From: Mark Davis (mark.davis@icu-project.org)
Date: Fri Jun 01 2007 - 14:51:00 CDT
Character fallbacks in CLDR are not a rendering issue.
Mark
On 6/1/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:
>
> De: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] 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)
>
>
>
>
-- Mark
This archive was generated by hypermail 2.1.5 : Fri Jun 01 2007 - 14:53:21 CDT