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 * http://www.evertype.com/
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