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/
