From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Jun 22 2010 - 06:23:12 CDT
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" <cibucj@gmail.com> 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.
This archive was generated by hypermail 2.1.5 : Tue Jun 22 2010 - 06:25:11 CDT