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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: RE: [dita] [dita-translation] TC/DITA/Translation Subcommittee Proposals


Hi Bruce,

Here's how it works:

1. The Unicode standard defines a default direction for each language. For
example, for English this default direction is LTR and for Hebrew it's RTL.

2. When embedding a RTL text run inside a LTR text run (or vice-verse), the
default direction often provides incorrect results, especially if the
embedded text run includes punctuation that is located at one end of the
embedded text run. Unicode defines spaces and punctuation as having neutral
directionality, and defines directionality for these neutral characters when
they appear between characters having a strong directionality (most
characters that are not spaces or punctuation). While the default direction
is often sufficient to determine the correct directionality of the language,
sometimes it renders the characters incorrectly (for example, a question
mark at the end of a Hebrew question may appear at the beginning of the
question instead of at the end). To control this behavior, the dir attribute
is set to "ltr" or "rtl" as needed, to ensure that the desired direction is
applied to the characters that have neutral bidirectionality. The "ltr|rtl"
values override only the neutral characters, not all Unicode characters.

3. Sometimes you may want to override the default directionality for
strongly bidirectional characters. This is done using the "lro" and "rlo"
values, which overrides the Unicode directionality algorithm. This
essentially forces a direction on the contents of the element, ignoring the
direction interpreted from any xml:lang setting. These override attributes
give the author a brute force way of setting the directionality
independently of the Unicode BIDI algorithm. The gentler "ltr|rtl" values
have a less radical effect, only effecting punctuation and other so-called
neutral characters.

For most authoring needs, the "ltr" and "rtl" values are sufficient. I have
found that there is not often a need to override the Unicode directional
algorithm under normal circumstances, but we should support them since W3C
standards include them.

Hope this clarifies things!

Best Regards,
Gershon

-----Original Message-----
From: Esrig, Bruce (Bruce) [mailto:esrig@lucent.com] 
Sent: Tuesday, March 14, 2006 4:41 PM
To: 'JoAnn Hackos'
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] [dita-translation] TC/DITA/Translation Subcommittee
Proposals

What do the values stand for? LRO, RLO?

The XSL-FO writing-mode property accomodates the direction in which lines
accumulate, in addition to the direction in which the text accumulates
within a line.

http://www.w3.org/TR/2006/CR-xsl11-20060220/
http://www.w3.org/TR/2006/CR-xsl11-20060220/#d0e373
http://www.w3.org/TR/2006/CR-xsl11-20060220/#writing-mode

So, for example, you can specify top-to-bottom within a line, with
right-to-left accumulation of lines.

Best wishes,

Bruce Esrig

-----Original Message-----
From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
Sent: Tuesday, March 14, 2006 9:26 AM
To: dita@lists.oasis-open.org
Subject: [dita] [dita-translation] TC/DITA/Translation Subcommittee
Proposals

From: JoAnn Hackos, chair DITA/Translation Subcommittee 
 
The DITA/Translation Subcommittee approved the following proposals to the
DITA TC on March 13, 2006.
 
DIR Attribute
Proposal: That the DITA 1.1 specification include the DIR attribute as a
universal attribute with the values of LTR, RTL, LRO, and RLO. No default
value is to be specified for the DITA DTD.
 
Discussion: The DIR attribute is used by authors of languages such as Hebrew
and Arabic to ensure that correct directionality on the output, especially
when the standard directionality has to be modified to accommodate some
special use of the language. The reason to include it is to ensure that
tools for authoring and for transforms generate the correct directionality.
There was discussion that the results of this would often be unpredictable
and produce different effects for different browers. The SC will now work on
a statement of best practices for authors and tools vendors to develop a way
to handle the dir attribute properly.
 
Ruby Attribute/element
Proposal: That the Subcommittee postpone any consideration of ruby enable
until there is an appropriate mechanism (e.g., a specialization of the
<keyref> attribute or a recommendation from the ITS working group of the
W3C) to enable it in the DITA DTD.

Discussion: The ruby attribute/element is used in some languages to provide
an annotation indicating how certain characters should be pronounced. It is
used in Japanese textbooks to guide a reader in the pronunciation of lesser
known characters. At present, we have not received a specific request to
enable ruby and the ITS working group has not yet completed its draft
recommendation. The SC believes it is better to wait until we have a means
to enable this attribute before making a recommendation to the TC. We hope
to reconsider this proposal for the DITA 1.2 specification.

Xml:lang Attribute
Proposal: That the DITA 1.1 specification maintain the xml:lang attributed
as currently specified in DITA 1.0. That specification stated that xml:lang
values are validated by RFC3066 or its successors.

Discussion: A considerable discussion on this attribute has occurred over
several weeks, because of the potential problems with specifying its value
correctly. Because DITA DTD does not specify what values are correct, it's
possible that authors could enter incorrect values. The correct values are
in the RFC3066. The best practice discussion now centers on recommending
that xml authoring tools or CM systems provide standard lists of values from
which authors can choose. For example, authors should correctly enter a
combination of language and locale as
follows: fr-fr or fr-ca specifies French or French Canadian.


 
 

JoAnn 

JoAnn T. Hackos, PhD
President
Comtech Services, Inc. 
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
joann.hackos@comtech-serv.com
http://www.comtech-serv.com <http://www.comtech-serv.com/> Skype joannhackos







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