Re: Visarga, ardhavisarga and anusvara -- combining marks or not?

From: verdy_p (
Date: Sun Sep 06 2009 - 15:50:24 CDT

  • Next message: verdy_p: "re: What justification for separately encoding two forms of lowercase sigma"

    > Message du 22/08/09 06:55
    > De : "Doug Ewell"
    > A : "Unicode Mailing List"
    > Copie à :
    > Objet : Re: Visarga, ardhavisarga and anusvara -- combining marks or not?
    > Shriramana Sharma wrote:
    > >> If you want Visarga and Anusvara to combine with Numerals, I think
    > >> you can use ZWJ
    > >> क्रयाहुताऽ२३४५ः
    > >> क्रयाहुताऽ२३४५‍ः
    > >
    > > Thanks, but:
    > >
    > > Not working on:
    > > MS Word 2003. Qt 4.5.2
    > >
    > > Working on:
    > > Firefox 3.5.2, OpenOffice 3.1.0

    Also working in Google Chrome and Safari (both based on Webkit). This gives then at least 3 distinct rendering
    engines that already accept it.

    > I haven't been following this thread too closely, so this is probably
    > out of context, but you need to be very careful if you are suggesting
    > changes to character properties on the basis that some existing software
    > doesn't follow the rules and display the characters correctly.

    Word and IE are probably based on the same default Windows script engine. I don't know exactly what Qt does, but it
    probably uses the default script rendering engine from the underlying OS.
    So may be it's Windows that needs to be updated. So the match is won 3 vs. 1 (only Windows).

    It's strange that you consider that the majority of softwares don't follow the rules and display the characters
    properly. It gives some hints about what are "the rules"? Is that Windows that gives them ?

    If three distinct engines are displaying the characters as intended for the effective script and expected by users,
    it's time to change your (implementation) rules, given the evidences that this changes can work as intended by the
    effective script rules.

    For the benefit of the global community, Microsoft should think about making more frequent changes to its script
    engine when needed than just between major versions of Windows. This lack of update is exactly what has forced other
    designers for web browsers or GUI libraries to rewrite their own renderer, to support more scripts than what was
    available more than 3 years ago when the last major version of Windows was designed.

    Yes, Windows 7 is coming and already offers some more scripts (in fact not a lot, just simple ones like 4 African
    alphasyllabaries), but it still limits them in some areas. In the next 2-3 years a solution will be developed by
    others and deployed on MacOSX, Linux, Java, Chrome, Mozilla and other softwares using their kits, and Windows will
    still be late: there's still no support and not apparent development for Burmese in Windows 7 (RC, RTM, and final
    included: I tried all of them, including with IE8 still present in them).

    In Europe where IE will not be preinstalled in Windows 7E (but the Windows text rendering engines should still be
    there), the market share for other browsers and renderers will considerably increase and Microsoft will stop
    ignoring that users want a better solution for interoperability (this need is increasing with the development of
    virtual OS hosted on virtual servers, and the huge development of virtual desktops, and share of the application
    deployment between several tiers, including for the GUI).

    It needs to open a bit more its rendering interface, otherwise the IE rendering engine will be dropped even within
    standalone applications, in favor of WebKit or Mozilla (also because of their much increased performance, and much
    reduced ressources usage, and better interlationalisation support).

    Even DirectWrite (part of DirectX for text rendering over a Direct2D surface, possibly connected itself to a GDI
    context for compatibility with legacy applications) is in competition now with other renderers that can use other
    accelerated features of Direct2D. DirectWrite still has a minor advantage for its support of advanded typographic
    features, but the first thing that users will want is the correct support of basic scripts: the highly contextual
    typographic features like glyph decorations will not be needed by most users, when they will still be able to use
    some decorated font designs for quite similar effects. Microsoft tries to launch DirectWrite as a successor of its
    legacy text renderer, but a good question is now to know if it will support the same openness to scripts.

    So can we stop in thinking that if things do not work in current versions of Windows when using IE, or MSWord, it is
    probably wrong? Others have implemented things correctly, and in interoperable ways with each others, meaning that
    Microsoft should follow their movement as well, and make these imporvements available to all, even if they don't
    upgrade Windows, given that other major softwares (browsers or office suites, and graphic libraries) are already
    implementing the new rules, proven better and interoperable with each other.

    This archive was generated by hypermail 2.1.5 : Sun Sep 06 2009 - 15:53:21 CDT