From: Mark Davis (mark.davis@icu-project.org)
Date: Thu Oct 11 2007 - 10:55:44 CDT
comments below.
On 10/10/07, James Kass <thunder-bird@earthlink.net> wrote:
>
>
> Exasperated sigh.
>
> >
> > http://www.unicode.org/faq/unsup_char.html
> >
>
> > Q: How should characters be displayed if the rendering system
> > doesn't fully support them?
>
> The correct answer is that it depends on the operating system and the
> font(s) in use. Display issues such as these are beyond the scope of a
> character encoding standard. Suggestions are fine, defining expected
> behavior is not.
The VS characters represent a mechanism that has been defined by the Unicode
standard -- it is not as if these existed before the standard created them!
And their defined appearance is as invisible and nonspacing if they are not
part of a standardized sequence; and if they are part of a standardized
sequence then their effect is to change the appearance of the previous
character.
So as said before, for normal usage, your first line is not correct. It is
just as wrong as if you showed all the spaces in that line as being boxes
with SP in them.
Of course, in special modes like Show Hidden you might show both spaces as
boxes with SP in them (or using other conventions -- the standard doesn't
restrict you there) and VS1 as you show above. But what you do show is
simply not the desired appearance.
> A: There are three main options, depending on the type of
> > character involved. Some should not display at all (zero-width
> > invisible characters); some should display as a visible (but blank)
> > space; and some should be displayed with one or more generic
> > glyphs, often referred to as "missing glyphs" or a ".notdef glyph".
>
> The appearance of the "missing glyph" in a font is completely under
> the control of the font developer. Many developers use a hollow
> rectangle, but some developers use their own logos. Even some
> mainstream fonts, like MingLiU, have a spacing glyph with no
> contours for the missing glyph. (No contours means that, in
> such fonts, the missing glyph will display as a space. Take any
> blank sheet of paper, it matches MingLiU's display of any Canadian
> Syllabics text, for instance.)
What you say is true, and the text in the FAQ does not imply any particular
appearance.
> Where a font is being designed for a rendering system that does
> > not handle invisible characters (such as variation selectors), then
> > the best glyph for them — in the absence of other support — is a
> > zero-width invisible glyph.
>
> Fonts are built to the font specs and should be cross-platform. In
> the unlikely event that a developer targets a rendering system which
> doesn't handle so-called invisible characters, the font developer has
> a slim chance of knowing if and when the rendering system might
> be updated. Savvy font developers hew to the line, and let the chips
> fall where they may.
>
> The attached graphic "2229VS1.GIF" shows the display of the same
> text in two different fonts. What do the authors of this FAQ
> consider "broken" in this picture? One font? Both fonts? The
> operating system? The rendering system? The application?
>
> The correct answer is that the operating system, both the fonts,
> the rendering system, and the application are behaving correctly
> and as expected.
No, as above. If your font is to be cross-platform, and work regardless of
the environment, then you would show an invisible, nonspacing glyph if the
VS was not part of a standardized sequence.
Here's the text string used in the graphic: ∩ + ︀ = ∩︀
>
> Best regards,
>
> James Kass
>
> P.S. - I doubt if 'how to display unsupported characters' is really
> asked frequently and wonder what criteria determines the
> frequency of FAQs on the Unicode site. If it *is* a FAQ, then
> it should be asked on the OpenType list rather than at the
> consortium.
>
>
There are a great many issues about font design that are outside of the
scope of the standard. But there are certain ones that *are* in the scope,
namely those dealing with mechanisms architected by the standard, or having
to do with the fundamental identity of characters.
Suppose you produced a font that used the layout on
http://demo.icu-project.org/icu-bin/convexp?conv=ibm-37_P100-1995&s=ALLd
was thus designed to have the glyphs with the following correspondences.
Doesn't mean you can't build a font like that, but it just wouldn't be
Unicode.
...
µ U+00A0
~ U+00A1
s U+00A2
t U+00A3
u U+00A4
v U+00A5
...
-- Mark
This archive was generated by hypermail 2.1.5 : Thu Oct 11 2007 - 10:58:59 CDT