Re: CLDR 1.5 beta/Unicode 5.0: character fallback substitutions

From: Mark Davis (
Date: Fri Jun 01 2007 - 14:51:00 CDT

  • Next message: Arne Goetje: "Re: writing Chinese dialects"

    Character fallbacks in CLDR are not a rendering issue.


    On 6/1/07, Philippe Verdy <> wrote:
    > De: [] De la
    > part de Mark Davis
    > > While this is not a matter of Unicode 5.0 conformance, it is a good
    > suggestion.
    > If a renderer produces different results from input strings that are
    > canonically equivalent, then it is not a conforming process.
    > It's true that Unicode does not absolutely require that a renderer should
    > be
    > fully conforming, but this should still be the recommended way to
    > implement
    > it: minor typographic differences are acceptable as long as it does not
    > break too much the character identity (so if a font does not have a
    > precomposed glyph for the small letter i with an acute accent over it, it
    > may try to emulate it by using two glyphs even if the positioning is not
    > perfect, as this does not change fundamentally the intended semantics.
    > The same is true if a font does not have a separate glyph for the
    > combining
    > acute accent, when it is possible to compose it with a prior base
    > character
    > in order to create a precomposed character that is mapped to an existing
    > glyph. But generally in this case, fonts should contain mappings for
    > rendering the decomposed character using the same glyph as the one used
    > for
    > rendering the precomposed character, even if there's no glyph defined
    > isolately for the combining accent, or renderers should be able to detect
    > those extra mappings if they are not present in the font file.
    > But trying to use an explicit fallback that is completely different from
    > the
    > original character should not be done before trying canonically equivalent
    > strings.
    > > Can you file as a bug?
    > Bug filed (id #1387)


    This archive was generated by hypermail 2.1.5 : Fri Jun 01 2007 - 14:53:21 CDT