Re: DOCBOOK: Re: bidi override thoughts

[Paul Grosso <pgrosso at arbortext dot com>]

At 07:14 2002 08 22 -0400, Norman Walsh wrote:
>/ Tony Graham <Tony.Graham@Sun.COM> was heard to say:
>| Norman Walsh wrote at 21 Aug 2002 16:57:19 -0400:
>|  > Well, for consistency with HTML, and so that moving something from one
>|  > context to another doesn't inadvertantly "flip" the direction, I think
>|  > I'd be inclined to give it values of "left-to-right" and
>|  > "right-to-left" rather than just make it boolean.
>|
>| So you're really talking about setting the text direction, not about
>| overriding the behaviour of the Unicode Bidirectional Algorithm?
>
>Can you tell me how those two things are different?
>
>| Isn't "dir" or "direction" a better name than "bdo"?
>
>Well, yeah, naturally :-)
>
>| If it really is an override, what sets the existing text direction
>| that you're overriding?
>
>It's set implicitly by the language of the containing block?
>
>My understanding, which could easily be so totally wrong as to cause
>hysterical laughter among those who do understand, is that you
>sometimes have to switch writing direction without changing languages
>(e.g., arabic numerals in hebrew text). Unicode has override
>characters for this purpose, but the Unicode Consortium deprecates
>their use in XML, preferring to use an element for this purpose.


Tony's post makes me realize that I don't understand this either.
Also, that I failed to complete my research.

Specifically, XSL-FO has a bidi-override FO, so that should have
led me to two questions:

1.  Given XSL-FO also has fo:inline and fo:wrapper, why did XSL-FO
    feel it needed an explicit fo:bidi-override?  If I knew the answer
    to this, it might shed light on whether DocBook should.  But I
    don't know the answer.

2.  How--especially with what attributes--does fo:bidi-override work?

I discovered I don't really understand this either.  Some quotes:

  The fo:bidi-override formatting object ... forces a string of text
  to be written in a specific direction....

  The direction traits are derived from the "writing-mode", "direction",
  and "unicode-bidi" properties....

These three properties are all part of "writing mode related properties"
described at [1], and these were apparently all inherited from CSS.

The direction property takes values of left-to-right and right-to-left
(well, ltr and rtl because this was inherited from CSS--funny time for 
CSS to get terse, if you ask me).

  This property specifies the base writing direction of blocks and the
  direction of embeddings and overrides....

  For the 'direction' property to have any effect on inline-level elements,
  the 'unicode-bidi' property's value must be 'embed' or 'override'.....

  The specific use of "direction" and "unicode-bidi" on inline objects is
  to set the inline-progression-direction to be used by the Unicode BIDI
  algorithm. This direction may override the inline-progression-direction
  determined by the current writing-mode and the implicit direction
  determined by the Unicode BIDI algorithm.

  To insure consistency with the "writing-mode" property, the "direction"
  property is initialized to the value that sets the same 
  inline-progression-direction as is set by the "writing-mode" property
  whenever that "writing-mode" property sets that direction. If the
  "direction" property is explicitly specified on the same formatting
  object the value of the "direction" property will override the
  inline-progression-direction set by the "writing-mode"....

The unicode-bidi property has values of normal, embed, bidi-override.
I will quote the meanings of embed and bidi-override, but I have no
idea what they are saying:

embed 

  If the element is inline-level, this value opens an additional
  level of embedding with respect to the bidirectional algorithm. The
  direction of this embedding level is given by the 'direction'
  property. Inside the element, reordering is done implicitly. This
  corresponds to adding a LRE (U+202A; for 'direction: ltr') or
  RLE (U+202B; for 'direction: rtl') at the start of the element and a
  PDF (U+202C) at the end of the element. 

bidi-override 

  If the element is inline-level or a block-level element that contains
  only inline-level elements, this creates an override. This means that
  inside the element, reordering is strictly in sequence according to
  the 'direction' property; the implicit part of the bidirectional
  algorithm is ignored. This corresponds to adding a LRO (U+202D; for
  'direction: ltr') or RLO (U+202E; for 'direction: rtl') at the
  start of the element and a PDF (U+202C) at the end of the element. 

I guess I can conclude that this area is more complex that I thought
and that I'm at the end of my expertise here.

paul



[1] http://www.w3.org/TR/xsl/slice7.html#writing-mode-related