Page 1 of 1

Controlling bi-directional text output in PDF publishing

Posted: Sun Jan 10, 2016 4:25 pm
by BobbyG66
We have just started working with Arabic and have issues with text direction.
We have our Arabic font installed and able to publish PDF's but have a few issues.
Items like phone numbers and some bookmap metadata is reversed.
These should be reading left to right.

Are there settings for the XSL-FO to control these, are do we format the XSL files to over ride them?

We were just able to fix our address, each element read left to right, but the zip code was first, then state, town, street...
Here is the code we used.

Code: Select all

<fo:bidi-override unicode-bidi="bidi-override" direction="ltr">
<fo:inline><xsl:value-of select="concat(normalize-space(//bookmeta/authorinformation/organizationinfo/addressdetails/thoroughfare),', ')"/></fo:inline>
<fo:inline><xsl:value-of select="concat(normalize-space(//bookmeta/authorinformation/organizationinfo/addressdetails/locality/localityname), ', ')"/></fo:inline>
<fo:inline><xsl:value-of select="concat(normalize-space(//bookmeta/authorinformation/organizationinfo/addressdetails/administrativearea), ' ')"/></fo:inline>
<fo:inline><xsl:value-of select="concat(normalize-space(//bookmeta/authorinformation/organizationinfo/addressdetails/locality/postalcode),'')"/></fo:inline>
</fo:bidi-override>
Do we just continue to add these overrides where ever we need them?

Thanks
Bob

Re: Controlling bi-directional text output in PDF publishing

Posted: Sun Jan 10, 2016 4:33 pm
by BobbyG66
The code edit above was made to this file.
DITA-OT1.7.5/plugins/org.company.pdf2/cfg/fo/xsl/static-content.xsl

Re: Controlling bi-directional text output in PDF publishing

Posted: Mon Jan 11, 2016 11:05 am
by Dan
Yes, you need to control the direction of the static content you generate using the fo:bidi-override elements.

But I would use "embed" instead of "bidi-override", it works better in case you have city names or other meta information in Arabic or/and English. (The "bidi-override" is so strong it will reverse the glyphs from the arabic names):

Code: Select all


<fo:bidi-override unicode-bidi="embed" direction="ltr">

Re: Controlling bi-directional text output in PDF publishing

Posted: Tue Jan 12, 2016 4:52 am
by BobbyG66
Thanks Dan,

I used the "embed" in the code string.
All seems good.

Thanks
BG66

Re: Controlling bi-directional text output in PDF publishing

Posted: Thu Jan 14, 2016 5:50 pm
by BobbyG66
We now have an issue with trademark info in our book map.
The trademark content is similar to this.
This product is trademarked by Amazing Widgets Inc.
The Arabic text is formatted correctly, but the company name appears as
Inc. Widgets Amazing
How do we control text as part of a sentence?
Can it be set up as a variable and direction set there?

Thanks
BG66

Re: Controlling bi-directional text output in PDF publishing

Posted: Fri Jan 15, 2016 10:43 am
by Dan
Hard to tell without seeing the generated markup...
Maybe you can provide an fragment of DITA and FO markup, so we can get a clearer picture.

I tried to put the company name in the middle of an Arabic text and it reads ".Amazing Widgets Inc" (the dot is BIDI neutral and it goes to the first position).

Maybe you have a fo:block (the paragraph) with direction right-to-left, and then inlines with direction left to right for each of the three words from "Amazing Widgets Inc". I think that only in this situation you get that arrangement.

Can you wrap the company name in a "ph" element with dir='ltr'?

For more details about how you can control BIDI text, see: https://www.w3.org/International/questi ... i-controls

Re: Controlling bi-directional text output in PDF publishing

Posted: Mon Jan 18, 2016 9:56 pm
by BobbyG66
Thanks Dan, good info.
Tried wrapping in a phrase tag and adding these attributes:
dir=ltr
dir=lro
xml:lang=en-US

With no success.

Here is the code:

Code: Select all

<p id="ph_disclaimerFooter"><b>إخلاء المسؤولية</b>: لا تقدم <ph dir="lro" xml:lang="en-US">Amazing Widgets, Inc.</ph> أي بيانات أو ضمانات بشأن محتويات هذا الدليل. ونحن نحتفظ
بحق مراجعة هذا المستند في أي وقت وإجراء تغييرات على المنتج الموصوف داخله بدون أي إشعار أو
إلزام بإخطار أي شخص بمثل هذه المراجعات أو التغييرات.</p>
We are also having an issue with part numbers.
If there is a mix of Alpha Numeric, the part numbers splits at the first Alpha character.
And part numbers with two dashes in them or phone numbers are reversed.

Thanks
BG66

Re: Controlling bi-directional text output in PDF publishing

Posted: Wed Jan 20, 2016 12:26 am
by BobbyG66
Here are more details about the part numbers we are having issues with.

Part numbers such as: PL-17209, BK030201, DE000004-X, K50A1-106 are good.
Part numbers like these are reversed:
12090-322 = 322-12090
50A1-999-X = A1-999-X50
50A1-369 = A1-36950

Not sure why they are doing this.
Where and how in the XSL-FO is this controlled?

Thanks
BG66

Re: Controlling bi-directional text output in PDF publishing

Posted: Wed Jan 20, 2016 10:40 am
by Dan
Hi,
I still cannot reproduce your problem with the oXygen default settings. This is my setup:

1. I used the 'samples/dita/it-book/taskbook.ditamap'
2. I opened the map, then I opened the 'installing.dita' topic. I switched to 'Text mode' and pasted your paragraph before the first one from the topic.
3. I checked in the Preferences/Options/DITA/ the 'Builtin DITA-OT 1.8'
4. Then I used the DITA Map transformation scenario 'DITA Map PDF'
5. The PDF has the BIDI text in the correct order.

Other hints:
- check this in a new oXygen installation (there might be some XSLT customizations in you current installation that break the PDF publishing)
- try specifying xml:lang="ar" on the root of the bookmap, or on the root of the first topic.

If you do not succeed with this, try creating a small map with a couple of topics exhibiting the problem.
After that transform it with 'DITA Map PDF' transformation scenario, but this time setting the parameter 'clean.temp' on 'no'.
Archive the entire folder containing the map, topics and temporary files and send it to the oXygen support by using this form:
'https://www.oxygenxml.com/techSupport.html'.
We will take a look at it.

Cheers,
Dan