From: Jill Ramonsky (Jill.Ramonsky@Aculab.com)
Date: Tue Nov 11 2003 - 07:00:41 EST
> -----Original Message-----
> From: Philippe Verdy [mailto:firstname.lastname@example.org]
> Why restricting to this range then [0 to 15]? The range of digits is
> infinite if you consider any possible radix...
That's correct, of course. The reason is that, in my experience (as I
can't speak for everyone else), radix sixteen is very frequently used,
and higher radices are not. In my life, if I had to answer the question
"which do you have to deal with most in your life - (a) decimal, or (b)
hexadecimal", I honestly wouldn't know which was the truthful answer.
It'd be touch and go either way. I appreciate that that's not the case
for most people, of course, but I don't think it could be argued that
there is any similar widespread use for, say radix-64. (For the record,
I am aware of its use as an email transport protection layer, but there
is no intention there that humans should have to deal with it directly,
as is the case with hex).
> In reality, you are defending the adoption of supplementary digits for
> natural sort.
Yes, that's correct. Except that I don't limit it just to natural sort,
which is but one algorithm among many. What I am arguing for is no
discrimination between the digit nine and the digit ten in any algorithm
for which it makes sense for the digit ten to exist.
> But stop supporting the WG2 proposal that
> clearly DOES NOT
> address your issue: it even does not guarantee that your
> IsDigit() function
> will return true for them (the author still considers them as
> letters when
> he states that they should collate along letters).
Good point. I had been aware of that, but I at least considered the
proposal a start, and that details like that could be changed in the
course of the discussion.
> What you want is not what the author of the proposal to WG2
> In fact
> you have radically different justifications. If you want to
> support the WG2
> proposal, will you accept that he revizes his proposal to also include
> figure-width decimal digits ?
To be honest, I'm not concerned with rendering issues. I don't care if
the extra symbols look like flying farm animals. But, since you
asked.... since I am arguing for no discrimination between the digit
nine and the the digit ten (etc.) it follows that I want the same rules
to apply accross the board to all digits. This means, if there are no
constraints on 0 to 9, then there should also be no constraints on the
digits ten to fifteen, and vice versa. I believe that, for the sake of
consistency, that WHENEVER a given font renders the digits zero to nine
with figure width, that same font should also render the digits ten to
fifteen with figure width (otherwise you no longer have indiscriminate
digits), but I see no reason to /require /figure width for any digit -
only that, if a font-designer is going to apply such a rule to /some/
digits, they should apply it to all of them. That said, I don't think
that this is an issue that should be mandated - it's pretty obvious from
my non-discrimination prerequisite. In the same vein, if 0-9 are
sans-serif then ten to fifteen should also be sans serif. I'm not sure
if this sort of thing should be mandated though, or just left to font
So, to answer your question directly: Rather than ask that the proposal
be revised to also include figure-width decimal digits, I would prefer
that it be revised in the opposite direction - that figure width hex
digits are not a requirement.
> If so, you will have for your
> natural sort
> several digits to manage: the ASCII ones, and the new ones needed for
> figure-width constraints.
Well, the "if so" test fails, so I guess I don't need to address that.
As I said in my previous email, there is only one mathematical object
meaning five, so one character suffices. (Yes, I do realise that it
could be argued that U+0660 to U+0669 may be considered ciphers for
U+0030 to U+0039, at least by mathematicians, but I don't want to start
down that road)
> Be honnest, what you want is supplementary digits,
> independantly of their
That's correct. (Actually, I thought that's what I was saying all along,
so by my reckoning I've been honest from the start).
> couldn't your digits have very distinct
> representative glyphs,
> completely unrelated to letters A to F, but still completely
> unrelated to
> figure-width constraints?
Yes. I don't care what they look like. In fact, since Unicode doesn't
encode ciphers, it seems to me that what they look like is a glyph
issue, not a character issue. I regard the sample glyphs in the proposal
paper as just one possible way among many in which they could be rendered.
> So you glyphs for these digits could be as well something
> like <1'0> for
> digit 10, with the apostrophe denoting a ligaturing
> connection between the
> two decimal digits equivalent to its value,
That's a good idea, so long as rendering agents are free to render the
<1'0> combination as "A" (or the flying pig I mentioned earlier, or
anything else that takes the fancy of a font-designer). In the case of
non-proportional fonts, or fonts in which '0' to '9' all have figure
space, it makes sense that the extra digits should ideally have the same
width as the old digits. If all of this is legal, the ligature idea
In fact, it might even be better, since it would allow things like
(U+0661, DIGIT COMBINING LIGATURE, U+0669), which would make hex
available to people who don't use the latin script. It would /also/
allow extention to radix-64 and above. (Yes, I know I said above that I
didn't think that was important, but if you get it for free, hell why not?).
In short, I like your idea.
> or an upper letter
> glyph on top of a
> baseline horizontal stroke, or slashed letters A to F
They have to be classified as digits. That's all that counts. I think
that if you modified A to F with combining characters, they would still
be letters, no? Digits is what I'm after. If they /looked/ like an upper
letter glyph on top of a baseline horizontal stroke, but were still
digits, that would be fine.
> or even completely invented glyphs ...
Again, no problem. But remember then that (as with the idea above) you'd
have to give them codepoints, and that I don't think that would actually
prevent font designers from rendering them the new codeponits as plain
"A" to "F" would it?.
> What you want is completely unrelated to the actual
> presentation of the
> digits, and figure-width is not a significant issue for your need.
Yes. Presumably we're all clear on that now. Although I still maintain
that IF 0 to 9 are figure-width, THEN, in the interests of equality
among digits, the extra digits should probably be figure-width too. I
don't see the point in mandating it though - if I /really /wanted figure
width hex digits (and hex digits existed in Unicode) I could learn how
to design fonts. I mean, it's not like there are an awful lot of glyphs
to encode in there!
Thanks for your highly constructive email. I'd be quite happy then to
support the addition of just one single new Unicode character then
(instead of six) - as in your ligature idea, which above I called DIGIT
COMBINING LIGATURE. This would seem to solve everything (pending your
answer to my proviso).
This archive was generated by hypermail 2.1.5 : Tue Nov 11 2003 - 07:50:36 EST