This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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
Created attachment 904 [details] Screen shot of canvas and bookmark pane
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 "إختبا"> <!ENTITY arabic-test2 "ر عربي"> <!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).