[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] BIDI problem in XSL-FO


Subject: Re: [xsl] BIDI problem in XSL-FO
From: "Geert Bormans geert@xxxxxxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 29 Apr 2016 21:41:57 -0000

Hi Michael,

It is late on a Friday here, so I ll keep my post very brief
(an excuse for not exactly brief but rather unstructured :-)
Over the past couple of months I have been tackling quiet a few issues similar
to what you describe.
The visual rendering "(Brand name (Former name" is often the correct
behaviour, but I learned from Arabic proof readers it is not pleasing anyway

The brackets around English text are one infamous known issue
another one I had issues with is registered trademarks appearing randomly
before or after an english word.
And keeping 1-25 as page number in the footer for chapter-page numbering
instead of 25-1 has been hard too

The algorythms for switching rtl and ltr are complex and although there is
very good support in some FO processors,
behaviour is not always predictable

We learned there is an advantage in creating inner context to tune the
algorythms our way
our documents are DITA, so I pulled the DITA files out of the CMS and added a
<term> element context around english text in arabic
but ONLY when there are potential issues (cases are rather isolated so if
there are no brackets eg. just leave the english text as it is in order to not
make mistakes)
We had cases like this
"A arrow B"
no arabic characters in there
in arabic the result needed to show
"B flipped arrow A"
That will not happen correctly if you create your bidi override to large (your
suggested regex would break this example)

from learning the hard way: advice no 1: be conservative in creating bidi
overrides because most often the FO processor does the right thing

I am revising my regular expressions over the next week or two because of
toolset version changes


Current Thread