RE: For review: Creating SVG Tiny Pages in Arabic, Hebrew and other Right-to-Left Scripts

Thanks, Mati, for the excellent feedback.

Responses below.

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

> From: Matitiahu Allouche [mailto:matial@il.ibm.com]
> Sent: 09 December 2008 08:38

> 1) In section "Be logical, not visual", "Nowadays almost all text on the
Web
> in in logical order." => "Nowadays almost all text on the Web is in
logical
> order."

Fixed.
 
> 2) In the example titled "Changing the direction of a text element.",
>    a)There is no code accounting for the display of "525520" on the last
> line. This is also true for the later example based on this one, titled
> "Script is not significant for text-align.".
>    b) We find the statement:  "Without the direction property, the text
> "(ISOC-IL)" would, incorrectly, appear on the right side of the line, as
> would the number on the second line."  This is not true concerning the
> "second" line (I assume this is the line containing the number 7).  A
number
> following Hebrew or Arabic text will always be considered by the Unicode
> Bidi Algorithm as being part of a RTL run and will be displayed on the
left
> side of the preceding text.

I have changed these examples.  Many thanks for your help with the Hebrew
translation !

 
> 3) In example "text-align set to start for RTL text", the use of Nastaliq
> font might be quite pleasing on the eyes, but makes comparing the
displayed
> text with the source text quite difficult for readers not proficient in
> Arabic.  I suggest to keep the font used for final display identical or
> reasonably similar to the one used for showing the source.

Changed. (sad to do so, but you're right)

 
> 4) In section "Bidi algorithm basics", we find: "The context is taken from
> the directionality set on the nearest parent element that set the
direction.
> In SVG this may have been set explicitly by using the direction property,
or
> it may be inherited from the default directionality of the svg tag, which
is
> LTR."
> It is somewhat confusing since the first sentence addresses setting the
> direction explicitly while the second sentence mentions inheriting a
> default.  I suggest the following rewording.
> "The context is taken from the directionality set on the nearest parent
> element that sets the direction explicitly by using the direction
property,
> or, in the absence of such a parent, it is inherited from the default
> directionality of the svg tag, which is LTR."

Wording adopted, with tweaks. Thank you.

 
> 5) We find:  "The really interesting part comes when a space or
punctuation
> falls between two strongly typed characters with different directionality.
> In such a case the neutral character, or characters, will be treated as if
> they have the directionality of the overall paragraph or context. This has
> the effect of creating a boundary between directional runs."
> This is not quite precise, since what creates the boundary is not the fact
> that neutral characters are treated according to the paragraph
> directionality.  The boundary is there because there are two strongly
typed
> characters with different directionality.
> I suggest to remove the sentence "This has the effect of creating a
boundary
> between directional runs."  If the notion of boundary is important, it
could
> be mentioned in relation with the "two strongly typed characters with
> different directionality".

Yes, I see what you mean.  Changed to:
The really interesting part comes when a space or punctuation falls between
two strongly typed characters with different directionality, ie. at the
boundary between directional runs. In such a case the neutral character, or
characters, will be treated as if they have the directionality of the base
direction.

 
> 6) We find: "(Note, however, that in this particular case, it may be
better
> to use the markup. This is because some markup ought to be there already,
> so
> that you can label the quotation as being in Arabic using xml:lang="ar".)"
> The relevance of using xml:lang="ar" to the matter is not clear. On the
> contrary, it could suggest that specifying the language would have an
effect
> on the problem at hand, namely how to correctly position the exclamation
> mark, which is not true. I suggest to remove the mention of xml:lang.

Changed to:
If there is already markup around the quotation, it probably makes sense to
just use direction on that, rather than the control character. Otherwise it
may be easier to use the control character.

 
> 7) We find: "the bidirectional algorithm sees the neutral comma as part of
> the Arabic text. It is interpreting the first two arabic words and the
comma
> as a list in Arabic. In fact the comma is part of the English text"
> The text mentions only the comma and ignores the adjacent space which
> illustrates exactly the same case.  Either remove the space from the
> example, or mention the space in the explaining text.

I added a note:
* Actually the space adjacent to the comma is also a neutral character, and
is treated in the same way as the comma, although we only mention the comma
in the text for the sake of simplifying the explanation.

 
> 8) In section "Mirrored characters", we find: "This means that, whether
> inputting content in Arabic/Hebrew or Latin script, you would use the same
> LEFT PARENTHESIS character at the beginning of the parenthesized text."
> This might be misleading: in many environments, input methods swap the
> parentheses when using the keyboard to enter Arabic or Hebrew, so that to
> input an opening parenthesis the user presses the Right Parenthesis key. I
> suggest to replace the reference to inputting content by a reference to
how
> the content is stored.

Changed "whether inputting content in" to "whether the stored content is in"

 
> 9) In the table listing Unicode control characters, the value of
> unicode-bidi for RLO and LRO should be "bidi-override".

Fixed.

 
> 10) In the whole document, the word "context" is used with different
> meanings: in most occurrences, it designates the direction set by using
> direction="xxx" or inherited from a parent component. In other
occurrences,
> especially in section "Mirrored characters", it designates the direction
> implied by neighbouring characters.
> I suggest to replace the terms "context" and "overall context" (first
> meaning) by "base direction", leaving the term "context" when used with
the
> second meaning.  Together with this first suggestion, or independently if
> the first suggestion is not accepted, I suggest to add the word "local"
> (giving "local context") when the word context is used with the second
> meaning.

I gave this a lot of thought, and then made a substantial number of edits to
the text.  End result, I use 'base direction', as you suggest, after trying
to make clear what that means (not typically done in other places).  I still
use the word 'context' occasionally, but in a more general sense than
before.  Thanks for pushing me to get that looked at.

New version uploaded at
http://www.w3.org/International/tutorials/svg-tiny-bidi/

Thanks,
RI

Received on Tuesday, 9 December 2008 17:19:32 UTC