by Michael S. Kaplan, published on 2006/06/18 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/18/635831.aspx
One of the occupational hazards of having the job I do and also having 'notions of linguistic aptitude' is that sometimes an idea might occur to me that initially seems interesting but after a whole bunch of research it turns out that it wasn't really such a good idea after all.
As an example, as a part of the work in Vista to support the Unicode 5.0 repetoire in the default collation table, a lot of weights had to be added to many different code points. In one particular case, I was looking at how Unicode has a block of characters encoded for Braille. From section 14.9 of of the latest version of The Unicode Standard:
Braille is a writing system used by blind people worldwide. It uses a system of six or eight raised dots, arranged in two vertical rows of three or four dots respectively. Eight-dot systems build on six-dot systems by adding two extra dots above or below the core matrix. Sixdot Braille allows 64 possible combinations, and eight-dot Braille allows 256 possible patterns of dot combinations. There is no fixed correspondence between a dot pattern and a character or symbol of any given script. Dot pattern assignments are dependent on context and user community.
I started thinking about the fact that so many different languages had collation support in Windows and so many of those same languages had standardized mappings for how characters are represented in Braille. Should the braille be ordered according to the individual languages?
Unicode itself did not have that information in the block description on this point.
Working on the assumption that perhaps 2 + 2 might be 4, I talked to folks in the group who agreed that it would make sense to find out. I started contacting people who worked in accessibility and folks they pointed me at to try to find out whether this idea had any merit. Because although it seemed very clever, to be sure, but not really useful unless that is how Braille might be used in its Unicode encoding....
In the end, it turned out that it was not going to be a very useful idea, because Braille as encoded in Unicode is not generally used in this way -- there are not widespread lists of encoded text in Braille that would need to be sorted, and the transformation to move between languages and their Braille representations work just fine with the languages themselves as they are in Unicode now.
Also, generally speaking, additional ideas like a keyboard that supports the range are also not as useful, because it is uncommonb to be typing directly in Braille now -- screen readers work on very different principles, to help the blind read any material, not just things typed specifically for them.
So perhaps in this case 2 + 2 actually turned out to be 22 and that the time spent looking into the issue was technically "wasted" at some level, but there are several things about the process that I like:
I'll probably have sequels to this post to talk about other such cases -- ideas that did work out, ones that are good ideas but are not yet feasible, ones that like this one with Braille did not really pan out in the end. It is the sort of process that can make the job very interesting....
(Hopefully you found it interesting also; if not then you can try again tomorrow!)
This post brought to you by ⠡ (U+2821, a.k.a. BRAILLE PATTERN DOTS-16)
referenced by