[mpeg-OTspec] Proposal related to Last Resort fonts

[Sairus Patel]

> There's nothing to stop someone from implementing a font that covers one or more blocks properly and then uses a single glyph for everything in other blocks, of course.  It just seems like the result will be something of a chimera, neither fish nor fowl.

The dangerous part about producing a font like this is that there is no information that distinguishes one kind of mapping from the other: a layout engine pinging the Unicode cmap subtable to determine whether this font supports a particular character (say, as part of a fallback strategy) can't tell that it's a last resort glyph as opposed to a glyph that truly supports that code point.

Sairus


From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of John H. Jenkins
Sent: Thursday, April 09, 2009 3:03 PM
To: Levantovsky, Vladimir
Cc: Sairus Patel; mpeg-OTspec at yahoogroups.com; Michelle Perham (HILL); Daniel Fenwick; Julio Gonzalez; Simon Daniels; Sergey Malkin; John Hudson; Peter Constable; Peter Lofting; Greg Hitchcock; Christopher Slye
Subject: Re: [mpeg-OTspec] Proposal related to Last Resort fonts






On Apr 9, 2009, at 1:59 PM, Levantovsky, Vladimir wrote:


My original impression (maybe incorrect) was that it would be okay to have both standard cmap table support and 'last resort' cmap in the same font. It's feasible that one may want to create a Unicode fonts where supported code points would be encoded using e.g. cmap formats 0, 4 and 12, and unsupported code points would be encoded using cmap format 13 (although I am still trying to wrap my head around this as to why a different glyph rather than .notdef glyph would be needed to convey the same thing, maybe we should say something about it).


The only real reason to have a standard cmap subtable would be for compatibility with older parsers.  You're not likely to have a last resort font with the ability to cover, say, Latin properly.  The idea underlying the font is that it is a true font of last resort and will only be used when no other font in the system can properly display a character.  In Apple's case, we show a glyph specifying the Unicode block to which the character belongs, thus giving the user at least *some* information.

There's nothing to stop someone from implementing a font that covers one or more blocks properly and then uses a single glyph for everything in other blocks, of course.  It just seems like the result will be something of a chimera, neither fish nor fowl.

=====
John H. Jenkins
jenkins at apple.com<mailto:jenkins at apple.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090409/29e32775/attachment.html>