> >> At 03:03 AM 6/20/02 -0400, Tom Finch wrote: > >> >I wish to propose sixteen consecutive digits for the purpose of displaying > >> >hexadecimal values. [...] Has this been considered? > >>
[David Starner] > >> I seem to recall that it has. The problem is, they're just new copies of > >> old characters. An A used in hexadecimal notation is just an A. Besides the > >> problem with normalization, you have the problem with all look-alike > >> characters - people won't use them consistently. Even if this got adopted, > >> 99% of time you looked at hexadecimal numbers, they would be in plain old > >> ASCII, so you don't really gain anything but confusion. It's a no-go. > >> [Tom Finch] > I looked at the code chart and there are many 16 character sequences empty. That is true enough -- but the more appropriate place to look is the BMP roadmap: http://www.unicode.org/roadmaps/bmp-3-6.html where you can see that many of those empty columns are already accounted for by roadmapped allocations for living minority scripts. The BMP is rather tight now for allocation, and it is unlikely that the committees are going to look kindly on miscellaneous collections of dubious stuff for encoding there. Of course there is plenty of space in Plane 1 for just about everything, but... That said, David Starner has this one right. There really is no good reason to create clones of 0..9, A..F to represent hexadecimal digits. The existing characters do that just fine, and represent an overwhelming legacy data representation precedent that any proposal such as Tom Finch's would have to cope with. Introducing new characters for these would just introduce confusion and would be unlikely to be implemented in any useful way. --Ken
