This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10242 - Bidirectionality in bookmark titles
Summary: Bidirectionality in bookmark titles
Status: NEW
Alias: None
Product: XSLFO
Classification: Unclassified
Component: XSL-FO (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Tony Graham
QA Contact: Mailing list for comments on XSL (XSl-FO)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-27 22:23 UTC by G. Ken Holman
Modified: 2010-08-02 14:05 UTC (History)
0 users

See Also:


Attachments
Screen shot of canvas and bookmark pane (13.51 KB, image/png)
2010-08-02 14:04 UTC, G. Ken Holman
Details

Description G. Ken Holman 2010-07-27 22:23:05 UTC
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
Comment 1 Tony Graham 2010-08-02 09:26:36 UTC
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
Comment 2 G. Ken Holman 2010-08-02 14:04:37 UTC
Created attachment 904 [details]
Screen shot of canvas and bookmark pane
Comment 3 G. Ken Holman 2010-08-02 14:05:22 UTC
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).