[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

[no subject]

[no subject]
So advice no 2: test different versions of your toolset and test them well.
When I first started working on arabic manuals with lots of english terms in
them, Antenna House was my best option and did a very very good job already.
For fixing the issues left in the manuals we added a bidi override context
(<term> element)
In the 6.3 release and the 6.3 Maintenance Release 1, Antenna House largely
improved the handling of bidi overrides.
We soon realised that Antenna House did fix some of our issues for us, so we
are in the process of undoing some of our context fixes

Hope this helps at least a little
Depending on the popularity of this topic, happy to discuss more details of
findings on this forum or outside of it

Best regards


----- Oorspronkelijk bericht -----
Van: "Michael MC<ller-Hillebrand mmh@xxxxxxxxx"
Aan: "xsl-list@xxxxxxxxxxxxxxxxxxxxxx" <XSL-List@xxxxxxxxxxxxxxxxxxxxxx>
Verzonden: Vrijdag 29 april 2016 20:05:07
Onderwerp:  BIDI problem in XSL-FO

Dear experts,

The processing done by an FO formatter for right-to-left (RTL) languages is
nearly magic, considering what happens if you just set


I really enjoy my first project with Arabic text. Interestingly the problem at
hand are English words. In the glossary of an RTL document I suddenly have a
full paragraph full of latin characters:

<fo:block>Brand name (Former name)</fo:block>

This is visually rendered like this:

(Brand name (Former name

I have looked at

* Unicode BIDI Processing <http://www.w3.org/TR/xsl/#d0e4879>
* Unicode BIDI algorithm <http://www.unicode.org/reports/tr9/>

I now understand that there are strong and weak characters. The sequence of
strong Latin characters with embedded 'weak' spacing and punctuation is
rendered LTR, the closing 'weak' parenthesis is treated as RTL, because this
is the default orientation of the paragraph.

My first idea is to add <fo:bidi-override direction="ltr"> to each block or
maybe only each text node that consist of solely non-Arabic characters. I
guess this could be done using a regular expression like

not(matches($text, '\p{Arabic}'))

Do you have any other recommendations or best practices?


- Michael

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.