This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: bidi [was: DocBook Technical Committee Meeting Minutes:18 Feb 2003]
At 15:41 2003 02 19 +0100, Yann Dirson wrote:
>On Wed, Feb 19, 2003 at 08:19:20AM -0600, Paul Grosso wrote:
>> At 21:38 2003 02 18 -0600, Paul Grosso wrote:
>>
>> >My very untutored understanding is that there are two key branches here:
>> >
>> >1. There is markup delimiting the language change--whether it is
>> > specifically markup to "change language" or it is other markup
>> > such as "foobar-number" whose content is known to require a
>> > direction change (e.g., numbers in Hebrew are written left-to-right).
>> >
>> > In this case, there is nothing more we need in the DTD.
>>
>> Actually, I mispoke here. What we should probably do is
>> add a "direction" attribute to the <phrase> element in
>> a fashion somewhat parallel to what HTML allows [1]. I
>> think <phrase> can be used for this purpose, but I suppose
>> we could add a "bidi" element (along the lines of HTML's
>> bdo element [2] or XSL-FO's bidi-override element [3]) if
>> we don't wish to use <phrase>. Note that this element needs
>> to be able to nest within itself.
>
>Is that necessary ? Isn't possible to infer the writing direction
>from the value of the "lang" attribute, without adding anything new ?
I don't think so. Note at [1] that:
User agents must not use the lang attribute to determine text directionality.
>For special cases like the Hebrew numbers, what about going more
>semantic and provide a "number" element ?
I don't believe we can/should make "semantic" elements for all sorts
of things like this, though certainly someone could put role="number"
on a phrase element if they so desired and have the stylesheet key in
on that to change the direction.
The fact is that both HTML and XSL-FO have a "bidi" element and a
"direction" attribute/property. We could check with the W3C I18N folks
to see if they wish to provide a suggestion, but it looks to me like
our target output formats both support such elements and attributes,
so it probably makes sense for our DTD to do likewise.
paul