[Bug 10242] New: Bidirectionality in bookmark titles

[b***@jessica.w3.org]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10242

Summary: Bidirectionality in bookmark titles
Product: XSLFO
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: XSL-FO
AssignedTo: ***@MenteithConsulting.com
ReportedBy: ***@cranesoftwrights.com
QAContact: xsl-***@w3.org


Please consider allowing <fo:bidi-override> in <fo:bookmark-title>. When
titles are created by a combination of authored content and stylesheet content,
bidi-override embed levels are required in the flow to prevent undesireable
interaction.

For example:

<bookmark-title>2.
&hebrew-test;
(14)</bookmark-title>

Renders differently in the bookmark pane than the following on the canvas:

<block>2.
<bidi-override unicode-bidi="embed">&hebrew-test;
<bidi-override unicode-bidi="embed">
(14)</bidi-override></bidi-override>
</block>

Thanks!

. . . . . . . . Ken

[b***@jessica.w3.org]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10242





--- Comment #1 from Tony Graham <***@MenteithConsulting.com> 2010-08-02 09:26:36 ---
How does your text appear without any fo:bidi-override? Is your problem that
the "(14)" does not appear correctly?

To borrow the example convention of uppercase for RTL and lowercase for LTR
text of UAX #9 [1], if your text, without any markup, is:

2. THE CAR (14)

it would appear as

2. 14) RAC ETH)

See (with Arabic that I can't read instead of Hebrew)
http://unicode.org/cldr/utility/bidi.jsp?a=2.+%D9%85%D8%A7%D8%B1%D9%92%D9%83+%2814%29&p=Auto

The usage recommendation from UAX #9 [2] is embedded marks. With the addition
of a LRM, the example becomes
http://unicode.org/cldr/utility/bidi.jsp?a=2.0+%D9%85%D8%A7%D8%B1%D9%92%D9%83+%28%E2%80%8E14%29&p=Auto

[1] http://www.unicode.org/reports/tr9/
[2] http://www.unicode.org/reports/tr9/#Usage

[b***@jessica.w3.org]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10242





--- Comment #2 from G. Ken Holman <***@cranesoftwrights.com> 2010-08-02 14:04:37 ---
Created an attachment (id=904)
--> (http://www.w3.org/Bugs/Public/attachment.cgi?id=904)
Screen shot of canvas and bookmark pane

[b***@jessica.w3.org]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10242





--- Comment #3 from G. Ken Holman <***@cranesoftwrights.com> 2010-08-02 14:05:22 ---
I can understand the use of embedded marks if I (a) know the direction of my
text and (b) work at the character level. But when using XSL-FO, I don't have
to think of either the direction of text or work with marks at the character
level because as the canvas text of my example shows, I can simply wrap text
from the stylesheet and text from the source file in "embed" layers and the
characters from each are protected from the directions of the other.

In my work last week, I finished all of the logic for my canvas presentation
and moved on to do the bookmark pane. When I simply called the template that
handled the accessing of text, that template was appropriately embedding the
fo:bidi-override constructs as was needed for the canvas. Then the FO
processor correctly rejected the result because fo:bidi-override is not yet
allowed as a child of bookmark title.

So I contrived the example I posted in this report.

Yes, when I use Antenna House (see attachment) with the following:

<!ENTITY arabic-test1 "&#x0625;&#x062e;&#x062a;&#x0628;&#x0627;">
<!ENTITY arabic-test2 "&#x0631; &#x0639;&#x0631;&#x0628;&#x064a;">
<!ENTITY arabic-test "&arabic-test1;&arabic-test2;">
...
<bookmark-title>2.
&arabic-test;
(14)</bookmark-title>
...
<block>2.
&arabic-test;
(14)</block>

<block><bidi-override unicode-bidi="embed">2.
&arabic-test;
<bidi-override unicode-bidi="embed">(14)</bidi-override

</bidi-override></block>

... the first block shows as you say but not as I want:

2. 14) RAC EHT)

... and the second block shows as I want (without me having to think at all
about inserting any direction markers):

2. (14) RAC EHT

... and the Adobe Reader shows the bookmark pane entry as:

(14) RAC EHT .2

... which isn't what I want either.

My thought when filing this report is that <bidi-override> has such a principal
role in expressing the desired interrelationship between characters *below* the
XSL-FO concept of blocks or bookmark titles, that it should be treated as
first-class as <inline>. Yes, I know that only a few <inline> properties are
allowed in the bookmark title, but the principle is set that some
character-level decoration or control is allowed.

If <bookmark-title> allowed <bidi-override> then I wouldn't have to
special-case my code to handle those titles that are mixing stylesheet text
with authored text. Since vendors can get the interpretation of
<bidi-override> to work on the canvas, then hopefully they would also be able
to get that interpretation to work in the bookmark pane, however they do it
(embedded direction markers or whatever).