From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri Mar 17 2006 - 22:09:06 CST
From: Peter Constable
> Re-ordering of Indic vowels most certainly does work on the Indic scripts that are supported on XP (which is most of them).
Not from my experience, and from many users. Its nearly impossible to get aset of fontsworking with all of them.
> Last time I checked, UCAS doesn't have any re-ordering vowels.
I did not say that. I just included UCAS, because it's symptomatic of other problems in internalfont mappings.
> Myanmar and Oriya were not supported on XP.
That's something that Microsoft did not claim high. Why then providing user settings in Internet Explorer for these scripts if IE ignores this setting, or use the specified fonts incorrectly? Isn't it only because Windows XP just ships with fonts supporting only the national digits?
>> * Bengali, Oriya, Malayalam (left matras displayed on the right),
>
> Bengali and Malayalam are supported in XP SP2, and the left matras display on the left.
Lots of attempts trying to make them work. But very disapointed to see that left matras are displayed on right in Internet Explorer 6 or 7 beta, but not in Firefox.
>> * Telugu (minor: only one matra is subjoined, others are not subjoined or upper
>> joined but always displayed after the consonnant)
>
> We display Telugu vowels where they belong in relation to the typeface.
> Some attach above, some go below and some go lower right.
Does not work for me with "Arial Unicode MS" or "Gautami" (tried on several hosts,with orwithout Office 2003 or XP installed, but all updated with SP2). Only works with "Akshar Unicode", a third-party font in Internet Explorer. With Firefox, each of these three fonts give correct results.
> Lao and Tibetan are not supported scripts on XP. Lao, Tibetan, Khmer, Oriya, Sinhala, UCAS - all these will be supported on Vista.
Why then giving options to users to set fonts for Lao, Tibetan, Khmer and Sinhala? These options have there in Internet Explorer even before Windows XP was released. WhenXPwas released, thesupport wasstill not there, but thesescripts were still announced in user interface settings. So users thought that these scripts would be finally available in XP. More than 4 years later, these scripts are still unsupported, and they won't... Indian customers mat bevery disappointed if they upgraded to XP (or are still upgrading now, given that Vista is still not released) just to try getting this support not working in Windows 98SE or Windows 2000.
> Keep in mind an important difference between bugs and unsupported functionality.
Iknow, but a feature that is announced in visible configurations are supposed to be working. Otherwise they are perceived as bogous.
>> From the data I have, there are legions of documents with such tweaks, so this is now a serious
>> interoperability problem.
>
> I won't debate that point. But I will correct inaccurate statements such as your earlier one about IE not handling re-ordering Indic vowels.
I did not say that. I said that this support was not complete, and not working for all the announced Indic scripts that are configurable in IE options. If there's noway to configure it correctly for these scripts, these options should simply not be there.
Until now, I've never been able to display Oriya correctly in Internet Explorer, even with the appropriate fonts (but this works in Mozilla and Firefox, as they use another text rendering engine).
But what is unbelievable, is that this script does work very well for me in Notepad and in WordPad / Write (provided that I select the appropriate font for that script), and sometimes default fonts are found for missing glyphs using some internal magic. So this support does exist somewhere in Windows or in some of its visual components, but are not used (or used differently) in Internet Explorer's text renderer.
Anyway, there are many new scripts (including Indic scripts but with simple behavior that donot require advanced OpenType features) that do work in Internet Explorer and user settings should allow users setting more specific fonts for them, instead of just configuring a one-do-all giant font with basic design.
I don't know if there's only a way to extend the list of scripts displayed inuser setting, and specifying the associated codepoint ranges (It looks like this list is hardcoded and tied to the version of Uniscribe for the local Windows system version).
In fact, this way of configuring fonts for each script is defective because one font is often not enough. It would be preferable to configure instead a CSS stylesheet, with rules selectors matching one or more script codes or code point ranges, and assigned styles pointing to "font-family:" settings with multiple fonts specified (as well as forced font styles such as "font-weight:normal !important;font-style:normal !important;" or "font-size:150%;linesize:180%;" adjustments for example with Thai or Dzongkha), or to import such stylesheet in the user registry for other applications.
Are there ways to define such things with CSS "@font" specifiers to build custom fonts, and notably the standard generic families "monospace", "serif", "sans-serif"? (Another limitation of IE settings is that they don't affect the standard "serif" and "sans-serif" families, which are internally bound to Windows core fonts, or some fonts installed with Office and its updated or modified Uniscribe engine.)
There's always some undetermiend magic to determine whichfont will be used, and webpage authors need to reference specific fonts for Internet Explorer on Windows, and not "serif" or "sans-serif" in CSS stylesheets. This breaks the interoperability of documents with other systems (including past versions of Windows or Internet Explorer), or with other browsers supporting user-friendly and configurable "serif" and "sans-serif" generic families.
If you just look at the horrible long header that is needed in HTML pages to detect various Internet Explorer versions and load specific CSS stylesheets for each of them, this is a nightmare for lots of web authors (and now things aren't better with IE7 beta1 and beta2 that also need their own separate settings). For example the HTML source code generated by Wikipedia (and even with this code, it's still not possible to get true international support, notably because of the internally bound "serif" and "sans-serif" font-families; you also need to use some JavaScript to remove some inherited styles, something that should not be necessary with CSS).
Things would be much simpler using aconfiguration based on ISO15924 script codes corresponding to Unicode properties of characters, and if there was a way in Windows to add more character properties (but apparently it's impossible for security reasons, as those properties are hardcoded in some system DLLs used by critical services, instead of being loaded as a separate Unicode properties DLL or using the registry to bind external properties file easy to update). I think that Miscrosoft has hardwired too many things in Windows internationalization support code, that should be left configurable by users (even if those settings are easily recoverable using some hardwired or signed "restore to default" system settings). This is strange, given the huge number of possible system hooks that Microsoft allows including in its kernel, to support PnP devices (most protections in Windows are in the GUI implementation code, not in the low level kernel API or in the Windows messages processing loop)
This archive was generated by hypermail 2.1.5 : Fri Mar 17 2006 - 22:13:52 CST