From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon Aug 27 2007 - 21:33:23 CDT
Such specialized fonts for “show hidden” mode during editing will then need
to map explicitly the variation selectors to some glyph (possibly the
.notdef glyph if this is desired) The absence of mapping to .notdef should
mean that nothing was designed for them in the font, and the renderer should
do its best with that font, and simply discard the supported variation
selector during rendering (unless the renderer supports itself a “show
hidden” mode applicable to any font, suing the “show hidden” mode as defined
in that font where it exists, or implementing it itself if the font has no
such feature).
This way, fonts do not need to map variation selectors if they don’t have
any distinction of glyphs for the same characters followed or not by
specific selectors. This will be the case for most fonts.
So the simplest way to solve the problem is not to modify fonts, but enhance
the renderers so that they treat variation selectors in a smarter way, which
does not contradict the design of specific fonts that make glyph
distinctions using variation selectors.
This leaves the freedom for font designers to map the variation selectors
only when needed, and simplifies the process of designing fonts for the many
scripts (or subsets like alphabets) that don’t have such significant
distinction : The case where the letter “a” has an ascender above it or is a
single eye taking the whole x-height is such a variation, and a font may
define only one glyph for one form or the other. Only fonts that have two
separate glyphs will need to map variation selectors.
The same case occurs for the form of the descender in the letter “g” (note
that for IPA, the loop-less descender form of g has a separate code point,
which accepts no variation, many fonts map it to the same glyph as the
normal latin letter “g” unless this normal “g” is mapped to a glyph using a
descender with a loop by default, like “Times”-like fonts, that don’t always
support variation selectors for the normal Latin letter “g”).
Note also that most recents version of “Times”-like fonts (such as “Times
New Roman” for Windows) will support a variation selector for the letters
“a” and “g” to select the “a” without ascender above it, or the loopless
“g”, simply because these fonts also support the separate explicit mapping
for the Latin alpha and loop-less “g” used in IPA. A renderer may consider
this when seeing how to render “a”+VS or “g”+VS, and the font does not have
an explicit mapping for the sequence, and may “smartly” remap these
sequences to the same glyph as the glyphs mapped explicitly in the font for
the IPA symbols, instead of just stripping the VS not supported explicitly
by that font…
I consider this as a candidate RFE (Request For Enhancement) sent to the
developers of font renderers (including Windows itself in GDI/GDI+ and the
other related text layout and rendering APIs), but this does not imply any
RFE sent to font designers that may still choose what they want explicitly
in their fonts for variation selectors.
_____
De : unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] De la
part de Mark Davis
Envoyé : vendredi 24 août 2007 19:47
À : James Kass
Cc : Unicode Mailing List
Objet : Re: Apostrophes at www.unicode.org
If that is a common perception, then we certainly need to correct that
misapprehension.
For general-purpose fonts, the default ignorable code points should be
invisible, just like whitespace characters should be invisible. Specialized
fonts, such as those used for a "Show Hidden" mode or for code charts, may
well want to have visible glyphs for default ignorables, whitespace
characters, controls, confusable characters, and so on, so that people can
see the internals of their text. But those are very specialized cases.
Mark
On 8/24/07, James Kass <thunder-bird@earthlink.net > wrote:
Mark Davis wrote,
>A similar annoyance is the fact that so many fonts don't map the
>default-ignorable code points (like variation selectors) to a zero-width
>invisible glyph by default.
It's up to individual font developers to weigh the pros and cons
of including control picture glyphs for such characters, as it
should be.
Mapping characters like VS to zero-width no outline glyphs would
mean, for one thing, that applications which give the user the
option of displaying control characters (and related items) would
not be able to get appropriate outlines for such characters from
the font. Opinions on this differ, as discussed on this list in years
past.
If an OpenType font supports a sequence which involves a VS, the
user won't see the control picture. If the font doesn't support
the particular sequence, it can be helpful if that is reflected in
the display.
Best regards,
James Kass
-- Mark
This archive was generated by hypermail 2.1.5 : Mon Aug 27 2007 - 21:36:38 CDT