From: W. Eliot Kimber (eliot@isogen.com)
Date: Tue Mar 18 2003 - 06:23:33 PST
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.
Cheers,
E.
-- W. Eliot Kimber, eliot@isogen.com 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 majordomo@renderx.com from the address you are subscribed from. (*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Tue Mar 18 2003 - 06:14:40 PST