In an ideal world, there should exist no font that assigns the .notdef glyph to any valid Unicode code point (or to any valid sequence of Unicode code points that has been mapped with GSUB/GPOS OpenType features).
But given that such fonts do exist (and often cannot be legally modified), the best that can be done is to enforce this requirement in the renderer allowing the use of these fonts. This would solve the problem of undesirable matching of older fonts that made such incorrect mapping even if there's another font that can display these characters. The .notdef glyph should only be assigned to code points that are permanently assigned as invalid ; but never to any unassigned reserved code points, or any code point assigned now to valid code points (not even in the PUA encoding spaces). That's why the .notdef is traditionnally mapped on U+FFFE, but it could be mapped as well on U+FFFF or other code points (in the BMP or other planes) that are permanently mapped to invalid characters (including surrogates). As the .notdef glyph in a font should be visually distinct from any other "similar-looking" glyphs that correctly represent assigned codepoints (such as box symbols encoded with valid code points in Unicode), it should never be mapped to these valid code points to share the same glyph. So, text renderers may also ignore completely *all* assignments to the .notdef glyph, and decide to draw it directly without using any glyph from any specified font, but only according to the other selected text styles (in CSS properties: font-weight, font-height, font-style, text-decoration, line-height, color...) and possibly according to the general font metrics of the first available font matching the specified family names (to correctly size and position the drawn glyph). The renderer should also be able to compute the correct character properties (including the default directionality for unassigned reserved code points). If the renderer does that, it may present the .notdef glyph in various ways (displaying a box, or the hex code point value, or some icon, according to user preferences and internal software settings in the application using the text renderer). Limitation: - This can only be applied to fonts that include an Unicode mapping for indexing their glyphs. - Other non-Unicode glyph maps which are present in the same font should be ignored completely, even if they allow accessing to glyphs that are not indexed in the existing Unicode map (notably because these non-Unicode maps may use ambiguous or approximative glyphs that are accurate only for the legacy mappings, but not for Unicode conformance). This is esspecially true for legacy encodings whose mapping to Unicode contain ambiguous positions. - For all legacy fonts and symbol/private fonts whose glyphs are mapped *without* specifiying any Unicode map, or that were technically designed only for other specific character encodings (e.g. legacy PostScript Type 1, Windows .FON format, and the many OS-specific or application-specific formats using some legacy 8-bit system codepages), renderers should remap these encodings to Unicode using a conversion table that doesn't assign any code positions from these legacy/private encodings to invalid Unicode code points (the encoding mappings should use U+FFFD for remapping reserved/unused positions in those legacy/private encodings). For example, the legacy symbols fonts for Windows are remapped to Unicode within a dedicated contiguous range in the PUA space of the BMP, a range that's specific to the builtin text renderers of the Windows API. -- Philippe. "cibu cj" <[email protected]> wrote: > Use a font with only one character, U+FFFE with a glyph of known width in > displaying the measuring divs. The font may be specified using @font-face > for these divs.
