Devanagari: 3.4 Glyph control - clarify requirement

[alolita]

https://w3c.github.io/iip/gap-analysis/deva-gap.html#glyphs

Section 2.4 states "Does the script in question require additional features to support alterations to the position or shape of glyphs, for example adjusting the distance between the base text and diacritics, or changing the glyphs used in a systematic way?"

Clarification needed: How much detail is needed in this section? Does an outline of proportions of spacing (width, height) between consonants or between a consonant and vowel when placed next to each other, need to be defined in this section?

Examples from other type specifications would be useful too.

@r12a - can you please clarify and add an example too?

[r12a]

I don't intend this section to list of all the GSUB and GPOS rules from a devanagari font. Instead, it was intended to capture requirements to give control to authors over positioning of diacritics, or other shaping.

I think the relevant information for (some) indic scripts is whether authors are able to force a virama to appear, or reduce a ligated form to a half-form, eg. क्ष vs. क्‍ष vs. क्‌ष.

[alolita]

Discussion Notes from Oct 5 2018 IIP wg:

1. Glyphs are not the right definition for Devanagari and other Indic language scripts
2. Instead the IIP team will use Akshara definitions (clusters not glyphs) for Indic scripts
3. The IIP team will recommend updates, enhancements to Unicode UTR 29
4. References include - current UTR 29, work being done for ICANN/GTLD definitions of handling domain names (IDNs) for Indic languages
5. Need to consider both current usage and historic usage of aksharas and inter-akshara spacing specs
6. Open Type specification and Unicode UTR 29 are inadequate for Indic scripts

Action Items:

1. Add usage specimens - @alolita @vivekpani @akshatsj @nehagk
2. Add links for each document from ICANN/GTLD work - @akshatsj , @nehagk
3. Public comment is open on GTLD docs till Oct 8 2018 - so review and comment

[tiroj]

re. Note 5

Need to consider both current usage and historic usage of aksharas and inter-akshara spacing specs

In OpenType, inter-akshara spacing is complicated by a long-standing bug affecting all non-USE (Universal Shaping Engine) Indic implementations of cluster shaping — Uniscribe, Harfbuzz, CoreText, World Ready Composer —, which is that all GSUB features are restricted to individual clusters, meaning that cross-cluster contextual substitutions do not work.

Although adjustment to spacing (kerning) is itself implemented via GPOS, which does work across cluster boundaries, preparing variants to have appropriate spacing relationships or, as is sometimes desirable, inserting a small head line extender to move glyphs further apart, will not work.

This bug is documented here: Problems for Indic typography in current OpenType Layout implementations.

In April 2014, a workaround to this bug was agreed on by stakeholders, and has since been implemented in the Harfbuzz and CoreText engines, but it has not been implemented in Uniscribe or World Ready Composer. [Adobe recently announced that Harfbuzz will be available for shaping in Photoshop, and hopefully that will be extended to other Adobe apps, leaving only Uniscribe not supporting the workaround.]

The workaround is documented here: Fixing Indic2 OpenType Layout.

[tiroj]

re. Note 6

Open Type specification and Unicode UTR 29 are inadequate for Indic scripts

Are more detailed comments available? I don't disagree with the sentiment, but would like to know what others find inadequate, especially with regard to OpenType.

[vivekpani]

It may be too long a comment and not entirely in the scope of this issue. But, having developed Indian scripts rendering solutions for early platforms (with fixed width fonts) and scalable fonts (before OpenType was defined) and then later developed Opentype rendering engines through the evolution of the opentype standard from it's early release in 2000s until now, I did find it largely inadequate for Indic scripts. But, not everything could be attributed to the font or font standard alone. Indic scripts do not have a linear behavior nor are the alphabet set a collection of letters with uniform properties. The ISCII encoding (from which Unicode was borrowed) itself considered several aspects of display and the responsibility that will go to the rendering algorithms (apart from computing considerations) before arriving at the encoding scheme. This is because the non-linearity of these scripts "and" the phonetic nature of the characters, made a very close link between the properties of the two. OpenType operates at a glyph level. The classification of glyphs into base and marks aren't linked to characters or their classifications. This may have been because the encoding (Unicode) itself didn't offer much details other than code points. Also, the definitions in OpenType, order of application of tables and rules are experimental. I think these gaps are the reasons, no two OpenType engines behave uniformly. Also, for an average font designer in native scripts, the glyph level definitions in isolation are not intuitive. Font designers struggle to create OpenType fonts and find it nearly impossible to make it work across all platforms. Native designers definitely grew in very large numbers independently for each script designing for ISCII based software. But, most of them couldn't use their design skills with OpenType and there are very limited OpenType fonts for Indic scripts.