[css-text] i18n-ISSUE-354: Questions about letter-spacing for Arabic script

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-text] i18n-ISSUE-354: Questions about letter-spacing for Arabic script

r12a
8.2 Tracking: the letter-spacing property
http://dev.w3.org/csswg/css-text/#letter-spacing-property
Editor’s Draft, 20 March 2014

The length value has the description:

"Specifies additional spacing between visually-perceived characters.
Values may be negative, but there may be implementation-dependent limits."

For cursive text the spec says:

"If it is able, the UA may apply letter-spacing to cursive scripts by
translating the total spacing distributed to a run of such letters into
some form of cursive elongation for that run."

Does this mean that if tracking length is set to 1em for a word that is
6 letters long, that the total length of the resulting text will be 6em
plus the letter widths, and that therefore if there are some letters
that are not allowed to elongate the others will elongate wider than
1em? Or does it mean that those letters that can stretch will each
stretch by 1em (possibly resulting in less than 6em overall width)?

If values are negative, does this have any meaning for cursive scripts,
or is it a hint to use ligatures if any are available (which will result
in different effects per font)?

And then there are Arabic font styles that don't elongate, such as
ruq'a. Does the application have to disable letter-spacing if the user
or the device chooses a ruq'a-style font, or is that the responsibility
of the author? It seems that it might be hard for authors to signal what
to do in the case of fallback fonts.



In addition to these questions, I'm also wondering whether the concept
of letter-spacing as one might use for, say, Latin text really applies
for Arabic. For example, elongations are often not uniform even across
the letters that do elongate. (see the example different-elongations.jpg
and doha-airport.jpg) As currently defined, letter-spacing seems to
imply some uniformity across letters where tracking is applied.

What may be more useful for cursive scripts like Arabic is the ability
to specify the overall width of a piece of text, and let the application
produce elongation according to rules to fill that space. Note that this
is different from what I described above (6 letters example) in that the
overall length includes the space taken up by the letters themselves -
it's more like justification.

Most of the stretching I've seen appears to be more concerned with
filling a given horizontal space than ending up with an unpredictable
overall width that is driven by the letters selected.

For example, many signs that include arabic and english make the arabic
and english the same width, one above the other. The degree of
stretching is determined by the overall width, rather than just by
making letters wider.

Even in single-line, non-bilingual situations also it appears to me,
though I admit I'm not certain at all, as if the desired overall width
is often what drives the amount of stretching, rather than the desire to
just have wider characters. See for example the Macdonalds advert attached.

doha-airport.jpg (74K) Download Attachment
different-elongations.jpg (150K) Download Attachment
macdonalds.jpg (408K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [css-text] i18n-ISSUE-354: Questions about letter-spacing for Arabic script

fantasai
On 07/25/2014 07:57 PM, Richard Ishida wrote:

> 8.2 Tracking: the letter-spacing property
> http://dev.w3.org/csswg/css-text/#letter-spacing-property
> Editor’s Draft, 20 March 2014
>
> The length value has the description:
>
> "Specifies additional spacing between visually-perceived characters.
> Values may be negative, but there may be implementation-dependent limits."
>
> For cursive text the spec says:
>
> "If it is able, the UA may apply letter-spacing to cursive scripts by
> translating the total spacing distributed to a run of such letters
> into some form of cursive elongation for that run."
>
> Does this mean that if tracking length is set to 1em for a word that
> is 6 letters long, that the total length of the resulting text will
> be 6em plus the letter widths, and that therefore if there are some
> letters that are not allowed to elongate the others will elongate
> wider than 1em? Or does it mean that those letters that can stretch
> will each stretch by 1em (possibly resulting in less than 6em overall
> width)?

The former.

> If values are negative, does this have any meaning for cursive scripts,
> or is it a hint to use ligatures if any are available
> (which will result in different effects per font)?

This would allow the use of shortening ligatures or contextual forms,
yes.

> And then there are Arabic font styles that don't elongate, such as
> ruq'a. Does the application have to disable letter-spacing  if the
> user or the device chooses a ruq'a-style font, or is that the
> responsibility of the author? It seems that it might be
> hard for authors to signal what to do in the case of fallback fonts.

The application should disable any elongation, yes. It seems unlikely
for a ruqu'a-style font to be a fallback font, however: system fonts
are much more likely to be the newspaper style of writing.

> In addition to these questions, I'm also wondering whether the concept
> of letter-spacing as one might use for, say, Latin text really applies
> for Arabic. For example, elongations are often not uniform even across
> the letters that do elongate. (see the example different-elongations.jpg
> and doha-airport.jpg) As currently defined, letter-spacing seems to
> imply some uniformity across letters where tracking is applied.

No, it just says that you add up the space that would have applied,
and then distribute it in some appropriate way. The idea is to "make
this line feel looser"; how the space is distributed to make it looser
is going to depend, though. But it should end up with text that is
less dense somehow, regardless of script.

The alternative is of course to always ignore letter-spacing applied
to Arabic; but I think the instruction to be "less dense" is worth
preserving if possible, and we might as well let UAs experiment to
see what's useful here.

> What may be more useful for cursive scripts like Arabic is the ability
> to specify the overall width of a piece of text, and let the application
> produce elongation according to rules to fill that space. Note that
> this is different from what I described above (6 letters example) in
> that the overall length includes the space taken up by the letters
> themselves - it's more like justification.

Yes; I'd implement this by

   min-width: 6em;
   text-align: justify-all;
   text-justify: kashida;

Except we don't have that last value yet. :)

(Actually, the right solution is a little more complicated than that
due to the desired fallback behavior. But that's a discussion by itself.)

> Most of the stretching I've seen appears to be more concerned with
> filling a given horizontal space than ending up with an unpredictable
> overall width that is driven by the letters selected.
>
> For example, many signs that include arabic and english make the
> arabic and english the same width, one above the other. The
> degree of stretching is determined by the overall width, rather
> than just by making letters wider.
>
> Even in single-line, non-bilingual situations also it appears to me,
> though I admit I'm not certain at all, as if the desired overall
> width is often what drives the amount of stretching, rather than the
> desire to just have wider characters. See for example the Macdonalds
> advert attached.

I agree. Arabic likes to exploit its "stretch to fill" ability in
graphic design. :)

~fantasai

Reply | Threaded
Open this post in threaded view
|

Re: [css-text] i18n-ISSUE-354: Questions about letter-spacing for Arabic script

r12a
On 01/08/2014 15:02, fantasai wrote:

> On 07/25/2014 07:57 PM, Richard Ishida wrote:
>> 8.2 Tracking: the letter-spacing property
>> http://dev.w3.org/csswg/css-text/#letter-spacing-property
>> Editor’s Draft, 20 March 2014
>>
>> The length value has the description:
>>
>> "Specifies additional spacing between visually-perceived characters.
>> Values may be negative, but there may be implementation-dependent
>> limits."
>>
>> For cursive text the spec says:
>>
>> "If it is able, the UA may apply letter-spacing to cursive scripts by
>> translating the total spacing distributed to a run of such letters
>> into some form of cursive elongation for that run."
>>
>> Does this mean that if tracking length is set to 1em for a word that
>> is 6 letters long, that the total length of the resulting text will
>> be 6em plus the letter widths, and that therefore if there are some
>> letters that are not allowed to elongate the others will elongate
>> wider than 1em? Or does it mean that those letters that can stretch
>> will each stretch by 1em (possibly resulting in less than 6em overall
>> width)?
>
> The former.
>
>> If values are negative, does this have any meaning for cursive scripts,
>> or is it a hint to use ligatures if any are available
>> (which will result in different effects per font)?
>
> This would allow the use of shortening ligatures or contextual forms,
> yes.
>
>> And then there are Arabic font styles that don't elongate, such as
>> ruq'a. Does the application have to disable letter-spacing  if the
>> user or the device chooses a ruq'a-style font, or is that the
>> responsibility of the author? It seems that it might be
>> hard for authors to signal what to do in the case of fallback fonts.
>
> The application should disable any elongation, yes. It seems unlikely
> for a ruqu'a-style font to be a fallback font, however: system fonts
> are much more likely to be the newspaper style of writing.


The i18n WG is hoping that you can add some of the above clarifications
to the spec, so that we can close this issue.

thanks,
ri

Reply | Threaded
Open this post in threaded view
|

Re: [css-text] i18n-ISSUE-354: Questions about letter-spacing for Arabic script

fantasai
On 10/23/2014 03:08 AM, Richard Ishida wrote:

> On 01/08/2014 15:02, fantasai wrote:
>> On 07/25/2014 07:57 PM, Richard Ishida wrote:
>>> 8.2 Tracking: the letter-spacing property
>>> http://dev.w3.org/csswg/css-text/#letter-spacing-property
>>> Editor’s Draft, 20 March 2014
>>>
>>> The length value has the description:
>>>
>>> "Specifies additional spacing between visually-perceived characters.
>>> Values may be negative, but there may be implementation-dependent
>>> limits."
>>>
>>> For cursive text the spec says:
>>>
>>> "If it is able, the UA may apply letter-spacing to cursive scripts by
>>> translating the total spacing distributed to a run of such letters
>>> into some form of cursive elongation for that run."
>>>
>>> Does this mean that if tracking length is set to 1em for a word that
>>> is 6 letters long, that the total length of the resulting text will
>>> be 6em plus the letter widths, and that therefore if there are some
>>> letters that are not allowed to elongate the others will elongate
>>> wider than 1em? Or does it mean that those letters that can stretch
>>> will each stretch by 1em (possibly resulting in less than 6em overall
>>> width)?
>>
>> The former.
>>
>>> If values are negative, does this have any meaning for cursive scripts,
>>> or is it a hint to use ligatures if any are available
>>> (which will result in different effects per font)?
>>
>> This would allow the use of shortening ligatures or contextual forms,
>> yes.
>>
>>> And then there are Arabic font styles that don't elongate, such as
>>> ruq'a. Does the application have to disable letter-spacing  if the
>>> user or the device chooses a ruq'a-style font, or is that the
>>> responsibility of the author? It seems that it might be
>>> hard for authors to signal what to do in the case of fallback fonts.
>>
>> The application should disable any elongation, yes. It seems unlikely
>> for a ruqu'a-style font to be a fallback font, however: system fonts
>> are much more likely to be the newspaper style of writing.
>
>
> The i18n WG is hoping that you can add some of the above clarifications
> to the spec, so that we can close this issue.

We've made some clarifications. Please take a look at the section and let
me know if this issue is resolved.

Thanks~
~fantasai

Reply | Threaded
Open this post in threaded view
|

Re: [css-text] i18n-ISSUE-354: Questions about letter-spacing for Arabic script

John Hudson
Richard Ishida responding to fantasai:

>> Does this mean that if tracking length is set to 1em for a word that
>> is 6 letters long, that the total length of the resulting text will
>> be 6em plus the letter widths, and that therefore if there are some
>> letters that are not allowed to elongate the others will elongate
>> wider than 1em? Or does it mean that those letters that can stretch
>> will each stretch by 1em (possibly resulting in less than 6em overall
>> width)?
>
> The former.
>
>> If values are negative, does this have any meaning for cursive scripts,
>> or is it a hint to use ligatures if any are available
>> (which will result in different effects per font)?
>
> This would allow the use of shortening ligatures or contextual forms,
> yes.
>
>> And then there are Arabic font styles that don't elongate, such as
>> ruq'a. Does the application have to disable letter-spacing  if the
>> user or the device chooses a ruq'a-style font, or is that the
>> responsibility of the author? It seems that it might be
>> hard for authors to signal what to do in the case of fallback fonts.
>
> The application should disable any elongation, yes. It seems unlikely
> for a ruqu'a-style font to be a fallback font, however: system fonts
> are much more likely to be the newspaper style of writing.

My two cents:

There really need to be font level controls for 'letter-spacing' of
Arabic text with which user agents can interact, because the methods of
extending or contracting line length in Arabic are style- and
design-specific. The issues involved in such 'letter-spacing' are, of
course, directly analogous to those of justifying Arabic text, and would
best make use of the same methods and technologies.

It should be noted that kashidas (i.e. elongations between cursively
joining letters) is only one in a hierarchy of methods traditionally
used to widen Arabic text to a fixed measure, and is actually one of the
lower priority methods, applied only after substitution of wider final
and isolated forms, variant joining behaviours appropriate to the style,
and adjustments to both inter- and intra-word spacing. The rules for
where kashidas may be applied are also style specific, and not simply a
binary between those styles that permit elongation and those that do not.

A few years ago, Microsoft introduced a simple mechanism to prevent
automatic kashida insertion from happening for a font during
justification: if the font contains a zero-width, no-ink glyph for
U+0640 ARABIC TATWEEL, MS Word and presumably MS browsers will not apply
kashidas in justification. The purpose of this was to protect fonts that
require curved or cascading kashidas and, hence, OpenType Layout GSUB
and GPOS processing, from having kashidas inserted by justification
algorithms after OTL has been processed. [Discretionary kashidas,
inserted either by an author using U+0640 or by OTL contextual
substitutions can still work in such fonts, but substituting an
appropriate glyph in the GSUB table.] This mechanism is, to my
knowledge, not properly documented and is currently external to any
specification or standard.

A more sophisticated option would involve support for the OpenType JSTF
table or some update thereto. This would allow for design-specific
prioritisation of multiple methods of adjusting Arabic text length to
achieve the best results for the individual typeface.

The end goal should be support even for curved and cascading kashida
within a broader framework of prioritised expansion and contraction
methods for Arabic text (meaning re-application of at least some aspects
of GSUB and GPOS during justification or letter-spacing). Anything short
of that is a technical compromise that may work for some specific styles
of Arabic text (themselves the result of compromises with previous
technologies dating back to hot-metal typesetting of the early 20th
Century). Such compromises may be accepted as interim measures, but not
as adequate solutions.

J.


--

John Hudson
Tiro Typeworks Ltd    www.tiro.com
Salish Sea, BC        [hidden email]

Getting Spiekermann to not like Helvetica is like training
a cat to stay out of water. But I'm impressed that people
know who to ask when they want to ask someone to not like
Helvetica. That's progress. -- David Berlow


Reply | Threaded
Open this post in threaded view
|

Re: [css-text] i18n-ISSUE-354: Questions about letter-spacing for Arabic script

fantasai
On 08/17/2016 11:49 AM, John Hudson wrote:

>
> My two cents:
>
> There really need to be font level controls for 'letter-spacing' of Arabic text with which user agents can interact, because
> the methods of extending or contracting line length in Arabic are style- and design-specific. The issues involved in such
> 'letter-spacing' are, of course, directly analogous to those of justifying Arabic text, and would best make use of the same
> methods and technologies.
>
> It should be noted that kashidas (i.e. elongations between cursively joining letters) is only one in a hierarchy of methods
> traditionally used to widen Arabic text to a fixed measure, and is actually one of the lower priority methods, applied only
> after substitution of wider final and isolated forms, variant joining behaviours appropriate to the style, and adjustments to
> both inter- and intra-word spacing. The rules for where kashidas may be applied are also style specific, and not simply a
> binary between those styles that permit elongation and those that do not.
>
> A few years ago, Microsoft introduced a simple mechanism to prevent automatic kashida insertion from happening for a font
> during justification: if the font contains a zero-width, no-ink glyph for U+0640 ARABIC TATWEEL, MS Word and presumably MS
> browsers will not apply kashidas in justification. The purpose of this was to protect fonts that require curved or cascading
> kashidas and, hence, OpenType Layout GSUB and GPOS processing, from having kashidas inserted by justification algorithms after
> OTL has been processed. [Discretionary kashidas, inserted either by an author using U+0640 or by OTL contextual substitutions
> can still work in such fonts, but substituting an appropriate glyph in the GSUB table.] This mechanism is, to my knowledge,
> not properly documented and is currently external to any specification or standard.
>
> A more sophisticated option would involve support for the OpenType JSTF table or some update thereto. This would allow for
> design-specific prioritisation of multiple methods of adjusting Arabic text length to achieve the best results for the
> individual typeface.
>
> The end goal should be support even for curved and cascading kashida within a broader framework of prioritised expansion and
> contraction methods for Arabic text (meaning re-application of at least some aspects of GSUB and GPOS during justification or
> letter-spacing). Anything short of that is a technical compromise that may work for some specific styles of Arabic text
> (themselves the result of compromises with previous technologies dating back to hot-metal typesetting of the early 20th
> Century). Such compromises may be accepted as interim measures, but not as adequate solutions.

Well, I can't really fix any font things, since that's not my area. :)
But do have a look at what's written in
   https://drafts.csswg.org/css-text-3/#justify-cursive
and
   https://drafts.csswg.org/css-text-3/#cursive-tracking
and let me know if anything needs tweaking.

~fantasai