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