[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: Re: bidi override thoughts
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC