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

Hi

On 6/14/13 7:33 PM, Amir E. Aharoni wrote:
> 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.

It may depends on the size of letter-spacing.
And then not all arabic letter join inside a word. Putting Kashida 
instead of space doesn't work in this case.
1- With letter-spacing: ﻏ ر ﻳ ﺐ
2- With 3 Kashidas instead of spaces: غـرـيـب
3- Normal text: غريب
4- With Kashida on purpose: غـريـب

Line 2, there's a spurious character (third one, in the middle between ر 
and ﻳ)
Line 4, only two Kashidas are put, between ﻏ and ر and, and between ﻳ and ب

Regards,

Najib

>
> 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 Saturday, 15 June 2013 13:02:39 UTC