W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css3-text] Issues that need i18n help

From: Amir E. Aharoni <amir.aharoni@mail.huji.ac.il>
Date: Fri, 14 Jun 2013 11:33:23 -0700
Message-ID: <CACtNa8uSN1A4ZMNSdgbfbN2fhpDmZVJLjqiysR01p2O6jf9fgQ@mail.gmail.com>
To: Najib Tounsi <ntounsi@emi.ac.ma>
Cc: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, fantasai <fantasai.lists@inkedblade.net>, WWW International <www-international@w3.org>, "www-style@w3.org" <www-style@w3.org>
Putting space between Arabic letters doesn't make much sense. The
Kashida technique should probably be used for this, and CSS already
has some support for it. Best of all, it should be used automatically
for text in an Arabic script.

Consulting from somebody who knows Arabic typography better that I do
is needed here, of course.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬


2013/6/14 Najib Tounsi <ntounsi@gmail.com>:
> Hello all,
>
> A positive (e.g. 1em) letter-spacing in Arabic looks the same in all
> browsers (according to spec?) as for the Latin languages. But in Arabic
> writing system, letters are joined. So it doesn't look good, thought it's
> still readable:  ﻏ ر ﻳ ﺐ  vs.  غريب
>
> As for the Latin languages, negative space (e.g. 1px), may "tight" the
> letters a bit, but beyond, it becomes an unreadable jam.
>
> So, okay to say that the property is undefined for some contexts or some
> languages. Or that a negative value doesn't make sense.
>
> Regards, Najib
>
>
> On 6/14/13 12:51 PM, "Martin J. Dürst" wrote:
>>
>> On 2013/06/14 20:18, fantasai wrote:
>>
>>> Issue 4: The 'letter-spacing' property as currently implemented puts
>>> space between Arabic letters. Does this make sense? Should there be
>>> some other behavior instead (e.g. suppressing letter-spacing)?
>>> http://dev.w3.org/csswg/css-text/#letter-spacing
>>>
>>>
>>> data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw%2BDQo8cCBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IDFlbSI%2B2qnZhduMINmG2YjYtNiq2YbZhiDYudix2KjbjA%3D%3D
>>
>>
>> Hello Fantasai,
>>
>> I think you know much more about the Arabic script than most of us, so I'm
>> a bit surprised to get such a question. The spaced Arabic from the above
>> data URI, at least to me as an outsider, looks quite wrong. At the minimum,
>> I would expect the letters to stay connected where they are connected.
>>
>> As far as I remember, on first approximation, a kashida/tatweel (longer
>> coursive connection) would be used in certain positions in a word to deal
>> with superfluous space on a line (when trying to justify). But better
>> typography would probably be much more complex.
>>
>> I seem to remember that years ago, there was a proposal to have a property
>> relating to kashida/tatweel. Maybe it was something like how much of the
>> slack space would go to spaces between words and how much would be absorbed
>> by kashidas, in terms of percentages.
>>
>>
>> Anyway, I think the more general problem here is how to move on with specs
>> where we know that something isn't correct, or isn't culturally appropriate,
>> or isn't optimal, but it may take years for browser implementers to improve
>> their implementations.
>>
>> Ideally, we could say in the spec that a certain property is (currently)
>> undefined in a certain context, and that would mean it wouldn't be tested,
>> and the spec could move on, and in a later version, once some
>> implementations got advanced and we have better ideas what to do, we could
>> specify that case, too. But the danger is that we get content that relies on
>> unspecified stuff.
>>
>> Another alternative is to specify something as applying to all cases (if
>> that's what the implementations do currently), and in a later spec define
>> another property (let's say cancel-letter-spacing-for-cursive-scripts, with
>> no as the default and yes (and inherited) as two other values) as a fix.
>>
>> Of course the problem is much smaller if it's easy to fix the
>> implementations.
>>
>> Regards,   Martin.
>>
>>
>
>
Received on Friday, 14 June 2013 18:34:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC