[MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision Proposal

Thu Feb 22 02:28:56 CET 2024

Thanks for the comments.

Adobe apps do implement palt and kern together when you select “metrics” kerning (also called “auto”. Fonts that set kerning values on kana glyphs set the kern amount as a delta from the ‘palt’ widths, so it actually would be incorrect only to turn ‘kern’ without also turning on ‘palt’. However this is problematic as a default value for Japanese, so we defined a new “Roman only kerning” setting that is the default and only kerns non-CJK glyphs and leaves CJK monospaced.

Most applications set kerning on by default. If you do not do the above complex thing the Japanese fonts that have kerning values for kana glyphs will not kern enough, and will not be monospaced by default, which makes it difficult to get a quality or desired result out of the box.

—Nat
________________________________
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of Peter Constable via mpeg-otspec <mpeg-otspec at lists.aau.at>
Sent: Wednesday, February 21, 2024 5:04:19 PM
To: Josh Hadley <johadley at adobe.com>; mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
Cc: kida at mac.com <kida at mac.com>
Subject: Re: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision Proposal

EXTERNAL: Use caution when clicking on links or opening attachments.

This was reported last fall as an issue on the OpenType spec:

'kern' and 'palt' UI suggestions and feature interaction descriptions are confusing for CJK · Issue #1069 · MicrosoftDocs/typography-issues (github.com)<https://github.com/MicrosoftDocs/typography-issues/issues/1069>

I’ve added comments in the discussion for that issue.

I’m leery about feature descriptions recommending complex feature-application behaviours that are unlikely to get implemented in applications. I have that concern in this case.

The ‘palt’ feature was defined by Adobe in early 1998. The earliest description (OpenType 1.1) didn’t mention interaction with ‘kern’. Here’s an excerpt:

—————

Tag: "kern"

…

UI suggestion: This feature should be active by default. Applications may wish to allow users to add further manually-specified adjustments to suit specific needs and tastes.

Script/language sensitivity: None.

Feature interaction: May be used in addition to any other feature.

…

Tag: "palt"

…

UI suggestion: This feature would be off by default.

Script/language sensitivity: Used mostly in CJKV fonts.

Feature interaction: This feature overrides the results of all other width features.

—————

In OpenType 1.2 (October 1998), the relationship to ‘kern’ was recognized (emphasis added):

—————

Feature interaction: This feature overrides the results of all other glyph-width features. Applying this feature should also activate the kern feature.

—————

Some of the early Adobe feature descriptions are worded in ways that might suggest a wrong expectation that features in a font can control activation of other features in the font. I don’t know if that’s what the author of that description was assuming at the time. It’s worth pointing out, however, that the desired outcome of the above recommendation doesn’t require activating any other feature when ‘palt’ is activated: the lookups that implement kerning actions could simply be referenced by the ‘palt’ feature table directly.

By OpenType 1.3 (2000?), more subtle interaction between ‘kern’ and ‘palt’ was called out, though it appears the idea was emerging subtle that interaction between ‘palt’ and ‘kern’ could be more subtle, though the feature descriptions weren’t consistent with each other:

—————

Tag: 'kern'

…

UI suggestion: This feature should be active by default for horizontal text setting. Applications may wish to allow users to add further manually-specified adjustments to suit specific needs and tastes.

…

Feature interaction: If 'kern' is activated, 'palt' must also be activated if it exists. (If 'palt' is activated, there is no requirement that 'kern' must also be activated.) May be used in addition to any other feature except those which result in fixed (uniform) advance widths (e.g. fwid, halt, hwid, qwid and twid)

…

Tag: 'palt'

…

Feature interaction: This feature is mutually exclusive with all other glyph-width features (e.g. fwid, halt, hwid, pwid, qwid and twid), which should be turned off when it's applied. Applying this feature should activate the kern feature. See also vpal.

—————

By OpenType 1.5 (May 2008) the ‘palt’ description was updated to match interaction described in the ‘kern’ description.

—————

Tag: 'palt'

…

Feature interaction: This feature is mutually exclusive with all other glyph-width features (e.g. fwid, halt, hwid, qwid and twid), which should be turned off when it’s applied. If palt is activated, there is no requirement that kern must also be activated. If kern is activated, palt must also be activated if it exists. See also vpal.

—————

Since 2008, these feature descriptions have not changed in these regards.

So, it’s over 25 years since Adobe first registered ‘palt’, and at least 15 years since they recommended applications implement more subtle interaction between ‘palt’ and ‘kern’.

Now it’s proposed that applications should implement behaviour that’s even more involved, detecting whether glyphs are proportional or monospace and requiring that 'kern' “[by] default shall not be activated on monospaced glyphs, but may be activate on any proportional-width glyphs”. I’m not even sure how an app is expected to distinguish monospaced glyphs from proportional glyphs.

But even without this proposed revision, there’s been an assumption for over 15 years that apps would have some interaction between application of ‘palt’ and of ‘kern’. Does any app today implement that?

If any app does, I expect Adobe, which proposed ‘palt’, would have done so at some point in the past 25 years. I don’t see a way in InDesign to control ‘palt’—here are the options I see in InDesign with the Yu Gothic font, which implements both ‘palt’ and ‘kern’ in GPOS under the default language system for ‘hani, ‘kana’, ‘latn’ and other scripts:

[A screenshot of a computer  Description automatically generated]

PhotoShop appears to be exposing ‘palt’ in UI, but it’s set on with no way to toggle it off:

[A screenshot of a computer menu  Description automatically generated]

In both apps, it’s not exactly clear to me how kerning UI interacts with the ‘kern’ feature. By default kerning is set to “Metrics”, which I’m guessing uses ‘kern’ (and I assume it’s deactivated by selecting the “0” option):

[A screenshot of a computer  Description automatically generated]

If that’s the case, then the default is that both ‘palt’ and ‘kern’ are activated by default for both Latin and CJK runs, with no way to disable ‘palt’ (that I’ve found).

[cid:image003.png at 01DA64EF.0C75A990]

Peter Constable

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Josh Hadley via mpeg-otspec
Sent: Wednesday, February 21, 2024 11:45 AM
To: mpeg-otspec at lists.aau.at
Cc: kida at mac.com
Subject: [EXTERNAL] [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision Proposal

(I’m posting this on behalf of Nat McCully for discussion at the next AHG meeting; he’s unavailable right now but wanted to get it on the agenda)

Vlad & AHG members,

Please consider the proposal posted at https://github.com/jcitpc/CJKFont/blob/main/docs/palt_kern.md for addition to the next AHG meeting agenda.

Thanks,

Josh Hadley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240222/66c0d076/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15072 bytes
Desc: image001.png
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240222/66c0d076/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 29343 bytes
Desc: image002.png
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240222/66c0d076/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 37365 bytes
Desc: image003.png
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240222/66c0d076/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 12376 bytes
Desc: image004.png
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240222/66c0d076/attachment-0007.png>