OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [docbook-tc] bidi override thoughts


At 18:45 2002 08 20 -0400, Norman Walsh wrote:

>|    573419 Add bidirectional text overrides
>
>Add bdo everywhere?
>
>ACTION: Paul to investigate what the content model needs to be and why simply
>        using a nested phrase is insufficient.

XSL-FO discusses BIDI concepts at [1].

(By the way, the maximum nesting of direction changes is 61!)

Most of the discussion in this section has to do with character-level
BIDI switching, so it is less relevant to the case at hand.  However,
it does say:

  As defined in [UNICODE UAX #9], the Unicode BIDI algorithm takes a
  stream of text as input, and proceeds in three main phases: 

      1.  Separation of the input text into paragraphs. The rest of
        the algorithm affects only the text between paragraph separators. 

       . . .

This implies that any bidi-override would only occur within paragraphs.
However, it is unclear what Unicode means by "paragraphs."

XSL-FO defines the fo:bidi-override formatting object [2].
Its "content model" is (#PCDATA|%inline;|%block;)* which pretty
much allows everything.  fo:bidi-override itself is part of %inline.

I think this translates into DocBook as allowing bidi-override 
as part of %para.char.mix; and giving it a content model of
(%para.char.mix;)*.

If so, then I note that phrase is defined as part of %gen.char.class; 
which is part of %para.char.mix; and that the declaration for phrase is:

<!ELEMENT phrase (%para.char.mix;)*>

It sure sounds like this would allow us to use phrase to signal 
bidi-override if that's what we want to do.

The phrase element currently has common attributes and a role attribute.
That appears to leave us the option of just using the role attribute
to trigger bidi-override or adding another attribute especially for
triggering the bidi-override semantic.  I don't think there is any
need for further options to bidi-override, so if we add a new attribute,
it would just be a "boolean" attribute.

paul

[1] http://www.w3.org/TR/xsl/slice5.html#section-N6720-Unicode-BIDI-Processing
[UNICODE UAX #9] http://www.unicode.org/unicode/reports/tr9/
[2] http://www.w3.org/TR/xsl/slice6.html#fo_bidi-override



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC