W3C home > Mailing lists > Public > www-style@w3.org > May 2014

Re: [css-text] I18N-ISSUE-333: 'letter-spacing' and Arabic

From: Richard Ishida <ishida@w3.org>
Date: Fri, 30 May 2014 13:08:35 +0100
Message-ID: <538874C3.4030403@w3.org>
To: Koji Ishii <kojiishi@gluesoft.co.jp>, Jonathan Kew <jfkthame@googlemail.com>
CC: Najib Tounsi <ntounsi@emi.ac.ma>, "Phillips, Addison" <addison@lab126.com>, "CSS WWW Style (www-style@w3.org)" <www-style@w3.org>, www International <www-international@w3.org>
On 23/04/2014 08:58, Koji Ishii wrote:
> On Jan 26, 2014, at 1:30 AM, Jonathan Kew <jfkthame@googlemail.com> wrote:
>
>> While letter-spacing should not break Arabic cursive connection, it probably *should* break optional stylistic ligatures such as lam-meem that some fonts may use by default. Only mandatory ligatures (i.e. lam-alef) that are a fixed requirement of the script's shaping behavior would be expected to be preserved in letter-spaced text.
>
> We have the following text[1]:
>
>> When the effective letter-spacing between two characters is not zero (due to either justification or non-zero computed ‘letter-spacing’), user agents should not apply optional ligatures.
>
> I suppose this clarifies your concern, please let me know if not.
>
> [1] http://dev.w3.org/csswg/css-text/#letter-spacing


Is it really expected that implementations decompose optional ligatures 
when 'stretching' Arabic text? Are we just making assumptions here, or 
is this based on some typographic tradition?

(I know that high end justification systems may create ligatures as part 
of the justification process, but) from what I've seen it doesn't 
necessarily follow to me that there is always a logical first step to 
the stretching of arabic text that dismantles optional ligatures.

I found a couple of examples of widely stretched Arabic text that don't 
decompose the lam-meem ligature in a newspaper I had to hand. I've 
attached a picture of one.

RI









stretch-plus-ligature.jpg
(image/jpeg attachment: stretch-plus-ligature.jpg)

Received on Friday, 30 May 2014 12:09:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:27 UTC