RE: Hexadecimal digits?

[Jill Ramonsky]

> -----Original Message-----
> From: Philippe Verdy [mailto:[EMAIL PROTECTED]]

> Why restricting to this range then [0 to 15]? The range of digits is
> mathematically
> 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
> wants.

Acknowledged.


> 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 designers.

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
> presentation:

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 would work.

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).

Jill