[xep-support] Support for Arabic Glyph Shaping?

[W. Eliot Kimber]

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 at 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 at 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