apkn needs clarification

[macnmm]

Description

please see my edits in the redline version of the spec, in the 'apkn' section.

nmccully comments for ISO14496-22.docx

Page URL

https://learn.microsoft.com/en-us/typography/opentype/spec/features_ae

Content source URL

https://github.com/MicrosoftDocs/typography/blob/live/typographydocs/opentype/spec/features_ae.md

[macnmm]

We (CITPC Japanese font committee) discussed the changes listed above and will submit a final version with minor edits soon

[PeterCon]

The revisions incorporated into the ISO/IEC DIS 14496-22 are useful though I have some concerns with a few details.

In particular, I think this wording is problematic:

For glyphs that have fixed widths by default but can be set proportionally as an option, or that can have metrics adjusted by the 'palt' feature...

It's unclear what was intended by "set proportionally as an option". The font data can be defined only in relation to other data in the font. As far as the font data goes, the glyphs in question can have proportional widths only as a result of 'palt' feature application. Some apps might have some special algorithms for setting the text proportionally, but there is no way for a font developer to know what such an algorithm might do. So, it only makes sense here to talk about glyphs that have had widths adjusted by application of the 'palt' feature.

(In principle, a different feature could be defined that interacts with some special algorithm for setting text proportionally, but for there to be interoperability, the details of the algorithm would need to be defined in a publicly available specification. Otherwise, a given vendor could have proprietary implementations in their applications and fonts. But neither of these is what 'apkn' is about.)

Here is how I would revise—this avoids the above issue as to how glyphs obtain proportional metrics, keeps content organized by the relevant sections (e.g., implementation details are not in the UI suggestion section), and eliminates some duplication:

---

Addendum

Nat McCulley clarified in email the intent of "can be set proportionally as an option":

This is meant to emphasize palt and proportional Japanese being optional behavior. It is not meant to refer to any app behaviors not related to palt.

We agreed this could be accommodated by additional insertion of "optionally" in the proposed text. That has now been added.

---

Tag: 'apkn'

Friendly name: Kerning for Alternate Proportional Widths

Function: Applies kerning adjustments to glyphs that have fixed advance widths by default but have been adjusted to proportional widths by application of the 'palt' feature.

For example, Japanese fonts typically contain proportional Latin glyphs (that are kerned by default using the 'kern' feature), and monospaced Japanese and other full-width glyphs (that are not kerned by default). The monospaced glyphs can optionally be adjusted to proportional widths using the 'palt' feature, and then some glyph pairs involving those alternate proportional width glyphs can be kerned using the 'apkn' feature. In this way the 'kern' feature can be reserved for use with the default proportional glyphs, and the 'apkn' feature can be reserved for the default monospaced glyphs, separating them as “kerned by default” and “kerned optionally when set proportionally”.

Example: A user activates proportional metrics ('palt') in Japanese text, which results in some glyphs that had fixed advance widths by default now having proportional widths. By activating the 'apkn' feature as well, those glyphs are then kerned with other glyphs. For instance, the glyphs for U+30A2 “ア” and U+30CE “ノ” have full-width advances by default; the 'palt' feature adjusts these glyphs to have a narrower, proportional width; the 'apkn' feature then shifts these glyphs closer together in the combination “アノ”.

Recommended implementation: The font kerns Kanji, Kana, Latin, punctuation, or other glyphs that have fixed-width metrics by default but assuming those glyphs have been adjusted to proportional widths by application of the 'palt' feature.

Primarily intended for use in the GPOS table. Positioning adjustments can be implemented using GPOS pair-adjustment (type 2) lookups. Single-adjustment and pair-adjustment lookups provide delta adjustments to glyph metrics that have simple additive effect. Therefore, the relative ordering of lookups for this feature and type 1 or type 2 lookups used for 'palt' or other features is not crucial.

Glyphs kerned by the 'apkn' feature should have fixed widths by default with proportional metrics provided by application of the 'palt' feature. If some glyphs that have fixed widths by default are not adjusted by the ‘palt’ feature, these may still be kerned by the ‘apkn’ feature with other glyphs that have acquired proportional widths due to the 'palt' feature. It is strongly recommended that any glyphs that acquire proportional widths by application of the 'palt' feature should not be kerned with any glyphs using the 'kern' feature; they should only be kerned by application of the 'apkn' feature. The 'apkn' and 'kern' features should be mutually exclusive: the set of glyph pairs processed by one should not overlap with the glyph pairs processed by the other.

UI suggestion: This feature should be off by default. If it has been activated for a run, the 'palt' feature should also be applied to that run. Conversely, if 'palt' has been activated for a run, then this feature may be automatically activated, but the UI should provide an option for a user to deactivate the feature while ‘palt' is still activated.

To support kerning of all glyphs in a text run, applications should apply 'kern', 'palt' and 'apkn' to the run. To support only kerning of default proportional glyphs, if a font supports the 'apkn' and 'palt' features, then applications can apply ‘kern’ — and only 'kern' — to the entire run. (This is simpler than what applications would need to do with fonts that do not support ‘apkn’: they would apply ‘palt’ together with ‘kern’ only on glyphs that are normally set monospaced.)

...