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

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        tiro@tiro.com

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

Received on Wednesday, 17 August 2016 18:49:55 UTC