And the digits just keep on coming

by Michael S. Kaplan, published on 2006/02/22 09:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/02/22/536877.aspx

I have definitely talked about digit substitution many times since I started with this blog.

And then I posted about my disillunsioned realization that Uniscribe was simply not doing as much as it could in the post Digits -- there is no substitute.

Unfortunately, it gets worse.

The ScriptRecordDigitSubstitution function, while seeming perfectly innocent and useful, has an interesting note in its Platform SDK topic:

Note that context digit substitution is supported only in Arabic and Persian locales. In other locales, context digit substitution is mapped to no substitution.

You may think when you see this text that it was euphamistically talking about all Arabic script locales.

I could make fun of your idealistic misperception, but it's what I thought too, so that would not be in my best interests. Instead I'll just commiserate with you for a bit. :-)

That is right, the ScriptRecordDigitSubstitution function is using ConvertDefaultLocale (that 'internal' function I have talked about before) and then getting the PRIMARYLANGID from the result.

And then it uses whether that little dance returns LANG_ARABIC or LANG_FARSI to know whether to support 'context' style digit substitution (it also puts that value into SCRIPT_DIGITSUBSTITUTE.TraditionalDigitLanguage for your viewing pleasure).

This is really kind of disappointing; just as with that post that ruined my idealistic view of digit substitution intially, Uniscribe is potentially ignoring a user preference -- like if I wanted Thai digits and  context style substitution, shouldn't I be able to have that?

To look at from a more "glass is half full" point of view for a moment, there is definitely a lot of room for improvement here in the future!

In the meantime, you can muck about a bit with the SCRIPT_DIGITSUBSTITUTE structure that ScriptRecordDigitSubstitution returns and modify it before calling ScriptApplyDigitSubstitution. You do not have complete freedom to fix everything, but you have the opportunity to help make up for some of the shortcomings of ScriptRecordDigitSubstitution I talk about here, at least.

This will not help with all of the problems, but at the very least it will work around this Arabic/Farsi only thing. And help meet the linguistic expectations of users since we took the trouble to ask them to detail those expectations in Regional Options.

Which by the way might explain why I am so torqued about this problem -- we are the ones exposing the settings, which means it is the GIFT team that is sitting in role of 'user car salesmen' who make promises that the car itself has no plan to deliver.

But to put a positive spin on that, it is an even better motivator for change, at some point.

To put a slightly more positive spin on the whole situation, Avalon (a.k.a. Windows Presentation Foundation) does a much better job, in part due to the hard work of some of the same people who wrote the original Uniscribe 'logic' (to use a term loosely!). Which is I think good proof that we are getting better here! :-)

This post brought to you by "୧" (U+0b67, a.k.a. ORIYA DIGIT ONE)

referenced by

go to newer or older post, or back to index or month or day