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

Thu Feb 29 02:50:51 CET 2024

Typo corrected inline below.

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of Peter Constable via mpeg-otspec <mpeg-otspec at lists.aau.at>
Date: Wednesday, February 28, 2024 at 6:46 PM
To: 木田泰夫 <kida at mac.com>, Nat McCully <nmccully at adobe.com>
Cc: Josh Hadley <johadley at adobe.com>, mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Re: OpenType 'palt' and 'kern' Documentation Revision Proposal
Hi, Kida-san

The problem I see with the current design involving interaction between ‘kern’ and ‘palt’ is a very ambiguous characterization of when ‘kern’ should not be activated by default. I think a different feature such as I suggested might be the cleanest solution. But a possible way to make something workable for existing fonts could be to use the Unicode East_Asian_Width property.

If I understand how ‘palt’ has been used (and is intended to be used), the characters whose glyphs would likely be affected by ‘palt’ are those that have EAW property values Fullwidth, Wide, and probably also Ambiguous.

Also, the concern about unintended application of ‘kern’ would only arise in the case of fonts that implement both ‘kern’ and ‘palt’. (If only one of those is implemented, there isn’t any problem.)

So, with those things in mind, the guidance for ‘kern’ could say that it should be applied by default _except_ for runs of text for which the following are both true:

  *   characters have East_Asian_Width property values Fullwidth or Wide (or, perhaps, Ambiguous); and
  *   the text is formatted with a font that implements both ‘palt’ and ‘kern’.

Perhaps that would be a sufficient remedy for the current problem. But if there’s concensus that a new feature should be defined, then a recommendation for new font implementations (and perhaps also updates to existing fonts) to use the new feature in conjuction with ‘palt’ could be added as well.

Peter

From: 木田泰夫 <kida at mac.com>
Date: Tuesday, February 27, 2024 at 6:35 PM
To: Nat McCully <nmccully at adobe.com>, Peter Constable <pconstable at microsoft.com>
Cc: Josh Hadley <johadley at adobe.com>, mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
Subject: [EXTERNAL] Re: OpenType 'palt' and 'kern' Documentation Revision Proposal
You don't often get email from kida at mac.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hello Peter,

I strongly support the direction you proposed. As you pointed out, this method spares applications from relying on unstable assumptions regarding monospace CJK, which is a significant advantage. I only wish this strategy had been our starting point.

However, we face a challenge with existing CFF-based Japanese fonts, which have incorporated 'palt' since their inception 25 years ago. These fonts are already in use and cannot be easily replaced in the field. Given this constraint, do you have any recommendations on how we might address or mitigate this issue? Your insights or suggestions would be invaluable as we navigate this complexity together.

Best regards,

- kida

2024/02/22 14:20、Nat McCully <nmccully at adobe.com>のメール:

Great idea! I like it better especially since now apps can rely on the font entirely to determine what gets kerned in the proportional Japanese case and not worry that 'kern' will affect Japanese without 'palt', and they also don't have to try to detect which glyphs are full width in the font or whatever (in our case we exclude upright in vertical characters/glyphs as the proxy for full width).

—Nat
________________________________
From: Peter Constable <pconstable at microsoft.com>
Sent: Wednesday, February 21, 2024 6:54:01 PM
To: Nat McCully <nmccully at adobe.com>; 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: OpenType 'palt' and 'kern' Documentation Revision Proposal

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

Thanks for the info.

I understand the need, which is reasonable. I just suspect this approach will not work out well.

It all hinges on special and complex logic for determining over what text spans ‘kern’ can be on by default. (To do it properly, I think you’d want to parse coverage tables of lookups linked to ‘palt’ and map those glyphs back to characters, including any paths through GSUB substitutions.) If some apps were to attempt something, implementations would likely be very buggy and inconsistent with one another, which would likely lead to font vendors getting complaints from their customers regarding some mix of apps that are outside their control.

Rather than suggest complex logic for default setting of ‘kern’, wouldn’t it be much simpler to define a new feature to activate kerning actions on glyphs to which ‘palt’ has also been applied? Here’s a possibility:

————

Tag: 'apkn'

Friendly name: Kerning for alternate proportional widths.

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

Example: A user activates proportional metrics (‘palt’) in Japanese text, which results in some glyphs that had monospace advance widths by default now having proportional widths. By activating this feature as well, those glyphs are then kerned with other glyphs. For instance, the glyph for U+FF08 “（” has full-width advance by default; the ‘palt’ feature adjusts the glyph to have a narrower, proportional width; this feature then shifs this glyph closer to U+3078 “へ” in the combination “（へ”.

Recommended implementation: The font kerns Kanji, Kana, Latin, punctuation, or other glyphs if those glyphs also are adjusted to proportional widths by lookups linked to the ‘palt’ feature.

Primarily intended for use in the GPOS table. Positioning adjustments can be implemented using GPOS pair-adjustment (type 2) lookups. Single- and pair-adjustment lookups have simple additive effect, therefore relative ordering of lookups for this feature and type 1 or type 2 lookups for ‘palt’ or other similar features is not crucial.

It is strongly recommended that glyphs that have monospace widths by default not be kerned with other glyphs using the ‘kern’ feature but should only be kerned by activation of this feature.

UI suggestion: This feature should be off by default, and activation should only be possible if the ‘palt’ feature has been activated. If ‘palt’ has been activated, then this feature may be automatically activated, but the UI should also provide a way to deactivate the feature when ‘palt’ is activated. The UI could implement logic for controlling both this feature and the ‘kern’ feature using a single control, but such logic should ensure that this feature is only activated if ‘palt’ is activated.

Script/language sensitivity: Intended primarily for CJK fonts but can be used in fonts for any script that have monospace advance widths by default.

Feature interaction: Should only be implemented in fonts that also implement the ‘palt’ feature, which this feature is intended to complement. This feature should only be activated if ‘palt’ has been activated, but is not required to be activated if ‘palt’ is activated.

————

This way, the description and implementation for ‘kern’ are much simpler: there’s no need for complex logic to determine over which spans ‘kern’ should be activated by default; the app simply should always activate ‘kern’ by default for all text. Assuming the above recommendations for the new feature are followed in a font, having ‘kern’ on by default doesn’t result in undesired results.

And, since the recommendation for the new feature is that it be off by default, the worst-case scenario of an app not having any logic about dependency on ‘palt’ also doesn’t lead to undesired results by default. A user might be able to activate this feature when ‘palt’ isn’t activated, but they can then turn it off.

I would think there’s a better chance apps will expose this feature along with ‘palt’ than implement special, complex and bug-prone logic around default activation of ‘kern’.

Peter Constable

From: Nat McCully <nmccully at adobe.com>
Sent: Wednesday, February 21, 2024 6:29 PM
To: Peter Constable <pconstable at microsoft.com>; Josh Hadley <johadley at adobe.com>; mpeg-otspec at lists.aau.at
Cc: kida at mac.com
Subject: [EXTERNAL] Re: OpenType 'palt' and 'kern' Documentation Revision Proposal

You don't often get email from nmccully at adobe.com<mailto:nmccully at adobe.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

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<mailto:mpeg-otspec-bounces at lists.aau.at>> on behalf of Peter Constable via mpeg-otspec <mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>>
Sent: Wednesday, February 21, 2024 5:04:19 PM
To: Josh Hadley <johadley at adobe.com<mailto:johadley at adobe.com>>; mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at> <mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>>
Cc: kida at mac.com<mailto:kida at mac.com> <kida at mac.com<mailto: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:

[cid:image001.png at 01DA64F5.64B99520]

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

[cid:image002.png at 01DA64F5.64B99520]

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):

[cid:image004.png at 01DA64F5.64B99520]

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:image005.png at 01DA64F5.64B99520]

Peter Constable

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at<mailto: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<mailto:mpeg-otspec at lists.aau.at>
Cc: kida at mac.com<mailto: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/20240229/652d8b7d/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/20240229/652d8b7d/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/20240229/652d8b7d/attachment-0005.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/20240229/652d8b7d/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 37365 bytes
Desc: image005.png
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240229/652d8b7d/attachment-0007.png>