Bidi

J.Pietschmann

XSLFO supports Unicode BIDI. Check out the BIDI properties of the arrow, if it's mirrored, it will flip automatically in a rl writing mode context. I suspect it isn't mirrored though. The properties can be found here

I'm generating index entries for Arabic documents (using XSL Formatter 2.3) and I'm running into a problem with the how the bi-di algorithm is being applied. I can solve the problem by adding a bidi-override element to the output FO but that solution is not ideal because it would mean adding markup to the input XML document, which I would like to avoid.

Here is a typical example:

<fo:block-container writing-mode="rl-tb">
<fo:block >Arabic English1 English2<fo:leader 
leader-length="1em">123</fo:block>
</fo:block-container>

The desired presentation result is:

But what I get from XSL Formatter is:

That is, the "<fo:leader>123" is taken as part of the left-to-right sequence, which I think is correct application of the Unicode bi-di algorithm.

I'm wondering if there is a Unicode control character of some sort that I can interject into the output to end the recognition of the left-to-right text (as though a normal Arabic character occured after the English text)? I looked through the Unicode database as presented by Unipad but I didn't see anything that looked like what I want.

I guess another question would be does FO define any markup that I could wrap around the entire index entry text (but not including the page number citation) that would also have the defined semantic of limiting the scope of the bidi recognition? I have tried putting a bidi-override around the leader (between the index entry text and the page number citation to no effect) but it does not produce the desired effect.

I am continuing to work with Antenna House support on this issue but I was hoping there might be an easy solution that wouldn't require more work on anyone's part.

Answer:

What is the difference, and why?

Eliot answers: If the numbers are literal, they are included in the left-to-right sequence. If generated by page-number-citation, then they are not. I would expect the same behavior in both cases.

See UAX #9, The Bidirectional Algorithm, or Section 3.12, Bidirectional Behavior, of the Unicode Standard, Version 3.0. They're also covered in Chapter 6 of "Unicode: A Primer".

Section 5.8, Unicode BIDI Processing, of the XSL 1.0 Recommendation describes the behavior of the "direction" and "unicode-bidi" properties in terms of RLO/LRO and RLE/LRE.

Mixing markup and the formatting control characters is asking for trouble. LRM and RLM do what you want -- i.e., they force the directionality of neighbouring characters, such as numbers, that have only "weak" inherent directionality. However, here's what the HTML 4.0 Recommendation says about mixing markup and formatting control characters:

If both methods are used, great care should be exercised to insure proper nesting of markup and directional embedding or override, otherwise, rendering results are undefined.

Tokushige Kobayashi

Yes

Unicode Bidi only determines the directionality of characters. By default, Arabic Characters are written from right to left, Latin characters are written from left to right.

When Arabic characters are positioned in a block which is in a lr-tb reference area, start of block is still left. An Arabic word is positioned at left in a line.

Please refer to XSL-FO Spec. 5.3 Computing the Values of Corresponding Properties.

For example, If the "writing-mode" specifies an inline-progression-direction of "left-to-right": "left" maps to "start".

As a result, you must wrap Arabic paragraphs in fo:block-container which has a property of writing-mode="rl-tb". (not tb-rl)

In my understanding, XSL Formatter does not change the behavior for writing-mode.