Let's go Uniscribe / ClearType has a real good vibe / So please use them in Safari, Steve [Jobs]!

by Michael S. Kaplan, published on 2007/06/14 21:02 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/06/14/3302077.aspx

(Title based on Surfin' Safari; apologies to both Brian Wilson and Mike Love, they deserve much better than this sort of nonsense -- I did not save the rest the lyrics I came up with out of respect for them

I haven't tried it (I might wait until I hear better news on the security front!). Though I have been reading Scott Hanselman's coverage:

And beyond the clear performance focus, a few points stuck out for me (these are both quotes):

That combined with Tom's thoughts and suddenly I have some opinions. Who'd have thunk it? :-)

When I think of all of the script support that Uniscribe and built-in fonts provide if not for free than at least for less than doing it all oneself, I winder how good the international support will be in the end. Could they afford to make the support better (or at least fuller) on Windows than it is on a Mac? Or is it better for them to keep the best support running on their main target?

I vaguely recall in the early days of Mozilla the debate over whether to use platform-specific functionality such as Uniscribe (in the end the people wanting to include that support where it existed win out over those who preferred a homogeneous approach, which detractors would see as more of a "least common denominator" browser).

Now all of that last paragraph is third-hand and fourth-hand knowledge from people who were there in the early days of getting Mozilla builds to support Bidi and Vietnamese and supplementary characters, with my speculation thrown on top of it based on bugs that I mentioned and which others got formally tracked and fixed. So if I have details wrong there, I apologize....

But going back on Safari, will Apple keep their least common denominator approach with an apple light-up scenario? Or will the effort be to support the best of the platform on which it is running, when it exists?

In my personal opinion, if they decided to support Uniscribe then I think the "fast browser with good internationalization support that works better on Windows than Mac" will be much more embarrassing for Microsoft/Windows/IE than for Apple/Mac/Safari.

And FWIW, I personally prefer it when there is strong competition in situations like this, on the whole it makes the features less random and more customer driven (it is just easier to prioritize the importance of features!). and I'd be just as happy to help out Safari devs having Uniscribe trouble as I have been to help others. The only trouble is getting them to ask....

This post brought to you by ẩ (U+0061 U+0302 U+0309, a.k.a. LATIN SMALL LETTER A + COMBINING CIRCUMFLEX ACCENT + COMBINING HOOK ABOVE)

AFAIK the Win32 WebKit uses Uniscribe and you can always visit their site [1] and start contributing - lets ignore the various existing restictions for a second :]

P.S.: I am not sure if I would call Apples UI thing an "[...] amazing owner-draw cross-platform UI framework"...

[1] http://webkit.org/

Agreed that Uniscribe is a great technology. But I have these issues with it-

1. It is non re-distributable.

2. We will have to instruct the end-user to get Uniscribe by other means (Install IE6/7 with complex script support)

3. It is not cross-platform -does not work in Linux.

I strongly believe that MS should address these issues so that the opentype font technology can be propogated.

Regards,

-Pavanaja

It's also possible that Apple will simply port the relevant bits of OS X's international support. If you browse around the files Safari installs you can see various bits of the Unicode database.

One of Safari's big issues at the moment is that it tries to use locale-specific resources, but only includes resources for English. It's somewhat difficult to distinguish between this bug and other bugs, since this one causes severe rendering issues -- elements disappearing and such.

Your recent post on the dangerous characters (http://blogs.msdn.com/michkap/archive/2007/06/12/3251648.aspx) renders pretty much the same in IE7/XP and Safari/XP, so it's not like there's a blatant "CJK doesn't work at all" problem.

If Apple is porting all of their international support, I think that will make for an even more interesting comparison, although I'm not certain users will win much of anything...

Pavanaja, what benefits in principle do you detect in choosing Uniscribe over something that's already cross platform like Pango?

I see that there's an outstanding Pango rendering bug relevant to Kannada (someone should poke the relevant maintainer, I don't know who that is for indic) is that enough to put you off?

Reporting from the Mac side, ẩ looks right in UnicodeChecker and other Cocoa-based apps like TextEdit, but the combining hook above messes up in Safari. In the Mozilla-based Camino, the combining circumflex also messes up.

The latest reports indicate Win Safari beta can't handle any complex script correctly, including Thai diacritic placement, Arabic, and Devanagari, even though characters do display. Perhaps the results of using Mac AAT fonts with Uniscribe (or at least without the OS support needed for AAT)?

If Win Safari can be made to use OpenType instead of AAT fonts for complex scripts, it will in fact be be superior to the Mac version, since the latter can only use AAT, which is rare or non-existent for many scripts.

Note 1

Let's not forget that Mac OS X has no clear story for Arabic and Hebrew (RTL), or Indic languages (complex scripts).

The Apple controls do not support any kind of mirroring (and I am not talking about text rendering here, but about "flipping" the controls, for instance the radio button having the "button" part on the right).

So even taking all the Mac OS X international support and embedding it in Safari/Win will not bring Safari to the same level as the applications using Windows NLS support.

Note 2

As a general rule, I think it is wrong to do your own thing.

Your own UI, your own custom controls, your own i18n support.

Being different can be cool sometimes, but it is not easy to get it right. Too different, and you are an outcast.

Do your own and you will be out of sync, and different than all the other applications. Have your own locale data (with ICU, for instance), and you suddenly ignore the user preferences in the "Regional and Language Options."

When MS releases support for locales (like it did happen with XP SP2, and with Update 897338), all the other applications "will get it," yours will not.

Pretty much the same with the UI.

Without getting too deep into this, read the Safari-Win complains: resizing from the bottom-right border, own font rendering, ignoring standard Windows shortcuts for tab switching, dialog boxes show up in Explorer bar, etc.

People need consistency.

I have been doing some Uniscribe stuff lately so I was very interested in looking at what Safari does. It appears that the current beta (it does not suppose complex text) is from a rather old branch of the WebKit code. If you look at the trunk you can find that it does use Uniscribe:

http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/win/UniscribeController.cpp

Apparently, they use it to select the glyphs, and then use their weirdo Mac code to actually render the glyphs. Who knows if everything is preserved through this tortured path (though maybe it works great).

If you want people to use Uniscribe, how about giving us some decent documentation and examples? The API itself is extremely difficult to use, and the MSDN documentation is vague and in some cases downright wrong (yes, I reported the errors I found). There are no examples that I can find. Almost the only "real" implementation I could find code for was Mozilla, whose code is awful in it's own way.

Although it's nice of you to offer to help them, you guys could help everyone use this API but you aren't.

The Uniscribe vs. Pango thing in Firefox at least isn't finished with yet -- support for either is still non-existant (on Windows). I believe they had originally planned to go with cross-platform Pango (and the Linux builds of Firefox already use Pango) but apparently they're now going with Uniscribe. It's supposed to be in the 3.0 release of Firerfox...

To be honest, whether you go with a platform-specific solution, such as Uniscribe vs. something like Pango, is an interesting question. If you go with Uniscribe, you're pretty much limited to what the platform provides. But if they went with Pango, they could add support for more languages or scripts at any time. And given that Pango is not just used in the browser, but in almost all of Linux (at least, all of Gnome/KDE) it's not like the number of supported scripts is *small* (far from it).

To be honest, I think I would have preferred that they went with Pango on Windows. If nothing else, it'd give us an easy way to compare and contrast the two frameworks without having to have Linux installed... ;-)

Firefox has supported Uniscribe since at least version 1. There have been some issues related to spacing and justification, but CTL scripts such as Devanagari or Gurmukhi have worked since the get-go. There were some bugs which were apparent from version 1, but they were fixed with the switch to Cairo in Firefox 3.

Neither Safari, IE or Firefox can render Bengali properly in Unicode. So obviously there is a problem with Uniscribe too. Users of the Bengali script have to make do with Dynamic Fonts which only IE supports. Bengali is the 4th or 5th largest spoken language in the world and no proper support from anyone as yet. This is strange.

Besides rendering on browsers there is no proper wrod processor for Bengali as yet. I wonder where the problem lies.