From: James Kass (thunder-bird@earthlink.net)
Date: Sun Aug 26 2007 - 06:02:43 CDT
Mark Davis wrote,
> I□find□this□reasoning□bizarre.↓
> ↓
> Simply□because□someone□might□want□a□visible□symbol□of□a□character↓
> in□unusual□circumstances□like□a□code□chart□or□Show□Hidden□Mode,↓
> the□font□designer□is□supposed□to□have□an□abnormal□glyph?↓
> It□is□the□*unusual*□case□that□calls□for□*unusual*□glyphs,↓
> including,□those□for□space,□tab,□and□others.□
Mark,
Well.
In order for there to be abnormal glyphs there would have to be normal ones.
The glyphs in the Unicode charts are informative, not normative.
This, quite sensibly, leaves glyph design up to glyph designers.
Which enables developers for non-English user pools to construct appropriate
control picture glyphs for any character deemed necessary by the developer.
(And does not prevent developers for English users from doing likewise
in a manner consistent with the rest of the glyphs in a font.)
In my letter, I was only referring to VS characters. You had specifically
mentioned VS characters as an example of characters which must have
zero-width no-contour glyphs. But, there are existing conventions, as has
been shown, for other control-like characters, such as ZWJ etc.
For space characters, tabs, carriage returns, and so forth -- Unicode already has
special control pictures as characters. If an application needs to show control
pictures for such characters, the application should first check the font-in-use
to see if it supports those control picture characters. If so, the application
should use the glyphs from the selected font as first choice.
But, Unicode does *not* have control picture characters assigned for many
of the non-ASCII control characters. What could be more simple and logical
than storing outlines for glyphs for such characters in the font properly
mapped to those characters?
One method which might be better, perhaps, would be to have special control
picture characters dedicated for *all* the control characters.
I haven't seen such a proposal yet. But, such a proposal would make more
sense than any proposal to encode animated icons in a plain text standard.
(Touché, and winks to those who get it.)
In the meantime, there's nothing wrong or bizarre about the existing
practices. Please remember that, as long as the system and font support
the characters and sequences well, users wouldn't see the glyphs anyway.
(Unless the font is being called upon to display one of these characters
in isolation, such as what happens when populating a chart.) And, if
system and font don't support, then the user gets immediate visibility
that such is the case, alerting the user to select an appropriate font.
And, if the user does see control pictures but doesn't want to see them
for any reason, this user can also select an appropriate font.
> And□since□fonts□cannot↓
> be□depended□on□to□always□have□"Show□Hidden"□glyphs,□*those*↓
> are□the□ones□that□need□to□be□handled□specially□in□rendering.↓
Agreed, but what you are describing is simply fallback rendering. Any
font can be called upon to display any character in isolation at any time.
And there's nothing abnormal about that.
Best regards,
James Kass
This archive was generated by hypermail 2.1.5 : Sun Aug 26 2007 - 06:06:01 CDT