W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 2010

[Bug 10242] Bidirectionality in bookmark titles

From: <bugzilla@jessica.w3.org>
Date: Mon, 02 Aug 2010 14:05:23 +0000
To: xsl-editors@w3.org
Message-Id: <E1Ofvdr-00020w-3D@jessica.w3.org>

--- Comment #3 from G. Ken Holman <gkholman@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;">

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

... 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).

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 2 August 2010 14:05:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:25 UTC