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

From: Michael Everson <>
Date: Fri, 15 Jul 2011 22:18:26 +0100

On 15 Jul 2011, at 22:04, Ken Whistler wrote:

>> We see graphic characters shown, one representing space and two representing joiners. This is plain text.
> Bzzzzt. Thanks for playing! But the correct answer is that it is not plain text. And what you see are not graphic characters, but glyphs arranged in a formatted figure.

And hey, by golly, one could write that inline in a sentence very easily.
>> This is something one might wish to put on a web page or in an e-mail.
> As well one might:
> <Figure08-04.jpg>

Yes, Ken. We shouldn't ever encode anything ever again because people can just use images.
>> One of the three characters is encoded.
> Michael is referring to the little bridge symbol there, which is used to represent the presence of a space, and which is encoded as U+2423 OPEN BOX. Note that that is different from U+2420 SYMBOL FOR SPACE, which is the kind of generic visible symbol for invisible control codes that are in question here.

I did not say that OPEN BOX was SYMBOL FOR SPACE. There are several characters which can be used to represent SPACE graphically in the standard.

> As for the others, those are chart glyphs for the ZWNJ and the ZWJ. There is no need to encode *characters* for chart glyphs.

That's your assertion. Some other people have a different view, and think that there *is* a need to encode *characters* for chart glyphs.
>> Talking about the standard is *important*. Since the use of graphic characters in plain text is often cited as a criterion for encoding, and since some non-graphic characters in the standard have a SYMBOL FOR graphic representation, I do not, at all, think that it is unwise or capricious to suggest that other non-graphic characters in the standard also have a SYMBOL FOR graphic character which can be used to represent them.
> I don't think anybody is claiming capriciousness here, but having such symbols encoded as characters is definitely *unnecessary* for the standard.

Again, it's a judgement as to what is "necessary". I think the argument for encoding such symbols is

> As Asmus has already pointed out, we have been successfully talking about such characters in the standard for 20 years now. There are half a dozen ways to do so, some using plain text, and others using rich text and images.

Rich text? And inline images in text are not at all convenient. I used to have inline images for Middle English Yogh in my documents. I can't see any reason why a SYMBOL FOR RTL OVERRIDE would be "worse" than having to use images. I wouldn't use images anyway. I would use a PUA character. And that is not portable, so while I could use it for printing, I couldn't share it on the web.

And remember, we're about to encode three stupid pointless and genuinely useless interrobangs, for no real reason at all.
>> In fact, I think it would be advantageous to users of the standard and to promulgators of the standard for such symbols to be encoded.
> And I rather think not. Asmus' analysis was spot on.

Well, I can't just use a font and put a dotted box glyph on RTL Override, and I have shown exactly how. One might do it for SPACE. But the override controls prevent a glyph from being displayed. That's a problem without a solution.

Michael Everson *
Received on Fri Jul 15 2011 - 16:20:01 CDT

This archive was generated by hypermail 2.2.0 : Fri Jul 15 2011 - 16:20:01 CDT