by Michael S. Kaplan, published on 2008/09/15 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/09/15/8951496.aspx
The other kind of MAC, in this case. :-)
Another from the list of bugs from that cool presentation from the folks over in Intel localization....
This one is kind of about Bidi.
Wait. Scratch that.
It is all about Bidi.
First some info from Loïc describing the screenshots:
There are 2 screenshots using Hebrew settings, 1 using Arabic. I must say those have so far puzzled our developers, and I wish we could set some sort of override for those MAC address fields. They're passed properly among applications, but their display can confuse the most experienced user ;-)
Please do not hesitate to share any suggestion about a possible fix.
I'll start with the screenshots, that were also part of the presentation itself, the examples of problems:
Okay, just so we all see it -- do you see what is happening to the Mac address?
It is easy to say that these are application-specific bugs, bugs that you should fix with Bidi control characters.
But that is really taking the easy way out.
Yes, you guessed it, I am thinking about those same thoughts from the recent blog The Bidi Algorithm's own SEP Field.
Let's explore the space a bit.
We'll start off with plain old English US settings.
And then to plain old Notepad, looking at some MAC addresses.
With both a left-to-right and then a right-to-left reading order:
Everything looks good. Cool.
Now we'll mix it up a bit, and go to Saudi Arabia:
We'll look at both orientations again.
Ready?
Well, we're half good. And half not so much.
Oh wait, I just remembered....
Context sensitive digit substitution.
We should also look at it with National digits:
This will even change the main dialog's look once it is all applied:
And we'll see it what it does to our Notepad stuff, too:
Now of course by rights there is another set of cases to look at -- with an Arabic UI language.
But I'll spare you the trouble, you can probably imagine -- or just use the original three screenshots and extrapolate what would happen.
The key here?
All of these cases, we are talking about plain text, the kind of scenario that Unicode was designed for. Did you know that according to Google, the words "plain text" appear a shade under 4,000 times?
Now for this bug, sure -- make the control have the attributes you want, and embed the control characters you need.
But what about documentation talking about the MAC addresses? What about there?
It is the job of documentation writers to embed Unicode control characters in the text, worldwide. Since one never knows what the user locale or the user UI language will be later on for the one reading the documentation.
We need something better here, for the whole world.
Because once again, Bidi is not doing so well in the world of mixed language text. Easier solutions are needed here....
For now, Loïc's request for a workaround? I suppose a forced LRE/PDF surrounding the text should do nicely enough here for now. But this will hardly scale to the general case, or the documentation case, or any of the other myriad of plain text cases. So what do we do?
This blog brought to you by މ (U+0789, aka THAANA LETTER MEEMU)
Daniel Yacob on 15 Sep 2008 10:04 AM:
The first thing that strikes me upon seeing the screenshot is "shouldn't those wifi signal bars reverse direction?" Or do quantity indicators, like numbers, remain LTR always?
Michiel on 16 Sep 2008 7:58 AM:
I'm probably missing a point here, but I don't understand why you describe the display in a "plain old English" local as "looks good". The LTR and RTL strings are in no sane way mirror images!
One can argue whether 12-34 should become 34-12 or 43-21, but 41-23 or 4-123 is out of the question.
Michael S. Kaplan on 16 Sep 2008 10:17 AM:
Good question, Daniel. I guess they use the height gradation to mitigate the fact that they did not mirror the UI piece when they should have? :-)
Michael S. Kaplan on 16 Sep 2008 10:17 AM:
Hey Michiel -- you aren't missing anything. For the record, the target users are also quite confused at the results, too. :-)
referenced by