From: Mark Davis (email@example.com)
Date: Fri Jun 01 2007 - 14:51:00 CDT
Character fallbacks in CLDR are not a rendering issue.
On 6/1/07, Philippe Verdy <firstname.lastname@example.org> wrote:
> De: email@example.com [mailto:firstname.lastname@example.org] De la
> part de Mark Davis
> > While this is not a matter of Unicode 5.0 conformance, it is a good
> 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
> fully conforming, but this should still be the recommended way to
> 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
> acute accent, when it is possible to compose it with a prior base
> 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
> 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
> original character should not be done before trying canonically equivalent
> > 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