[dsdl-discuss] Re: Does Part 7 need built-in definitions forIANA sets?

Rick responded to my comments on the Euro
> Martin Bryan wrote:
>
> >Let me add another requirement that came up in real-life only yesterday.
> >
> >We have an application in which the customer requires us to use
Baskerville.
> >He also requires the use of the Euro sign. The Euro sign does not exist
in
> >the Baskerville font, so it can only be used within a section of text
that
> >is flagged as being set in a different font. In normal text the Euro sign
> >must report an error. In specific fonts it does not report an error.
> >
> >
> Are you saying that if we provide built-ins for standard encodings,
> because they
> are easy to test using the platform API rather than an explicit
> specification, then
> we can/should also provide built-ins for fonts, because they are
> similarly easy to
> test using the platform API?

No, we do not need to provide fonts. What my request was for is that we must
be able to say "character set x without charcters a,b c or anything in range
a-c". In other words it should be possible to generate an error report if
characters you know cannot be handled in specific scenarios is encountered.

>
> I quite agree, but in the knowledge that many fonts lie about which
> characters they provide.
> (Things are getting better for BMP characters as we move away from
horrible
> Windows 9* fonts, which are frequently unreliable, but the initial
> generation of
> fonts for surrogate-range characters have horrible metrics still.)

This problem is not with Windows 9* font but a full ATF font that was
created in the days when Euros did not exist. Remember that this is an
extension character. Very few fonts are fully UTF compatible - they need
some fallback mechanism to pick up missing characters. But this is a
style-sheet thing. What I am asking for is a validation level warning that
problems could occur during subsequent formatting if certain characters are
present.
>
> As far as being able to send an XML document though an XSLT, to generate
> an FO document, then resolving the FO document so that it all has explicit
> font information rather than using libraries, and then validating each
> element
> differently with Part 7, that is out-of-scope for part 7. XSLT
transformers
> and FO resolvers should be treated as external processors that our
> architecture allows.

Agreed
>
> Indeed, this is why is it so important that we resist ever deverting
> from our XML-in/XML-out
> model. (By which I mean Well-formed XML In/Well-formed XML Out, by the
> way!)
> It gives a basic discipline which allows implementers readily to use
> existing
> component such as XSLT transformers.
>
> However, I would say that there is a difference between fonts and
> character sets.
> The characters available in a font differ from system to system. They
> are not standard.
> Indeed, some platforms such as Java have fallbacks where if a font is
> missing from one
> font, a different font is used. Also, East Asian systems sometimes
> support virtual fonts
> (as does Java) which different ranges from different real fonts are
> selected. Furthermore,
> the font metrics for a particular platform report the installed screen
> fonts, not fonts on a
> remote printer; this is obviously changing, especially because Adobe has
> changed its
> marketing towards downloadable fonts.

Agreed we should encourage fallbacks wherever they are available. The
problem is with coping with systems that have no such fallback (in this case
a typesetting system). The point is that the character should have been
entered as € to ensure that the correct font would be mapped to. It was
entering it as the UTF codepoint for Euro that led to the problem.

> So, all things considered, I think it would be better to imagine a
> font-to-part7 creation utility,
> rather than an implementation using the API directly. The part 7 schema
> creation
> utility would make a hulls-and-kernels specification for the font, which
> would then be
> used on any system.

Interesting idea of automatically generated font-specific character sets,
but I'm not sure we want to get into the complexity of that. A simpler
mechanism is a "but not ..." option on the character set when specified
contexts have been identified.

Martin

Martin

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)