From: Mark Davis (mark.davis@icu-project.org)
Date: Tue Aug 28 2007 - 08:28:44 CDT
> "So I would suggest that the rendering engines be left alone in this
case. Any reader seeing unwanted boxes in any situation should
simply select an appropriate font. The presence of the boxes in
any text means that the selected font does not support some of
the characters it is being called to display."
In general, this is true. However, in the case of certain characters (the
important DI characters), the font developer is strongly recommended to
always include a glyph, since the display breaks for the user in unintended
ways. These characters are important not in and of themselves, but in terms
of the way that they may affect the display of surrounding characters. If
they are not supported, they should not be visible: the LRM, for example,
should never be visible. And the CJK VS characters should never be visible
in a font that has CJK characters.
Mark
On 8/28/07, James Kass <thunder-bird@earthlink.net> wrote:
>
>
> Philippe Verdy wrote,
>
> >Asmus Freytag wrote:
> >> Variation selectors have no business being visible - unless you are in
> a
> >> special mode. The whole idea behind them is that they can (and should)
> >> be ignored when the resources to act on them (variant glyphs) are not
> >> present.
> >
> >That's exactly the same conclusion I made when I suggested that renderers
> >strip the variation selectors not supported in the selected font...
> >
> >There's never any good reason to show the .notdef glyph of that font,
> >because according to Unicode reference, the sequence <char+VS> should be
> >treated like <char> without the VS, (except in special algorithms
> described
> >in the standard or its annexes) if the VS makes no sense with the
> available
> >local data.
> >
> >If renderers were updated to do that, variation selectors could be used
> more
> >easily and widely, and a reasonable default rendering would still be
> >available if there's no font defining glyphs for the specific
> variations...
> >and this would not create "bogous text" that readers are seeing, full of
> >boxes.
>
> A font which does not support VS sequences and has no glyph data
> mapped with VS characters will display the base character glyph
> plus the font's missing glyph in default rendering mode. (In plain
> text.) Just like any other combining mark character unsupported
> by a font.
>
> The developer can anticipate this and map the VS characters with
> zero-width no-contour glyphs in order to avoid having the missing
> glyph displayed.
>
> This would be a good recommendation, along the lines of Mark Davis'
> original suggestion. However, choices of glyph design and font
> coverage should remain with the font developer.
>
> Font developers are in the best position to know the intended uses
> of their fonts, and design accordingly.
>
> So I would suggest that the rendering engines be left alone in this
> case. Any reader seeing unwanted boxes in any situation should
> simply select an appropriate font. The presence of the boxes in
> any text means that the selected font does not support some of
> the characters it is being called to display.
>
> Best regards,
>
> James Kass
>
>
>
-- Mark
This archive was generated by hypermail 2.1.5 : Tue Aug 28 2007 - 08:31:08 CDT