Re: [xep-support] Support for Arabic Glyph Shaping?

From: W. Eliot Kimber (
Date: Tue Mar 18 2003 - 06:23:33 PST

  • Next message: Ondřej Tučný: "[xep-support] problem with XEP Ant task"

    David Tolpin wrote:
    >>If XEP can do Arabic glyph shaping and Thai glyph composition it will be
    >>very close to matching XSL Formatter for internationalization support.
    >>These two features are one of the key reasons that my multinational
    >>customers cannot consider XEP as a solution right now.

    > Eliot,
    > many multilingual customers do use XEP as the solution right now.

    I'm sure. But currently all of our multilingual customers require both
    Arabic and Thai support.

    > To implement it is a matter of time, and only one of our clients ever
    > considered it as a limitation.

    And I'm saying that I have at least two more customers for whom Thai
    support is a hard requirement that, if satisfied, would allow them to
    consider XEP where today they cannot.

    As an integrator and as a fan of XSL-FO, it's important to me that my
    customers and prospects have real choices of FO implementation. With XSL
    Formatter and XEP they do to a very remarkable degree.

    In all my years of working with SGML and XML tools as a user and
    integrator, it is unprecedented that the key distinguisher among two
    tools would be something as small as support for a single difficult
    writing system. Nevertheless, it is an important distinction.

    I know that development resources are limited and you have to make hard
    choices when prioritizing development work. I'm just giving you some
    input to the decision making process. ISOGEN is currently focusing on
    selling FO solutions to enteprises that have hard localization and
    internationalization challenges, so our focus is on things like Thai
    support. But this market still represents only a fraction of the total
    FO market, so it would not surprise me if XEP ranks other features
    higher than Thai support, especially given the challenge of implementing
    it. As an engineer I fully understand what goes into such decisions.

    XSL Formatter has until now had a clear advantage in the area of
    internationalization support. With the advent of glyph shaping in XEP
    that advantage will be almost completely erased. That's pretty amazing
    and should be a point of pride for the XEP development team.

    > XEP's implementation is consistent with the explicit wording of the specification.
    > Switching writing mode midway within one word if the word is hyphenated and
    > adjacent pages have different writing modes may not be an intent of the recommendation.

    Yes, which is one piece of evidence that XEP's interpretation is not the
    correct one. But there's other evidence that it is the correct one,
    which means that there's no way of knowing who is correct without a
    ruling from the editors.

    > The lack of functionality in XSL Formatter (and this lack of functionality is
    > in contradiction with explicit wording of the recommendation -- it explicitely
    > always for block-containers to generate several areas) should hardly be a cause
    > for RenderX team to implement non-compliant behaviour.

    I'm not suggesting that RenderX implement non-conforming behavior, just
    pointing out that with the current state of implementations
    interoperation in this (admittedly rare) case would not be possible.
    This is now one of the only areas I can think of where XSL Formatter and
    XEP are not capable of essentially identical behavior (now that XEP
    provides the option of enforcing the inheritance of indents to tables).

    Obviously Antenna House need to fix their limitations on block-container
    in XSL Formatter.



    W. Eliot Kimber,
    Consultant, ISOGEN International
    1016 La Posada Dr., Suite 240
    Austin, TX  78752 Phone: 512.656.4139
    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to from the address
    you are subscribed from.
    (*) By using the Service, you expressly agree to these Terms of Service

    This archive was generated by hypermail 2.1.5 : Tue Mar 18 2003 - 06:14:40 PST