Re: Need for Level Direction Mark

From: Richard Wordingham <richard.wordingham_at_ntlworld.com>
Date: Thu, 22 Sep 2011 22:37:15 +0100

On Sun, 18 Sep 2011 20:21:38 Peter Edberg <pedberg_at_apple.com> wrote:
> On Sep 17, 2011, at 7:24 PM, Richard Wordingham wrote:
>> On Fri, 16 Sep 2011 18:59:47 Peter Edberg <pedberg_at_apple.com> wrote:

>>> However, it does not handle the situation in which the date is part
>>> of other text, and may be preceded or followed by Arabic letters
>>> (with an intervening space); there are layout interactions between
>>> the Arabic letters and adjacent Arabic digits, since the digits are
>>> not treated as being part of a longer sequence due the direction
>>> marks associated with the '/'. This can be solved by placing an LDM
>>> before and after the date, as well as before each '/'. However,
>>> using an RLM LRM sequence before and after the date causes the
>>> spaces around the date to reorder.

>> The interaction between Arabic letters and Arabic digits that are
>> part of the date occurs in a left-to-right embedding. The non-LDM
>> solution in each case is to insert an LRM after the separating
>> space.
 
>> Incidentally, if Arabic digits (AN, not EN) are used, the separators
>> should be terminated by LRM on one side, not by both RLM and LRM.
 
> I am not sure exactly what you are suggesting here. Do you meant just
> the following (in memory order): LRM AN+ '/' LRM AN+ / LRM AN+
> ? If so, that will not lay out correctly in a right-to-left context.

The outer marks are to protect against adjacent R and AN in a
*left-to-right* context:

Storage: ' ' LRM AN1 '/' LRM AN2 '/' LRM AN3 ' ' LRM
LTR resolution: L L AN L L AN L L AN L L
Final embedding level: 00200200200
Display ' ' AN1 '/' AN2 '/' AN3 ' '

The string also has some merit in a right-to-left context:

RTL resolution after R or AN: R L AN R L AN R L AN R L
Final embedding level: 12212212212
Display: ' ' AN3 '/' AN2 '/' AN1 ' ' R/AN

Actually, though, <LRM ' ' AN1 '/' LRM AN2 '/' LRM AN3 ' ' LRM> would
be still better, as that also works if there is a preceding L in an RTL
context.

However, if the text receiving calculated text is directional, I don't
think it unreasonable to require that the receiving text separate
calculated text from elements in the receiving text with the contrary
direction. (In this context, the directionality of AN is contrary
to left-to-right text.) After all, a comma-separated list of Hebrew
words in left-to-right text would naturally be written with a separator
sequence such as <U+002E LEFT-TO-RIGHT MARK, U+002C COMMA, U+0020
SPACE>. The commas are to the left of the spaces.

Therefore, I think it reasonable to require the guarding LRMs
above to be provided as part of the receiving left-to-right text.
Because the date uses Arabic digits, no protection is needed in
right-to-left text. Protection would be needed if the date used
'European' digits, as it presumably would in Persian or Urdu text.
('EXTENDED' ARABIC-INDIC DIGITs are EN!)

Richard.
Received on Thu Sep 22 2011 - 16:42:05 CDT

This archive was generated by hypermail 2.2.0 : Thu Sep 22 2011 - 16:42:07 CDT