Re: Quick survey of Apple symbol fonts (in context of the Wingding/Webding proposal)

From: Asmus Freytag <>
Date: Sun, 17 Jul 2011 18:34:09 -0700

On 7/17/2011 12:19 PM, Philippe Verdy wrote:
> 2011/7/17 Asmus Freytag<>:
>> On 7/17/2011 2:35 AM, Michael Everson wrote:
>>> ... invisible and stateful control characters are more expensive than
>>> ordinary graphic symbols.
>> In this case, the expense is so much higher as to rule out such an idea from
>> the start.
>> A./
>> PS: this doesn't mean that adding graphic symbols is the foregone thing to
>> do, only that, if evidence points to the need to address this issue in
>> character encoding, then, using graphic symbols is the better way to go
>> about it.
> Another alternative: instead of encoding separate symbols for each
> control, we could as well encode symbols for each character visible in
> those symbols.
> E.g. ro represent the glyph for the RLO control, we could encode three
> characters, one for each of R, L, and O, as DOTTED SYMBOL FOR LATIN
> SYMBOL FOR LATIN CAPITAL LETTER O. These three symbols would have a
> representative glyph as the base letter from which they are derived,
> within a dotted rectangle.
> Then each of them would contextually adopt one of four glyph forms :
> the full rectangle, or the rectangle with the left or right side
> removed, or both sides removed. The selection would be performed
> selectively.

I'm baffled: what problem is this elaborate scheme trying to solve?

The problem was never in *how* to encode such symbols, but in *whether*
they should be considered *characters* (and therefore need to be
supported on the character level of the architecture). That point,
whether there's a reasonable use case for them as characters, has not
been settled, so the case for thinking about encoding solutions has not
been established.

When people write about a line feed character, they use "LF" or
"linefeed" or 000A (or U+000A or 0x0A etc.). They commonly don't use the
"LF" symbol character, nor any other unencoded symbol.

I claim, the same is true for ZWJ, RLO, PDF and all the other good

Just because Unicode uses dashed box placeholders in the code charts
hasn't made them the generally accepted, universally understood
*symbols* for these characters.

This is different from the "pictures for control codes" because at the
time, these were widely supported in devices, and users of these devices
(terminals) were familiar with the convention (staggered small letters)
and many would recognize common control characters.

So, let's keep a lid on devising ever more arcane and fragile encoding
and pseudo-encoding options until there's consensus that this issue must
be addressed on the character level.

Received on Sun Jul 17 2011 - 20:36:28 CDT

This archive was generated by hypermail 2.2.0 : Sun Jul 17 2011 - 20:36:29 CDT