From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Aug 28 2007 - 01:30:17 CDT
From James Kass :
> The control pictures are coming from the font-in-use, which is the
> absolute *best* place for any renderer to get the outline data from.
Yes if the font has glyphs for them.
> If the font-in-use does not support VS characters, then I expect the
> renderer to use the missing glyph from that font. That makes the
> fact that the selected font is inappropriate visible to the author/user.
Not necessarily. If the "visible controls" mode is not enabled by the user
in the application's user interface (or by design in simple plain-text
editors), then the best is to not render them at all.
Rendering a control picture for a VS is useful only in limited situations
for editing with visible controls enabled, or in a mode where unsupported
VS-sequences will still show up. For this case, the user of that text editor
will need an appropriate font for document authoring and proofing. IF no
such font is available, then the editor will try to use the VS glyphs mapped
in the font (if they exist), otherwise the editor will use the .notdef glyph
of that font and will then show its "square box" (which should be present in
any font, and adapted to its metrics)...
The renderer should not try looking at another fallback font for other
possible visible VS glyphs when rendering in the "visible controls" mode for
editing, and will not even need it in the normal rendering mode when
unsupported VS-sequences are simply stripped from their VS instances.
This will be true as long as the base character (stripped from its VS) is
defined in that font; if it is not, the renderer can still look the base
character in fallback fonts, and then use its mapped VS sequence if it is
defined in that fallback font.
This archive was generated by hypermail 2.1.5 : Tue Aug 28 2007 - 01:32:02 CDT