Re: Using Javascript to Detect Script Support in a Browser

From: Philippe Verdy (
Date: Tue Jun 22 2010 - 06:23:12 CDT

  • Next message: Andrey V. Lukyanov: "Re: UTF-12"

    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

    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

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

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