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

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?

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.)

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.

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.

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.

Cheers
Rick Jelliffe

--
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)