From: Jukka K. Korpela (jkorpela@cs.tut.fi)
Date: Wed Jan 18 2006 - 00:19:22 CST
On Tue, 17 Jan 2006, Kenneth Whistler wrote:
> They are encoded *for* compatibility with legacy encodings, but it does
> not follow logically from that that they should be generally avoided.
There is no such logical implication, but there is an explicit statement
in the standard, as I mentioned in the previous discussion.
> Remember, as I said the first time this went around, that some of these
> are encoded for compatibility with ISO 8859-1, which hardly is a matter
> of the Unicode Standard saying that those are characters to be "generally
> avoided."
Why not? What you use in ISO-8859-1 is one thing; what you use in Unicode
is another.
> The ELLIPSIS itself was encoded for compatibility with -- among others --
> the MacRoman character set.
And Windows Latin 1. So what?
> I think you may be in danger of mixing up the concept of deprecation --
No, I'm not. Deprecation is far stronger than any "should be avoided"
principle.
>> We may disagree on what constitutes a
>> special occasion, but it can hardly mean "whenever you like".
>
> Actually, in some instances, such as NO-BREAK SPACE and ELLIPSIS, it
> pretty much *does* mean whenever you like.
My point has been that the general principle is to avoid compatibility
characters and that there are exceptions to the principle, of varying
kind, including implicit or explicit statements about some characters in
the standard.
> Asmus just posted a whole list of reasons why use of HORIZONTAL ELLIPSIS
> is often quite expected and reasonable.
I think they were basically points about using an ellipsis _glyph_. (And
some cases were not convincing; e.g., in fixed-pitch fonts, "..." is
surely much too spaced, but a horizontal ellipsis surely has too _little_
spacing.) The question is whether you should use the HORIZONTAL ELLIPSIS
_characters_ or to deal with the typography issue at a higher level.
And my point was the latter would be preferable on general grounds, along
Unicode principles, but often not (yet, or perhaps ever) feasible on
practical grounds.
> Hence, no constraint (implied or otherwise) by the standard on
> its use as a character.
Non sequitur. It's not a matter of constraints but recommendations.
And special reasons that may constitute an acceptable reason to deviate
from the recommendations do not mean that the recommendation does not
exist.
> It doesn't need to be given a different status. "Compatibility character"
> does not mean "bad character".
That's your wording; I have referred to the "should not" wording.
-- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
This archive was generated by hypermail 2.1.5 : Wed Jan 18 2006 - 00:24:24 CST