<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 9, 2009, at 1:59 PM, Levantovsky, Vladimir wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: TaligentMono; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="clear: both; padding-top: 15px; padding-right: 0px; padding-bottom: 3px; padding-left: 0px; overflow-x: hidden; overflow-y: hidden; margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">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).</span></div></span><br class="Apple-interchange-newline"></blockquote></div><br><div>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. </div><div><br></div><div>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. </div><div><br></div><div>=====</div><div>John H. Jenkins</div><div><a href="mailto:jenkins@apple.com">jenkins@apple.com</a></div><div><br></div></body></html>