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

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 11:52:07 UTC