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

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:00:29 UTC