RE: Hexadecimal digits?

From: Jill Ramonsky (
Date: Tue Nov 11 2003 - 07:00:41 EST

  • Next message: Kent Karlsson: "RE: Hexadecimal digits?"

    > -----Original Message-----
    > From: Philippe Verdy []

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


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


    This archive was generated by hypermail 2.1.5 : Tue Nov 11 2003 - 07:50:36 EST