Re: Arabic letters separated by markup

At 03:14 PM 6/13/2005, fantasai wrote:

>Erik van der Poel wrote:
>>[I'm not on the www-style list.]
>>fantasai wrote:
>>
>>>  For characters within the same inline sequence.
>>>
>>>   1. Shaping and joining behavior MUST NOT be affected by element
>>>      boundaries.
>>If the CSS "display" property is set to "none" for a particular element, 
>>then perhaps the characters in adjacent displayable elements should not 
>>be joined to the characters in the "display: none" element.
>>(Maybe you already thought of this, and that is what is meant by "same 
>>inline sequence"?)
>
>No, I hadn't thought of that. But if an element is display: none, then
>for all rendering purposes it is to be treated as if it wasn't there.
>
>>>   4. Obligatory ligatures MUST NOT be broken if the formatting rules
>>>      introduce no extra space between the affected characters, even
>>>      if this means some of the characters are rendered in the wrong
>>>      font or as part of the wrong visual element.
>>Perhaps the spec could say that an implementation MAY honor such things 
>>as a color change (which may not be possible in current font technologies 
>>such as OpenType?)
>
>Of course if the system is somehow capable of honoring both the style
>rules and the ligature formation, it should be allowed to do so. :)
>
>>or MAY instead use the isolated forms of the individual characters. I 
>>don't know whether the obligatory ligature rules should trump the style rules.
>
>Yeah, I'm not too set on this one. But I don't know how critical it is
>for the affected scripts. If the font isn't changing at all, though, then
>the spec should require that the ligature be formed across element
>boundaries. I suspect it might be simpler just to make the exception apply
>even in cases where the font changes.

For what it is worth the following text comes from the XSL 1.0 REC 
concerning when a ligature substitution is to be done. From section 4.7.2 
Line Building:

...substitutions may occur because of addition of hyphens or spelling 
changes due to hyphenation, or glyph image construction from 
syllabification, or ligature formation.

Substitutions that replace a sequence of glyph-areas with a single 
glyph-area should only occur when the margin, border, and padding in the 
inline-progression-direction (start- and end-), baseline-shift, and 
letter-spacing values are zero, treat-as-word-space is false, and the 
values of all other relevant traits match (i.e., alignment-adjust, 
alignment-baseline, color trait, background traits, 
dominant-baseline-identifier, font traits, text-depth, text-altitude, 
glyph-orientation-horizontal, glyph-orientation-vertical, line-height, 
lineheight-shift-adjustment, text-decoration, text-shadow).

This indicates a bias to honoring the author's/user's styling choices over 
ligature formation. I am not sure how well these paragraphs have been 
tested in practice.


>>>   5. Combining characters MUST be rendered as the combined grapheme
>>>      cluster if the system is capable of rendering the combination,
>>>      even if this means some of the characters are rendered in the
>>>      wrong font or as part of the wrong visual element. The combined
>>>      grapheme cluster SHOULD be rendered as part of the base
>>>      character's element, or, in the case of combining jamos, the
>>>      initial character's element.
>>Here again, shouldn't the style rules trump the Unicode rules? Otherwise, 
>>why should we even allow tags to be inserted between such characters?
>
>In this case, I think it's more important for the grapheme cluster to
>be rendered as one unit. An 'a' with an acute accent should have its
>acute accent on top, and a Hangul syllable expressed as individual
>pieces should be presented as its proper syllable block. Breaking
>ligatures like alef-lam looks weird, but it wouldn't be as bad as
>breaking such combinations: alef and lam appear individually quite
>frequently, but combining vowels and diacritics don't.
>
>~fantasai

         Steve
=====================================
Steve Zilles
115 Lansberry Court,
Los Gatos, CA 95032-4710
steve@zilles.org 

Received on Thursday, 16 June 2005 17:30:09 UTC