From tfuji at morisawa.co.jp  Fri Feb  2 06:45:58 2024
From: tfuji at morisawa.co.jp (=?utf-8?B?VGFrYWFraSBGdWppIOiXpCDosrTkuq4=?=)
Date: Fri,  2 Feb 2024 14:45:58 +0900
Subject: [MPEG-OTSPEC] Possible edit for LTSH and b64k
Message-ID: <2E1F1F9A-5377-456E-AFF7-F34C7A042077@morisawa.co.jp>

Hello all,

Sorry if I missed past discussions, but I found LTSH might also need a small change for the b64k proposal, where the 'numGlyphs' field is uint16.

I checked the fonts currently available in macOS and Windows, and still a number of fonts include a set of VDMX/hdmx/LTSH table, possibly generated with the Microsoft?s CacheTT tool. I also found out that B612 (https://b612-font.com) is one of the recent fonts with those tables.

For b64k fonts, I suppose just capping this field at 65,535 should suffice as you can put an arbitrary number of 'yPels' in the table anyway. Like the 'sbix' table, putting a line like

> The glyph count is derived from the size of the ?GLYF? table when present, or from the 'maxp' table. 

into the description sounds nice to make sure b64k-aware clients should ignore the ?numGlyphs? field in this table.

So, in case this table is still in use, we might want to make a small edit. What do you think?

Regards,

Takaaki Fuji


From behdad at behdad.org  Fri Feb  2 19:31:24 2024
From: behdad at behdad.org (Behdad Esfahbod)
Date: Fri, 2 Feb 2024 11:31:24 -0700
Subject: [MPEG-OTSPEC] Possible edit for LTSH and b64k
In-Reply-To: <2E1F1F9A-5377-456E-AFF7-F34C7A042077@morisawa.co.jp>
References: <2E1F1F9A-5377-456E-AFF7-F34C7A042077@morisawa.co.jp>
Message-ID: <CAF63+7WctFSyaMa6-9A5x8v+HZdE1DO7bFc6g8P_KD7xW5eY1w@mail.gmail.com>

Thank you for this. I filed the following issue with a proposal:

  https://github.com/harfbuzz/boring-expansion-spec/issues/132

behdad
http://behdad.org/


On Thu, Feb 1, 2024 at 10:46?PM Takaaki Fuji ? ?? via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> Hello all,
>
> Sorry if I missed past discussions, but I found LTSH might also need a
> small change for the b64k proposal, where the 'numGlyphs' field is uint16.
>
> I checked the fonts currently available in macOS and Windows, and still a
> number of fonts include a set of VDMX/hdmx/LTSH table, possibly generated
> with the Microsoft?s CacheTT tool. I also found out that B612 (
> https://b612-font.com) is one of the recent fonts with those tables.
>
> For b64k fonts, I suppose just capping this field at 65,535 should suffice
> as you can put an arbitrary number of 'yPels' in the table anyway. Like the
> 'sbix' table, putting a line like
>
> > The glyph count is derived from the size of the ?GLYF? table when
> present, or from the 'maxp' table.
>
> into the description sounds nice to make sure b64k-aware clients should
> ignore the ?numGlyphs? field in this table.
>
> So, in case this table is still in use, we might want to make a small
> edit. What do you think?
>
> Regards,
>
> Takaaki Fuji
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240202/470ff3eb/attachment.htm>

From tfuji at morisawa.co.jp  Fri Feb  2 20:08:11 2024
From: tfuji at morisawa.co.jp (=?utf-8?B?VGFrYWFraSBGdWppIOiXpCDosrTkuq4=?=)
Date: Sat,  3 Feb 2024 04:08:11 +0900
Subject: [MPEG-OTSPEC] Possible edit for LTSH and b64k
In-Reply-To: <CAF63+7WctFSyaMa6-9A5x8v+HZdE1DO7bFc6g8P_KD7xW5eY1w@mail.gmail.com>
References: <2E1F1F9A-5377-456E-AFF7-F34C7A042077@morisawa.co.jp>
 <CAF63+7WctFSyaMa6-9A5x8v+HZdE1DO7bFc6g8P_KD7xW5eY1w@mail.gmail.com>
Message-ID: <5F4A0B71-D44F-4653-8A5B-CB4DBA102B8F@morisawa.co.jp>

Thank you so much! As for versioning I have no particular opinions and whatever is fine.

Regards,

Takaaki Fuji

> On Feb 3, 2024, at 3:31, Behdad Esfahbod <behdad at behdad.org> wrote:
> 
> Thank you for this. I filed the following issue with a proposal:
> 
>   https://github.com/harfbuzz/boring-expansion-spec/issues/132
> 
> behdad
> http://behdad.org/
> 
> 
> On Thu, Feb 1, 2024 at 10:46?PM Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> Hello all,
> 
> Sorry if I missed past discussions, but I found LTSH might also need a small change for the b64k proposal, where the 'numGlyphs' field is uint16.
> 
> I checked the fonts currently available in macOS and Windows, and still a number of fonts include a set of VDMX/hdmx/LTSH table, possibly generated with the Microsoft?s CacheTT tool. I also found out that B612 (https://b612-font.com) is one of the recent fonts with those tables.
> 
> For b64k fonts, I suppose just capping this field at 65,535 should suffice as you can put an arbitrary number of 'yPels' in the table anyway. Like the 'sbix' table, putting a line like
> 
> > The glyph count is derived from the size of the ?GLYF? table when present, or from the 'maxp' table. 
> 
> into the description sounds nice to make sure b64k-aware clients should ignore the ?numGlyphs? field in this table.
> 
> So, in case this table is still in use, we might want to make a small edit. What do you think?
> 
> Regards,
> 
> Takaaki Fuji
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec


From htl10 at users.sourceforge.net  Sun Feb  4 17:25:44 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Sun, 4 Feb 2024 16:25:44 +0000 (UTC)
Subject: [MPEG-OTSPEC] Possible edit for LTSH and b64k
In-Reply-To: <5F4A0B71-D44F-4653-8A5B-CB4DBA102B8F@morisawa.co.jp>
References: <2E1F1F9A-5377-456E-AFF7-F34C7A042077@morisawa.co.jp>
 <CAF63+7WctFSyaMa6-9A5x8v+HZdE1DO7bFc6g8P_KD7xW5eY1w@mail.gmail.com>
 <5F4A0B71-D44F-4653-8A5B-CB4DBA102B8F@morisawa.co.jp>
Message-ID: <766531122.7794151.1707063944799@mail.yahoo.com>

 The version field in LTSH is going to be another case of "that field hasn't changed for 3 decades, it is possible that implementation(s) stopped wasting time reading it some years ago..." .
One would hope that the numGlyphs field, on the other hand, is read and cross-checked against maxp, head, etc in practical implementation(s), regardless of the version field.
    On Friday, 2 February 2024 at 19:08:39 GMT, Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 Thank you so much! As for versioning I have no particular opinions and whatever is fine.

Regards,

Takaaki Fuji

> On Feb 3, 2024, at 3:31, Behdad Esfahbod <behdad at behdad.org> wrote:
> 
> Thank you for this. I filed the following issue with a proposal:
> 
>? https://github.com/harfbuzz/boring-expansion-spec/issues/132
> 
> behdad
> http://behdad.org/
> 
> 
> On Thu, Feb 1, 2024 at 10:46?PM Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> Hello all,
> 
> Sorry if I missed past discussions, but I found LTSH might also need a small change for the b64k proposal, where the 'numGlyphs' field is uint16.
> 
> I checked the fonts currently available in macOS and Windows, and still a number of fonts include a set of VDMX/hdmx/LTSH table, possibly generated with the Microsoft?s CacheTT tool. I also found out that B612 (https://b612-font.com) is one of the recent fonts with those tables.
> 
> For b64k fonts, I suppose just capping this field at 65,535 should suffice as you can put an arbitrary number of 'yPels' in the table anyway. Like the 'sbix' table, putting a line like
> 
> > The glyph count is derived from the size of the ?GLYF? table when present, or from the 'maxp' table. 
> 
> into the description sounds nice to make sure b64k-aware clients should ignore the ?numGlyphs? field in this table.
> 
> So, in case this table is still in use, we might want to make a small edit. What do you think?
> 
> Regards,
> 
> Takaaki Fuji
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240204/35461771/attachment.htm>

From htl10 at users.sourceforge.net  Sun Feb  4 17:31:30 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Sun, 4 Feb 2024 16:31:30 +0000 (UTC)
Subject: [MPEG-OTSPEC] Possible edit for LTSH and b64k
In-Reply-To: <766531122.7794151.1707063944799@mail.yahoo.com>
References: <2E1F1F9A-5377-456E-AFF7-F34C7A042077@morisawa.co.jp>
 <CAF63+7WctFSyaMa6-9A5x8v+HZdE1DO7bFc6g8P_KD7xW5eY1w@mail.gmail.com>
 <5F4A0B71-D44F-4653-8A5B-CB4DBA102B8F@morisawa.co.jp>
 <766531122.7794151.1707063944799@mail.yahoo.com>
Message-ID: <1132385973.7798017.1707064290433@mail.yahoo.com>

 AFAIK, Microsoft's CacheTT precompiled 3 tables, LTSH, hdmx, and VDMX. May need to update the other two table's numglyphs and other fields.
    On Sunday, 4 February 2024 at 16:26:13 GMT, Hin-Tak Leung via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
  The version field in LTSH is going to be another case of "that field hasn't changed for 3 decades, it is possible that implementation(s) stopped wasting time reading it some years ago..." .
One would hope that the numGlyphs field, on the other hand, is read and cross-checked against maxp, head, etc in practical implementation(s), regardless of the version field.
    On Friday, 2 February 2024 at 19:08:39 GMT, Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 Thank you so much! As for versioning I have no particular opinions and whatever is fine.

Regards,

Takaaki Fuji

> On Feb 3, 2024, at 3:31, Behdad Esfahbod <behdad at behdad.org> wrote:
> 
> Thank you for this. I filed the following issue with a proposal:
> 
>? https://github.com/harfbuzz/boring-expansion-spec/issues/132
> 
> behdad
> http://behdad.org/
> 
> 
> On Thu, Feb 1, 2024 at 10:46?PM Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> Hello all,
> 
> Sorry if I missed past discussions, but I found LTSH might also need a small change for the b64k proposal, where the 'numGlyphs' field is uint16.
> 
> I checked the fonts currently available in macOS and Windows, and still a number of fonts include a set of VDMX/hdmx/LTSH table, possibly generated with the Microsoft?s CacheTT tool. I also found out that B612 (https://b612-font.com) is one of the recent fonts with those tables.
> 
> For b64k fonts, I suppose just capping this field at 65,535 should suffice as you can put an arbitrary number of 'yPels' in the table anyway. Like the 'sbix' table, putting a line like
> 
> > The glyph count is derived from the size of the ?GLYF? table when present, or from the 'maxp' table. 
> 
> into the description sounds nice to make sure b64k-aware clients should ignore the ?numGlyphs? field in this table.
> 
> So, in case this table is still in use, we might want to make a small edit. What do you think?
> 
> Regards,
> 
> Takaaki Fuji
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  _______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240204/bf1d9620/attachment.htm>

From skef at skef.org  Mon Feb  5 10:59:56 2024
From: skef at skef.org (Skef Iterum)
Date: Mon, 5 Feb 2024 01:59:56 -0800
Subject: [MPEG-OTSPEC] Updated FeatureVariations proposals
Message-ID: <5482c43f-bffb-4796-be43-ce296ce9a0a9@skef.org>

In August I distributed a document on an alternative to the 
FeatureVariations mechanism that was briefly discussed in the last Ad 
Hoc meeting. Assuming things go as planned we'll be reviewing the same 
ideas in the form of closer-to-final proposals.

I'm still hoping to get some feedback by the February 8th or so, which I 
will turn around and integrate into what is reviewed. Nevertheless, I 
decided to rework the document to be more proposal-like before that, in 
part to make such feedback easier. I also split the ideas into two 
proposals, one for the alternative mechanism (the tables for which have 
been slightly simplified, I think in a way that makes things easier and 
more backward compatible) and one for the negated conditions.

Like most proposal documents these don't really "explain themselves". 
Anyone interested should refer to the earlier document for explanations 
of why these changes are beneficial.

Skef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newfeatvar_spec.pdf
Type: application/pdf
Size: 28616 bytes
Desc: not available
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/93ec0777/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: negation.pdf
Type: application/pdf
Size: 10609 bytes
Desc: not available
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/93ec0777/attachment-0003.pdf>

From skef at skef.org  Mon Feb  5 11:23:29 2024
From: skef at skef.org (Skef Iterum)
Date: Mon, 5 Feb 2024 02:23:29 -0800
Subject: [MPEG-OTSPEC] Relaxation of CFF2 hint requirements (?) in variable
 fonts
Message-ID: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org>

A short proposal to relax the requirements on stem hints in a CFF2 
variable font should be attached. These changes (or clarifications -- 
see below) are comparable to allowing overlap in CFF2; what could easily 
be normalized away in a static context winds up being needed in a 
variable context.

Note that these changes do not affect the storage format, and one could 
argue that one or even both is compatible with the current standard 
(given that nothing much is said on the subject). Still, they may raise 
issues about versioning. My sense is that if a font built according to 
the clarifications is rasterized on a system assuming total ordering of 
stems and/or no duplicate stems, the result will be as if some stems are 
missing rather than overt distortion of a glyph. And the need for such 
stems is relative rare, so only a few glyphs in a typical font are 
likely to be affected.

We can talk about versioning questions as part of the discussion.

Skef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cff2hintorder.pdf
Type: application/pdf
Size: 11704 bytes
Desc: not available
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/642f1ef5/attachment.pdf>

From pconstable at microsoft.com  Mon Feb  5 21:43:54 2024
From: pconstable at microsoft.com (Peter Constable)
Date: Mon, 5 Feb 2024 20:43:54 +0000
Subject: [MPEG-OTSPEC] [EXTERNAL] Relaxation of CFF2 hint requirements
 (?) in variable fonts
In-Reply-To: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org>
References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org>
Message-ID: <PH7PR21MB33085EBEEDEB488B633C120DDE472@PH7PR21MB3308.namprd21.prod.outlook.com>

Hi, Skef

The term "master" should not be used in the way you have in this doc. The variations overview section uses the term, defining it as "a set of source font data... used in a font-development workflow". It could be used elsewhere in the spec with that meaning, but the wording should make clear that it refers to source data. 

In your doc, it's not clear whether you mean "instance" or a default value combined with a (not attenuated) delta. The latter concept necessarily has to refer to some specific value in the font, which could be an outline coordinate, a metric value, or any other single, variable value. But when it comes to data in the font file there is nothing that corresponds to a source master.


A question about this: I gather that this would require changes in CFF2 rasterizers?


Peter

-----Original Message-----
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Skef Iterum via mpeg-otspec
Sent: Monday, February 5, 2024 3:23 AM
To: mpeg-otspec at lists.aau.at
Subject: [EXTERNAL] [MPEG-OTSPEC] Relaxation of CFF2 hint requirements (?) in variable fonts

A short proposal to relax the requirements on stem hints in a CFF2 variable font should be attached. These changes (or clarifications -- see below) are comparable to allowing overlap in CFF2; what could easily be normalized away in a static context winds up being needed in a variable context.

Note that these changes do not affect the storage format, and one could argue that one or even both is compatible with the current standard (given that nothing much is said on the subject). Still, they may raise issues about versioning. My sense is that if a font built according to the clarifications is rasterized on a system assuming total ordering of stems and/or no duplicate stems, the result will be as if some stems are missing rather than overt distortion of a glyph. And the need for such stems is relative rare, so only a few glyphs in a typical font are likely to be affected.

We can talk about versioning questions as part of the discussion.

Skef

From htl10 at users.sourceforge.net  Mon Feb  5 21:53:27 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Mon, 5 Feb 2024 20:53:27 +0000 (UTC)
Subject: [MPEG-OTSPEC] [EXTERNAL] Relaxation of CFF2 hint requirements
 (?) in variable fonts
In-Reply-To: <PH7PR21MB33085EBEEDEB488B633C120DDE472@PH7PR21MB3308.namprd21.prod.outlook.com>
References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org>
 <PH7PR21MB33085EBEEDEB488B633C120DDE472@PH7PR21MB3308.namprd21.prod.outlook.com>
Message-ID: <2140608869.8781385.1707166407350@mail.yahoo.com>

 That reminds me - the git/git[hub,lab,...] people have been moving away from "master" as the name of the default branch, to "main", because of the word's colonial connotations.
Maybe the opentype spec should avoid the word "master" for that reason too.
    On Monday, 5 February 2024 at 20:44:15 GMT, Peter Constable via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 Hi, Skef

The term "master" should not be used in the way you have in this doc. The variations overview section uses the term, defining it as "a set of source font data... used in a font-development workflow". It could be used elsewhere in the spec with that meaning, but the wording should make clear that it refers to source data. 

In your doc, it's not clear whether you mean "instance" or a default value combined with a (not attenuated) delta. The latter concept necessarily has to refer to some specific value in the font, which could be an outline coordinate, a metric value, or any other single, variable value. But when it comes to data in the font file there is nothing that corresponds to a source master.


A question about this: I gather that this would require changes in CFF2 rasterizers?


Peter

-----Original Message-----
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Skef Iterum via mpeg-otspec
Sent: Monday, February 5, 2024 3:23 AM
To: mpeg-otspec at lists.aau.at
Subject: [EXTERNAL] [MPEG-OTSPEC] Relaxation of CFF2 hint requirements (?) in variable fonts

A short proposal to relax the requirements on stem hints in a CFF2 variable font should be attached. These changes (or clarifications -- see below) are comparable to allowing overlap in CFF2; what could easily be normalized away in a static context winds up being needed in a variable context.

Note that these changes do not affect the storage format, and one could argue that one or even both is compatible with the current standard (given that nothing much is said on the subject). Still, they may raise issues about versioning. My sense is that if a font built according to the clarifications is rasterized on a system assuming total ordering of stems and/or no duplicate stems, the result will be as if some stems are missing rather than overt distortion of a glyph. And the need for such stems is relative rare, so only a few glyphs in a typical font are likely to be affected.

We can talk about versioning questions as part of the discussion.

Skef
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/620ef5a3/attachment.htm>

From skef at skef.org  Mon Feb  5 22:01:09 2024
From: skef at skef.org (Skef Iterum)
Date: Mon, 5 Feb 2024 13:01:09 -0800
Subject: [MPEG-OTSPEC] [EXTERNAL] Relaxation of CFF2 hint requirements
 (?) in variable fonts
In-Reply-To: <PH7PR21MB33085EBEEDEB488B633C120DDE472@PH7PR21MB3308.namprd21.prod.outlook.com>
References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org>
 <PH7PR21MB33085EBEEDEB488B633C120DDE472@PH7PR21MB3308.namprd21.prod.outlook.com>
Message-ID: <4dfddcc8-32dc-4d77-a6dd-33731bc50cb6@skef.org>

I'll update the document to remove the use of "master". I meant 
instance, in this case.

Whether adopting this proposal would require a change in how CFF2 
rasterizers are implemented depends on how they were implemented before. 
I've seen some code that trusts that stems arrive sorted and some code 
that doesn't (the latter either resorting and doing something clever 
with the masks or just going through the list to find the best match 
every time). And if code only looks at "active" stems when matching, 
there should only be one active stem with a given position and width, so 
duplication wouldn't matter.

So it boils down to the particular heuristics of the particular 
implementation.

Skef

On 2/5/24 12:43, Peter Constable wrote:
> Hi, Skef
>
> The term "master" should not be used in the way you have in this doc. The variations overview section uses the term, defining it as "a set of source font data... used in a font-development workflow". It could be used elsewhere in the spec with that meaning, but the wording should make clear that it refers to source data.
>
> In your doc, it's not clear whether you mean "instance" or a default value combined with a (not attenuated) delta. The latter concept necessarily has to refer to some specific value in the font, which could be an outline coordinate, a metric value, or any other single, variable value. But when it comes to data in the font file there is nothing that corresponds to a source master.
>
>
> A question about this: I gather that this would require changes in CFF2 rasterizers?
>
>
> Peter
>
> -----Original Message-----
> From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Skef Iterum via mpeg-otspec
> Sent: Monday, February 5, 2024 3:23 AM
> To: mpeg-otspec at lists.aau.at
> Subject: [EXTERNAL] [MPEG-OTSPEC] Relaxation of CFF2 hint requirements (?) in variable fonts
>
> A short proposal to relax the requirements on stem hints in a CFF2 variable font should be attached. These changes (or clarifications -- see below) are comparable to allowing overlap in CFF2; what could easily be normalized away in a static context winds up being needed in a variable context.
>
> Note that these changes do not affect the storage format, and one could argue that one or even both is compatible with the current standard (given that nothing much is said on the subject). Still, they may raise issues about versioning. My sense is that if a font built according to the clarifications is rasterized on a system assuming total ordering of stems and/or no duplicate stems, the result will be as if some stems are missing rather than overt distortion of a glyph. And the need for such stems is relative rare, so only a few glyphs in a typical font are likely to be affected.
>
> We can talk about versioning questions as part of the discussion.
>
> Skef

From tphinney at cal.berkeley.edu  Mon Feb  5 22:03:56 2024
From: tphinney at cal.berkeley.edu (Thomas Phinney)
Date: Mon, 5 Feb 2024 13:03:56 -0800
Subject: [MPEG-OTSPEC] [EXTERNAL] Relaxation of CFF2 hint requirements
 (?) in variable fonts
In-Reply-To: <2140608869.8781385.1707166407350@mail.yahoo.com>
References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org>
 <PH7PR21MB33085EBEEDEB488B633C120DDE472@PH7PR21MB3308.namprd21.prod.outlook.com>
 <2140608869.8781385.1707166407350@mail.yahoo.com>
Message-ID: <CAO6Fj1VGyaVOAWYcMYYtH1wMrRFiTO0FE0j_gu348F3WXLG9Uw@mail.gmail.com>

IIRC, we had a (very lengthy!) discussion of this same issue internally at
FontLab back when I was CEO.

We never came up with an alternate word that seemed workable for the font
data concept. ?Main? really does seem *singular* in a way that ?master? is
not necessarily.

If somebody proposes a good alternative word, I expect people would be
happy to entertain a change request?I just couldn?t think of something.




On Mon, Feb 5, 2024 at 12:53?PM Hin-Tak Leung via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> That reminds me - the git/git[hub,lab,...] people have been moving away
> from "master" as the name of the default branch, to "main", because of the
> word's colonial connotations.
>
> Maybe the opentype spec should avoid the word "master" for that reason too.
>
> On Monday, 5 February 2024 at 20:44:15 GMT, Peter Constable via
> mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>
>
> Hi, Skef
>
> The term "master" should not be used in the way you have in this doc. The
> variations overview section uses the term, defining it as "a set of source
> font data... used in a font-development workflow". It could be used
> elsewhere in the spec with that meaning, but the wording should make clear
> that it refers to source data.
>
> In your doc, it's not clear whether you mean "instance" or a default value
> combined with a (not attenuated) delta. The latter concept necessarily has
> to refer to some specific value in the font, which could be an outline
> coordinate, a metric value, or any other single, variable value. But when
> it comes to data in the font file there is nothing that corresponds to a
> source master.
>
>
> A question about this: I gather that this would require changes in CFF2
> rasterizers?
>
>
> Peter
>
> -----Original Message-----
> From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Skef
> Iterum via mpeg-otspec
> Sent: Monday, February 5, 2024 3:23 AM
> To: mpeg-otspec at lists.aau.at
> Subject: [EXTERNAL] [MPEG-OTSPEC] Relaxation of CFF2 hint requirements (?)
> in variable fonts
>
> A short proposal to relax the requirements on stem hints in a CFF2
> variable font should be attached. These changes (or clarifications -- see
> below) are comparable to allowing overlap in CFF2; what could easily be
> normalized away in a static context winds up being needed in a variable
> context.
>
> Note that these changes do not affect the storage format, and one could
> argue that one or even both is compatible with the current standard (given
> that nothing much is said on the subject). Still, they may raise issues
> about versioning. My sense is that if a font built according to the
> clarifications is rasterized on a system assuming total ordering of stems
> and/or no duplicate stems, the result will be as if some stems are missing
> rather than overt distortion of a glyph. And the need for such stems is
> relative rare, so only a few glyphs in a typical font are likely to be
> affected.
>
> We can talk about versioning questions as part of the discussion.
>
> Skef
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/e096f320/attachment-0001.htm>

From htl10 at users.sourceforge.net  Mon Feb  5 22:32:55 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Mon, 5 Feb 2024 21:32:55 +0000 (UTC)
Subject: [MPEG-OTSPEC] [EXTERNAL] Relaxation of CFF2 hint requirements
 (?) in variable fonts
In-Reply-To: <CAO6Fj1VGyaVOAWYcMYYtH1wMrRFiTO0FE0j_gu348F3WXLG9Uw@mail.gmail.com>
References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org>
 <PH7PR21MB33085EBEEDEB488B633C120DDE472@PH7PR21MB3308.namprd21.prod.outlook.com>
 <2140608869.8781385.1707166407350@mail.yahoo.com>
 <CAO6Fj1VGyaVOAWYcMYYtH1wMrRFiTO0FE0j_gu348F3WXLG9Uw@mail.gmail.com>
Message-ID: <1709905589.8795378.1707168775084@mail.yahoo.com>

 For some of its current usage, the word "master" can be replaced with "primary". The other usage, and in plurals, "masters" (as in variable fonts) are really corner states / extremas . There is probably a better word to mean a "pure instance" of some sort?
"primary/primaries" probably can work? "primary source data"? "Source primary"?
    On Monday, 5 February 2024 at 21:04:50 GMT, Thomas Phinney <tphinney at cal.berkeley.edu> wrote:  
 
 IIRC, we had a (very lengthy!) discussion of this same issue internally at FontLab back when I was CEO.
We never came up with an alternate word that seemed workable for the font data concept. ?Main? really does seem singular in a way that ?master? is not necessarily.
If somebody proposes?a good alternative word, I expect people would be happy to entertain a change request?I just couldn?t think of something.



On Mon, Feb 5, 2024 at 12:53?PM Hin-Tak Leung via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:

 That reminds me - the git/git[hub,lab,...] people have been moving away from "master" as the name of the default branch, to "main", because of the word's colonial connotations.
Maybe the opentype spec should avoid the word "master" for that reason too.
    On Monday, 5 February 2024 at 20:44:15 GMT, Peter Constable via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 Hi, Skef

The term "master" should not be used in the way you have in this doc. The variations overview section uses the term, defining it as "a set of source font data... used in a font-development workflow". It could be used elsewhere in the spec with that meaning, but the wording should make clear that it refers to source data. 

In your doc, it's not clear whether you mean "instance" or a default value combined with a (not attenuated) delta. The latter concept necessarily has to refer to some specific value in the font, which could be an outline coordinate, a metric value, or any other single, variable value. But when it comes to data in the font file there is nothing that corresponds to a source master.


A question about this: I gather that this would require changes in CFF2 rasterizers?


Peter

-----Original Message-----
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Skef Iterum via mpeg-otspec
Sent: Monday, February 5, 2024 3:23 AM
To: mpeg-otspec at lists.aau.at
Subject: [EXTERNAL] [MPEG-OTSPEC] Relaxation of CFF2 hint requirements (?) in variable fonts

A short proposal to relax the requirements on stem hints in a CFF2 variable font should be attached. These changes (or clarifications -- see below) are comparable to allowing overlap in CFF2; what could easily be normalized away in a static context winds up being needed in a variable context.

Note that these changes do not affect the storage format, and one could argue that one or even both is compatible with the current standard (given that nothing much is said on the subject). Still, they may raise issues about versioning. My sense is that if a font built according to the clarifications is rasterized on a system assuming total ordering of stems and/or no duplicate stems, the result will be as if some stems are missing rather than overt distortion of a glyph. And the need for such stems is relative rare, so only a few glyphs in a typical font are likely to be affected.

We can talk about versioning questions as part of the discussion.

Skef
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  _______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/4cc7f8eb/attachment.htm>

From skef at skef.org  Tue Feb  6 01:03:58 2024
From: skef at skef.org (Skef Iterum)
Date: Mon, 5 Feb 2024 16:03:58 -0800
Subject: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
In-Reply-To: <SJ0PR00MB103926806416F78F8915D807BE792@SJ0PR00MB1039.namprd00.prod.outlook.com>
References: <47d8e424-1793-412f-a711-8def6afc7ec3@skef.org>
 <B02B15FD-D72A-46DD-BC77-50D5729E47E9@lorp.org>
 <a80c6236-f441-4715-9468-bc142ba6536b@skef.org>
 <SJ0PR00MB103926806416F78F8915D807BE792@SJ0PR00MB1039.namprd00.prod.outlook.com>
Message-ID: <d11ab5a1-8adb-4e59-8a9e-7a1b6f91a223@skef.org>

Coming back to this subject --

We just did a couple explicit tests and it appears that the developing 
understanding is still conflating two distinct things: whether and how 
the /context/ that the font is being rendered in is transformed, and 
whether and how a component of a composite glyph is transformed.

One might imagine a rasterizer that does something like the following:

 1. Each component is given access to CVT-derived values that take into
    account the total transformation of the component (any "external"
    transformation plus any transformation at the composite level).
 2. Whether grid-fitting is active depends on those component-specific
    CVT values. If there is rotation or skew the fitting might always be
    off. If there is just scaling maybe it is left on.
 3. If the instructions are on, they apply to the points of the
    component /post-/tranformation.

What our experiments imply is:

 1. The CVT values only vary by "external" transformation, not component
    transformation. Therefore if there is no "external" skew or
    rotation, instructions will generally be turned on for every component.
 2. Grid-fitting of the component occurs /pre-/transformation. The
    points of the component are transformed to their final locations in
    a later step.

So if this is accurate the typical result of rendering a component with 
a skew and/or rotation in a context that does not have skew and/or 
rotation will be to grid-fit the "original" component using its hint 
data and then transforming the result. This will yield a glyph that is 
distorted (due to the grid-fitting) but not hinted according to the 
pixel grid it is rendered against.

So, one thing the VARC specification could, well, /specify/ is that VARC 
components extracted from the glyf table are hinted more like the first 
list above than the second -- with further details presumably to be 
worked out. That way, with an appropriate header, grid fitting could be 
on or off depending on the total transformation of the component. 
Whether the existing instruction set is rich enough to handle 
non-uniform scaling when grid-fitting isn't cancelled by skew or 
rotation still seems like an open question, given that that's not how 
things seem to work in practice now. But such a change would be a start.

However, the VARC spec being added to the working draft says /nothing/ 
about hinting, apparently leaving the question of how hinting is 
supposed to be managed in the face of component transformation -- the 
latter being a central part of VARC -- unresolved.

Skef

On 1/26/24 13:04, Greg Hitchcock wrote:
>
> Through a combination of the GETINFO instruction and the INSTCTRL 
> instruction, glyphs or fonts can make educated decisions about whether 
> to apply instructions under different circumstances such as rotations, 
> stretching, &c. Typically we recommend in the pre-program to disable 
> hints under rotation, but if someone comes up with a clever algorithm 
> for handling this, that is an option.
>
> GregH
>
> *From:*mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> *On Behalf Of 
> *Skef Iterum via mpeg-otspec
> *Sent:* Friday, January 26, 2024 11:33 AM
> *To:* Laurence Penney <lorp at lorp.org>
> *Cc:* mpeg-otspec <mpeg-otspec at lists.aau.at>
> *Subject:* Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
>
>
> 	
>
> You don't often get email from mpeg-otspec at lists.aau.at. Learn why 
> this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> 	
>
> On 1/24/24 23:47, Laurence Penney wrote:
>
>         On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec
>         <mpeg-otspec at lists.aau.at> <mailto:mpeg-otspec at lists.aau.at>
>         wrote:
>
>         There is a distinction between whether the text path itself is
>         skewed or
>         rotated and whether a component in a composite is skewed or
>         rotated.
>         Asking around it seems as though with the existing glyf components
>         instructions are /not/ automatically turned off when
>         "compositing", but
>         perhaps that info is wrong.
>
>         Either way, though, that seems like something the
>         specification should
>         clarify.
>
>     I asked similar questions when I was getting my head around TT
>     hinting, and recall being told that skewed or rotated components
>     were not hinted. The person I asked would most likely have been
>     Greg Hitchcock.
>
> Josh Hadley on our team got curious about this and did an experiment 
> or two
> in VTT. As far as we can tell there is no automatic disabling of hints 
> when using
> "not nice" transformations, at least in that tool. We can provide a 
> specific
> example or two if anyone needs them.
>
> It's possible that the "client side" implementations work differently 
> than the
> development tools but designers are likely to take the guidance of 
> those tools
> unless there is very strong conventional wisdom pointing in a different
> direction.
>
> Skef
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/d86e972c/attachment-0001.htm>

From vladimir.levantovsky at gmail.com  Tue Feb  6 02:40:22 2024
From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky)
Date: Mon, 5 Feb 2024 20:40:22 -0500
Subject: [MPEG-OTSPEC] AHG meeting announcement
Message-ID: <CACJZqjDN+LLUaV_KnceSKoYDhrNHh9Y6f6m7QR7gt6Te2QA1ug@mail.gmail.com>

Dear all,

Like we discussed previously, we will have our next AHG Zoom meeting on
Feb. 20, 2024 at 15:00 UTC to review additional changes proposed for
inclusion into the current version of the Working Draft of the 5th edition
ISO/IEC 14496-22. Please see below the meeting agenda, and please review
the documents [shared on the AHG list] ahead of time to make the use of AHG
meeting time most efficient and productive.

If you're working on an updated proposal, please make sure to finalize it
and make it available for AHG review at least a week prior to the meeting.

Tentative agenda (may be updated if/when new proposals are presented):
1. Review updated Feature Variations proposal, see
https://lists.aau.at/mailman/private/mpeg-otspec/2024-February/003262.html
(the AHG email archive has recently been restored for private access, you
may need to login using your list email/PW).
2. New proposal to relax CFF2 hint requirements in variable fonts, see
https://lists.aau.at/mailman/private/mpeg-otspec/2024-February/003263.html
3. Tentative - review new 'dmap' table proposal (TBD)
4. Tentative - discuss remaining follow-up changes ('LTSH', 'hdmx', 'VARC"
updates [if any], ...)

Zoom meeting info: no changes since our last meeting. (Individual off-list
meeting invites will include all necessary info.)

All prior Zoom meeting participants will automatically get an invite, if
you have not been a participant and would like to be added to the list,
please respond directly to this email and I will add you to the invite list.

Thank you,
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/d40b7525/attachment.htm>

From liam at fromoldbooks.org  Tue Feb  6 03:16:58 2024
From: liam at fromoldbooks.org (Liam R. E. Quin)
Date: Mon, 05 Feb 2024 21:16:58 -0500
Subject: [MPEG-OTSPEC] [EXTERNAL] Relaxation of CFF2 hint requirements
 (?) in variable fonts
In-Reply-To: <1709905589.8795378.1707168775084@mail.yahoo.com>
References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org>
 <PH7PR21MB33085EBEEDEB488B633C120DDE472@PH7PR21MB3308.namprd21.prod.outlook.com>
 <2140608869.8781385.1707166407350@mail.yahoo.com>
 <CAO6Fj1VGyaVOAWYcMYYtH1wMrRFiTO0FE0j_gu348F3WXLG9Uw@mail.gmail.com>
 <1709905589.8795378.1707168775084@mail.yahoo.com>
Message-ID: <f9a65bd6563cf07bc76e0834e07498080a744455.camel@fromoldbooks.org>

On Mon, 2024-02-05 at 21:32 +0000, Hin-Tak Leung via mpeg-otspec wrote:
> ?
> For some of its current usage, the word "master" can be replaced with
> "primary". The other usage, and in plurals, "masters" (as in variable
> fonts) are really corner states / extremas . There is probably a
> better word to mean a "pure instance" of some sort?

Source design?

> "primary/primaries" probably can work? "primary source data"? "Source
> primary"?

?Primary source? already means something else, so i think that may be a
little confusing. But i wont object, either.

Best,

liam



-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.

From behdad at behdad.org  Tue Feb  6 17:55:46 2024
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 6 Feb 2024 09:55:46 -0700
Subject: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
In-Reply-To: <d11ab5a1-8adb-4e59-8a9e-7a1b6f91a223@skef.org>
References: <47d8e424-1793-412f-a711-8def6afc7ec3@skef.org>
 <B02B15FD-D72A-46DD-BC77-50D5729E47E9@lorp.org>
 <a80c6236-f441-4715-9468-bc142ba6536b@skef.org>
 <SJ0PR00MB103926806416F78F8915D807BE792@SJ0PR00MB1039.namprd00.prod.outlook.com>
 <d11ab5a1-8adb-4e59-8a9e-7a1b6f91a223@skef.org>
Message-ID: <CAF63+7Vw0kkAihgtuOBnGPJvOR3-eF202PsEPPnZWOVY=q_+Lg@mail.gmail.com>

Hi Skef,

* Indeed, CVT values are only calculated once per font, not per transformed
components.

* Is the full component transformation available to the bytecode? If yes,
we can spec that the VARC components are hinted post-transformation.

* What transformations are safe to hint can be left to the font. It can
have a function to determine that. It can even be in the `prep` code which
is run once, and set a CVT value to disable hinting fontwide if necessary.

b


behdad
http://behdad.org/


On Mon, Feb 5, 2024 at 5:04?PM Skef Iterum via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> Coming back to this subject --
>
> We just did a couple explicit tests and it appears that the developing
> understanding is still conflating two distinct things: whether and how the
> *context* that the font is being rendered in is transformed, and whether
> and how a component of a composite glyph is transformed.
>
> One might imagine a rasterizer that does something like the following:
>
>    1. Each component is given access to CVT-derived values that take into
>    account the total transformation of the component (any "external"
>    transformation plus any transformation at the composite level).
>    2. Whether grid-fitting is active depends on those component-specific
>    CVT values. If there is rotation or skew the fitting might always be off.
>    If there is just scaling maybe it is left on.
>    3. If the instructions are on, they apply to the points of the
>    component *post-*tranformation.
>
> What our experiments imply is:
>
>    1. The CVT values only vary by "external" transformation, not
>    component transformation. Therefore if there is no "external" skew or
>    rotation, instructions will generally be turned on for every component.
>    2. Grid-fitting of the component occurs *pre-*transformation. The
>    points of the component are transformed to their final locations in a later
>    step.
>
> So if this is accurate the typical result of rendering a component with a
> skew and/or rotation in a context that does not have skew and/or rotation
> will be to grid-fit the "original" component using its hint data and then
> transforming the result. This will yield a glyph that is distorted (due to
> the grid-fitting) but not hinted according to the pixel grid it is rendered
> against.
>
> So, one thing the VARC specification could, well, *specify* is that VARC
> components extracted from the glyf table are hinted more like the first
> list above than the second -- with further details presumably to be worked
> out. That way, with an appropriate header, grid fitting could be on or off
> depending on the total transformation of the component. Whether the
> existing instruction set is rich enough to handle non-uniform scaling when
> grid-fitting isn't cancelled by skew or rotation still seems like an open
> question, given that that's not how things seem to work in practice now.
> But such a change would be a start.
>
> However, the VARC spec being added to the working draft says *nothing*
> about hinting, apparently leaving the question of how hinting is supposed
> to be managed in the face of component transformation -- the latter being a
> central part of VARC -- unresolved.
>
> Skef
> On 1/26/24 13:04, Greg Hitchcock wrote:
>
> Through a combination of the GETINFO instruction and the INSTCTRL
> instruction, glyphs or fonts can make educated decisions about whether to
> apply instructions under different circumstances such as rotations,
> stretching, &c. Typically we recommend in the pre-program to disable hints
> under rotation, but if someone comes up with a clever algorithm for
> handling this, that is an option.
>
>
>
> GregH
>
>
>
> *From:* mpeg-otspec <mpeg-otspec-bounces at lists.aau.at>
> <mpeg-otspec-bounces at lists.aau.at> *On Behalf Of *Skef Iterum via
> mpeg-otspec
> *Sent:* Friday, January 26, 2024 11:33 AM
> *To:* Laurence Penney <lorp at lorp.org> <lorp at lorp.org>
> *Cc:* mpeg-otspec <mpeg-otspec at lists.aau.at> <mpeg-otspec at lists.aau.at>
> *Subject:* Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
>
>
>
> You don't often get email from mpeg-otspec at lists.aau.at. Learn why this
> is important <https://aka.ms/LearnAboutSenderIdentification>
>
>
>
> On 1/24/24 23:47, Laurence Penney wrote:
>
> On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec
> <mpeg-otspec at lists.aau.at> <mpeg-otspec at lists.aau.at> wrote:
>
> There is a distinction between whether the text path itself is skewed or
> rotated and whether a component in a composite is skewed or rotated.
> Asking around it seems as though with the existing glyf components
> instructions are *not* automatically turned off when "compositing", but
> perhaps that info is wrong.
>
> Either way, though, that seems like something the specification should
> clarify.
>
> I asked similar questions when I was getting my head around TT hinting,
> and recall being told that skewed or rotated components were not hinted.
> The person I asked would most likely have been Greg Hitchcock.
>
>
>
> Josh Hadley on our team got curious about this and did an experiment or two
> in VTT. As far as we can tell there is no automatic disabling of hints
> when using
> "not nice" transformations, at least in that tool. We can provide a
> specific
> example or two if anyone needs them.
>
> It's possible that the "client side" implementations work differently than
> the
> development tools but designers are likely to take the guidance of those
> tools
> unless there is very strong conventional wisdom pointing in a different
> direction.
>
> Skef
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240206/1f8459b4/attachment-0001.htm>

From gregh at microsoft.com  Tue Feb  6 21:36:21 2024
From: gregh at microsoft.com (Greg Hitchcock)
Date: Tue, 6 Feb 2024 20:36:21 +0000
Subject: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
In-Reply-To: <CAF63+7Vw0kkAihgtuOBnGPJvOR3-eF202PsEPPnZWOVY=q_+Lg@mail.gmail.com>
References: <47d8e424-1793-412f-a711-8def6afc7ec3@skef.org>
 <B02B15FD-D72A-46DD-BC77-50D5729E47E9@lorp.org>
 <a80c6236-f441-4715-9468-bc142ba6536b@skef.org>
 <SJ0PR00MB103926806416F78F8915D807BE792@SJ0PR00MB1039.namprd00.prod.outlook.com>
 <d11ab5a1-8adb-4e59-8a9e-7a1b6f91a223@skef.org>
 <CAF63+7Vw0kkAihgtuOBnGPJvOR3-eF202PsEPPnZWOVY=q_+Lg@mail.gmail.com>
Message-ID: <DS1PEPF0000B07D5931E0B2A2FFCE86E7E4BE462@DS1PEPF0000B07D.namprd00.prod.outlook.com>

Behdad is correct that CVT values are calculated once per font at the parent transform.

The full component transform is not available to the bytecode.

The GETINFO instruction returns Bit 8 equal to 1 if the current glyph has been rotated, and bit 9 equal to 1 if the current glyph has been stretched.

GregH

From: Behdad Esfahbod <behdad at behdad.org> Tuesday, February 6, 2024 8:56 AM


Hi Skef,

* Indeed, CVT values are only calculated once per font, not per transformed components.

* Is the full component transformation available to the bytecode? If yes, we can spec that the VARC components are hinted post-transformation.

* What transformations are safe to hint can be left to the font. It can have a function to determine that. It can even be in the `prep` code which is run once, and set a CVT value to disable hinting fontwide if necessary.

b


behdad
http://behdad.org/


On Mon, Feb 5, 2024 at 5:04?PM Skef Iterum via mpeg-otspec <mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>> wrote:

Coming back to this subject --

We just did a couple explicit tests and it appears that the developing understanding is still conflating two distinct things: whether and how the context that the font is being rendered in is transformed, and whether and how a component of a composite glyph is transformed.

One might imagine a rasterizer that does something like the following:

  1.  Each component is given access to CVT-derived values that take into account the total transformation of the component (any "external" transformation plus any transformation at the composite level).
  2.  Whether grid-fitting is active depends on those component-specific CVT values. If there is rotation or skew the fitting might always be off. If there is just scaling maybe it is left on.
  3.  If the instructions are on, they apply to the points of the component post-tranformation.

What our experiments imply is:

  1.  The CVT values only vary by "external" transformation, not component transformation. Therefore if there is no "external" skew or rotation, instructions will generally be turned on for every component.
  2.  Grid-fitting of the component occurs pre-transformation. The points of the component are transformed to their final locations in a later step.

So if this is accurate the typical result of rendering a component with a skew and/or rotation in a context that does not have skew and/or rotation will be to grid-fit the "original" component using its hint data and then transforming the result. This will yield a glyph that is distorted (due to the grid-fitting) but not hinted according to the pixel grid it is rendered against.

So, one thing the VARC specification could, well, specify is that VARC components extracted from the glyf table are hinted more like the first list above than the second -- with further details presumably to be worked out. That way, with an appropriate header, grid fitting could be on or off depending on the total transformation of the component. Whether the existing instruction set is rich enough to handle non-uniform scaling when grid-fitting isn't cancelled by skew or rotation still seems like an open question, given that that's not how things seem to work in practice now. But such a change would be a start.

However, the VARC spec being added to the working draft says nothing about hinting, apparently leaving the question of how hinting is supposed to be managed in the face of component transformation -- the latter being a central part of VARC -- unresolved.

Skef
On 1/26/24 13:04, Greg Hitchcock wrote:
Through a combination of the GETINFO instruction and the INSTCTRL instruction, glyphs or fonts can make educated decisions about whether to apply instructions under different circumstances such as rotations, stretching, &c. Typically we recommend in the pre-program to disable hints under rotation, but if someone comes up with a clever algorithm for handling this, that is an option.

GregH

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at><mailto:mpeg-otspec-bounces at lists.aau.at> On Behalf Of Skef Iterum via mpeg-otspec
Sent: Friday, January 26, 2024 11:33 AM
To: Laurence Penney <lorp at lorp.org><mailto:lorp at lorp.org>
Cc: mpeg-otspec <mpeg-otspec at lists.aau.at><mailto:mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions

You don't often get email from mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>


On 1/24/24 23:47, Laurence Penney wrote:
On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec <mpeg-otspec at lists.aau.at><mailto:mpeg-otspec at lists.aau.at> wrote:
There is a distinction between whether the text path itself is skewed or
rotated and whether a component in a composite is skewed or rotated.
Asking around it seems as though with the existing glyf components
instructions are not automatically turned off when "compositing", but
perhaps that info is wrong.

Either way, though, that seems like something the specification should
clarify.
I asked similar questions when I was getting my head around TT hinting, and recall being told that skewed or rotated components were not hinted. The person I asked would most likely have been Greg Hitchcock.

Josh Hadley on our team got curious about this and did an experiment or two
in VTT. As far as we can tell there is no automatic disabling of hints when using
"not nice" transformations, at least in that tool. We can provide a specific
example or two if anyone needs them.

It's possible that the "client side" implementations work differently than the
development tools but designers are likely to take the guidance of those tools
unless there is very strong conventional wisdom pointing in a different
direction.

Skef
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>
https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240206/ad9f5f98/attachment-0001.htm>

From htl10 at users.sourceforge.net  Wed Feb  7 02:37:12 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Wed, 7 Feb 2024 01:37:12 +0000 (UTC)
Subject: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
In-Reply-To: <DS1PEPF0000B07D5931E0B2A2FFCE86E7E4BE462@DS1PEPF0000B07D.namprd00.prod.outlook.com>
References: <47d8e424-1793-412f-a711-8def6afc7ec3@skef.org>
 <B02B15FD-D72A-46DD-BC77-50D5729E47E9@lorp.org>
 <a80c6236-f441-4715-9468-bc142ba6536b@skef.org>
 <SJ0PR00MB103926806416F78F8915D807BE792@SJ0PR00MB1039.namprd00.prod.outlook.com>
 <d11ab5a1-8adb-4e59-8a9e-7a1b6f91a223@skef.org>
 <CAF63+7Vw0kkAihgtuOBnGPJvOR3-eF202PsEPPnZWOVY=q_+Lg@mail.gmail.com>
 <DS1PEPF0000B07D5931E0B2A2FFCE86E7E4BE462@DS1PEPF0000B07D.namprd00.prod.outlook.com>
Message-ID: <1240201732.9709744.1707269832780@mail.yahoo.com>

 Apparently GETINFO bit 10 returns GX variation font support (this is undocumented AFAIK, and also what GETINFO does for the higher bits 10 onwards are undocumented), and there is an undocumented truetype instruction GETVARIATION for obtaining GX variation axes.
Might be interesting to "overload" that bit 10 and that instruction with new meanings for opentype variable fonts.
    On Tuesday, 6 February 2024 at 20:36:58 GMT, Greg Hitchcock via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 
Behdad is correct that CVT values are calculated once per font at the parent transform.
 
 ?
 
The full component transform is not available to the bytecode.
 
 ?
 
The GETINFO instruction returns Bit 8 equal to 1 if the current glyph has been rotated, and bit 9 equal to 1 if the current glyph has been stretched.
 
 ?
 
GregH
 
 ?
 
From: Behdad Esfahbod <behdad at behdad.org> Tuesday, February 6, 2024 8:56 AM


 
 ?
 
Hi Skef,
 
 ?
 
* Indeed, CVT values are only calculated once per font, not per transformed components.
 
 ?
 
* Is the full component transformation available to the bytecode? If yes, we can spec that the VARC components are hinted post-transformation.
 
 ?
 
* What transformations are safe to hint can be left to the font. It can have a function to determine that. It can even be in the `prep` code which is run once, and set a CVT value to disable hinting fontwide if necessary.
 
 ?
 
b
 
 ?
 


 
behdad
http://behdad.org/
 
 ?
 
 ?
 
On Mon, Feb 5, 2024 at 5:04?PM Skef Iterum via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
 

Coming back to this subject --
 
We just did a couple explicit tests and it appears that the developing understanding is still conflating two distinct things: whether and how thecontext that the font is being rendered in is transformed, and whether and how a component of a composite glyph is transformed.
 
One might imagine a rasterizer that does something like the following:
    
   - Each component is given access to CVT-derived values that take into account the total transformation of the component (any "external" transformation plus any transformation at the composite level).
   - Whether grid-fitting is active depends on those component-specific CVT values. If there is rotation or skew the fitting might always be off. If there is just scaling maybe it is left on.
   - If the instructions are on, they apply to the points of the component post-tranformation.
 
What our experiments imply is:
    
   - The CVT values only vary by "external" transformation, not component transformation. Therefore if there is no "external" skew or rotation, instructions will generally be turned on for every component.
   - Grid-fitting of the component occurs pre-transformation. The points of the component are transformed to their final locations in a later step.
 
So if this is accurate the typical result of rendering a component with a skew and/or rotation in a context that does not have skew and/or rotation will be to grid-fit the "original" component using its hint data and then transforming the result. This will yield a glyph that is distorted (due to the grid-fitting) but not hinted according to the pixel grid it is rendered against.
 
So, one thing the VARC specification could, well, specify is that VARC components extracted from the glyf table are hinted more like the first list above than the second -- with further details presumably to be worked out. That way, with an appropriate header, grid fitting could be on or off depending on the total transformation of the component. Whether the existing instruction set is rich enough to handle non-uniform scaling when grid-fitting isn't cancelled by skew or rotation still seems like an open question, given that that's not how things seem to work in practice now. But such a change would be a start.
 
However, the VARC spec being added to the working draft says nothing about hinting, apparently leaving the question of how hinting is supposed to be managed in the face of component transformation -- the latter being a central part of VARC -- unresolved.
 
Skef
 
On 1/26/24 13:04, Greg Hitchcock wrote:
 

Through a combination of the GETINFO instruction and the INSTCTRL instruction, glyphs or fonts can make educated decisions about whether to apply instructions under different circumstances such as rotations, stretching, &c. Typically we recommend in the pre-program to disable hints under rotation, but if someone comes up with a clever algorithm for handling this, that is an option.
 
?
 
GregH
 
?
 
From: mpeg-otspec<mpeg-otspec-bounces at lists.aau.at>On Behalf Of Skef Iterum via mpeg-otspec
Sent: Friday, January 26, 2024 11:33 AM
To: Laurence Penney <lorp at lorp.org>
Cc: mpeg-otspec <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
 
?
 
|  | 
You don't often get email frommpeg-otspec at lists.aau.at.Learn why this is important
  |  |


?
 
On 1/24/24 23:47, Laurence Penney wrote:
 


On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec<mpeg-otspec at lists.aau.at> wrote:
 


There is a distinction between whether the text path itself is skewed or
rotated and whether a component in a composite is skewed or rotated.
Asking around it seems as though with the existing glyf components
instructions are not automatically turned off when "compositing", but
perhaps that info is wrong. 
 
Either way, though, that seems like something the specification should
clarify.
 

I asked similar questions when I was getting my head around TT hinting, and recall being told that skewed or rotated components were not hinted. The person I asked would most likely have been Greg Hitchcock.
 
?
 

Josh Hadley on our team got curious about this and did an experiment or two
in VTT. As far as we can tell there is no automatic disabling of hints when using
"not nice" transformations, at least in that tool. We can provide a specific
example or two if anyone needs them.

It's possible that the "client side" implementations work differently than the 
development tools but designers are likely to take the guidance of those tools
unless there is very strong conventional wisdom pointing in a different
direction.
 
Skef
 

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
 
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240207/74ee706d/attachment.htm>

From behdad at behdad.org  Wed Feb  7 02:41:52 2024
From: behdad at behdad.org (Behdad Esfahbod)
Date: Tue, 6 Feb 2024 18:41:52 -0700
Subject: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
In-Reply-To: <1240201732.9709744.1707269832780@mail.yahoo.com>
References: <47d8e424-1793-412f-a711-8def6afc7ec3@skef.org>
 <B02B15FD-D72A-46DD-BC77-50D5729E47E9@lorp.org>
 <a80c6236-f441-4715-9468-bc142ba6536b@skef.org>
 <SJ0PR00MB103926806416F78F8915D807BE792@SJ0PR00MB1039.namprd00.prod.outlook.com>
 <d11ab5a1-8adb-4e59-8a9e-7a1b6f91a223@skef.org>
 <CAF63+7Vw0kkAihgtuOBnGPJvOR3-eF202PsEPPnZWOVY=q_+Lg@mail.gmail.com>
 <DS1PEPF0000B07D5931E0B2A2FFCE86E7E4BE462@DS1PEPF0000B07D.namprd00.prod.outlook.com>
 <1240201732.9709744.1707269832780@mail.yahoo.com>
Message-ID: <CAF63+7XqRuKsMLHe9KYzgOpjwu3dxfgR==u7SAuanwdRLWfN8A@mail.gmail.com>

On Tue, Feb 6, 2024, 6:37?PM Hin-Tak Leung <htl10 at users.sourceforge.net>
wrote:

> Apparently GETINFO bit 10 returns GX variation font support (this is
> undocumented AFAIK, and also what GETINFO does for the higher bits 10
> onwards are undocumented), and there is an undocumented truetype
> instruction GETVARIATION for obtaining GX variation axes.
>

Search for GET in:
https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview



Might be interesting to "overload" that bit 10 and that instruction with
> new meanings for opentype variable fonts.
>
> On Tuesday, 6 February 2024 at 20:36:58 GMT, Greg Hitchcock via
> mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>
>
> Behdad is correct that CVT values are calculated once per font at the
> parent transform.
>
>
>
> The full component transform is not available to the bytecode.
>
>
>
> The GETINFO instruction returns Bit 8 equal to 1 if the current glyph has
> been rotated, and bit 9 equal to 1 if the current glyph has been stretched.
>
>
>
> GregH
>
>
>
> *From:* Behdad Esfahbod <behdad at behdad.org> Tuesday, February 6, 2024
> 8:56 AM
>
>
>
> Hi Skef,
>
>
>
> * Indeed, CVT values are only calculated once per font, not per
> transformed components.
>
>
>
> * Is the full component transformation available to the bytecode? If yes,
> we can spec that the VARC components are hinted post-transformation.
>
>
>
> * What transformations are safe to hint can be left to the font. It can
> have a function to determine that. It can even be in the `prep` code which
> is run once, and set a CVT value to disable hinting fontwide if necessary.
>
>
>
> b
>
>
>
>
> behdad
> http://behdad.org/
>
>
>
>
>
> On Mon, Feb 5, 2024 at 5:04?PM Skef Iterum via mpeg-otspec <
> mpeg-otspec at lists.aau.at> wrote:
>
> Coming back to this subject --
>
> We just did a couple explicit tests and it appears that the developing
> understanding is still conflating two distinct things: whether and how the
> *context* that the font is being rendered in is transformed, and whether
> and how a component of a composite glyph is transformed.
>
> One might imagine a rasterizer that does something like the following:
>
>    1. Each component is given access to CVT-derived values that take into
>    account the total transformation of the component (any "external"
>    transformation plus any transformation at the composite level).
>    2. Whether grid-fitting is active depends on those component-specific
>    CVT values. If there is rotation or skew the fitting might always be off.
>    If there is just scaling maybe it is left on.
>    3. If the instructions are on, they apply to the points of the
>    component *post-*tranformation.
>
> What our experiments imply is:
>
>    1. The CVT values only vary by "external" transformation, not
>    component transformation. Therefore if there is no "external" skew or
>    rotation, instructions will generally be turned on for every component.
>    2. Grid-fitting of the component occurs *pre-*transformation. The
>    points of the component are transformed to their final locations in a later
>    step.
>
> So if this is accurate the typical result of rendering a component with a
> skew and/or rotation in a context that does not have skew and/or rotation
> will be to grid-fit the "original" component using its hint data and then
> transforming the result. This will yield a glyph that is distorted (due to
> the grid-fitting) but not hinted according to the pixel grid it is rendered
> against.
>
> So, one thing the VARC specification could, well, *specify* is that VARC
> components extracted from the glyf table are hinted more like the first
> list above than the second -- with further details presumably to be worked
> out. That way, with an appropriate header, grid fitting could be on or off
> depending on the total transformation of the component. Whether the
> existing instruction set is rich enough to handle non-uniform scaling when
> grid-fitting isn't cancelled by skew or rotation still seems like an open
> question, given that that's not how things seem to work in practice now.
> But such a change would be a start.
>
> However, the VARC spec being added to the working draft says *nothing*
> about hinting, apparently leaving the question of how hinting is supposed
> to be managed in the face of component transformation -- the latter being a
> central part of VARC -- unresolved.
>
> Skef
>
> On 1/26/24 13:04, Greg Hitchcock wrote:
>
> Through a combination of the GETINFO instruction and the INSTCTRL
> instruction, glyphs or fonts can make educated decisions about whether to
> apply instructions under different circumstances such as rotations,
> stretching, &c. Typically we recommend in the pre-program to disable hints
> under rotation, but if someone comes up with a clever algorithm for
> handling this, that is an option.
>
>
>
> GregH
>
>
>
> *From:* mpeg-otspec <mpeg-otspec-bounces at lists.aau.at>
> <mpeg-otspec-bounces at lists.aau.at> *On Behalf Of *Skef Iterum via
> mpeg-otspec
> *Sent:* Friday, January 26, 2024 11:33 AM
> *To:* Laurence Penney <lorp at lorp.org> <lorp at lorp.org>
> *Cc:* mpeg-otspec <mpeg-otspec at lists.aau.at> <mpeg-otspec at lists.aau.at>
> *Subject:* Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
>
>
>
> You don't often get email from mpeg-otspec at lists.aau.at. Learn why this
> is important <https://aka.ms/LearnAboutSenderIdentification>
>
>
>
> On 1/24/24 23:47, Laurence Penney wrote:
>
> On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec
> <mpeg-otspec at lists.aau.at> <mpeg-otspec at lists.aau.at> wrote:
>
> There is a distinction between whether the text path itself is skewed or
> rotated and whether a component in a composite is skewed or rotated.
> Asking around it seems as though with the existing glyf components
> instructions are *not* automatically turned off when "compositing", but
> perhaps that info is wrong.
>
> Either way, though, that seems like something the specification should
> clarify.
>
> I asked similar questions when I was getting my head around TT hinting,
> and recall being told that skewed or rotated components were not hinted.
> The person I asked would most likely have been Greg Hitchcock.
>
>
>
> Josh Hadley on our team got curious about this and did an experiment or two
> in VTT. As far as we can tell there is no automatic disabling of hints
> when using
> "not nice" transformations, at least in that tool. We can provide a
> specific
> example or two if anyone needs them.
>
> It's possible that the "client side" implementations work differently than
> the
> development tools but designers are likely to take the guidance of those
> tools
> unless there is very strong conventional wisdom pointing in a different
> direction.
>
> Skef
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240206/cc5d0bf3/attachment-0001.htm>

From htl10 at users.sourceforge.net  Wed Feb  7 15:48:38 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Wed, 7 Feb 2024 14:48:38 +0000 (UTC)
Subject: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
In-Reply-To: <CAF63+7XqRuKsMLHe9KYzgOpjwu3dxfgR==u7SAuanwdRLWfN8A@mail.gmail.com>
References: <47d8e424-1793-412f-a711-8def6afc7ec3@skef.org>
 <B02B15FD-D72A-46DD-BC77-50D5729E47E9@lorp.org>
 <a80c6236-f441-4715-9468-bc142ba6536b@skef.org>
 <SJ0PR00MB103926806416F78F8915D807BE792@SJ0PR00MB1039.namprd00.prod.outlook.com>
 <d11ab5a1-8adb-4e59-8a9e-7a1b6f91a223@skef.org>
 <CAF63+7Vw0kkAihgtuOBnGPJvOR3-eF202PsEPPnZWOVY=q_+Lg@mail.gmail.com>
 <DS1PEPF0000B07D5931E0B2A2FFCE86E7E4BE462@DS1PEPF0000B07D.namprd00.prod.outlook.com>
 <1240201732.9709744.1707269832780@mail.yahoo.com>
 <CAF63+7XqRuKsMLHe9KYzgOpjwu3dxfgR==u7SAuanwdRLWfN8A@mail.gmail.com>
Message-ID: <130869330.10181893.1707317318935@mail.yahoo.com>

 The more relevant url is https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions#miscellaneous-instructions . But as I said, a fair chunk of it is under-documented.


    On Wednesday, 7 February 2024 at 01:42:12 GMT, Behdad Esfahbod <behdad at behdad.org> wrote:  
 
 On Tue, Feb 6, 2024, 6:37?PM Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:

 Apparently GETINFO bit 10 returns GX variation font support (this is undocumented AFAIK, and also what GETINFO does for the higher bits 10 onwards are undocumented), and there is an undocumented truetype instruction GETVARIATION for obtaining GX variation axes.

Search for GET in:https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview




Might be interesting to "overload" that bit 10 and that instruction with new meanings for opentype variable fonts.
    On Tuesday, 6 February 2024 at 20:36:58 GMT, Greg Hitchcock via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 
Behdad is correct that CVT values are calculated once per font at the parent transform.
 
 ?
 
The full component transform is not available to the bytecode.
 
 ?
 
The GETINFO instruction returns Bit 8 equal to 1 if the current glyph has been rotated, and bit 9 equal to 1 if the current glyph has been stretched.
 
 ?
 
GregH
 
 ?
 
From: Behdad Esfahbod <behdad at behdad.org> Tuesday, February 6, 2024 8:56 AM


 
 ?
 
Hi Skef,
 
 ?
 
* Indeed, CVT values are only calculated once per font, not per transformed components.
 
 ?
 
* Is the full component transformation available to the bytecode? If yes, we can spec that the VARC components are hinted post-transformation.
 
 ?
 
* What transformations are safe to hint can be left to the font. It can have a function to determine that. It can even be in the `prep` code which is run once, and set a CVT value to disable hinting fontwide if necessary.
 
 ?
 
b
 
 ?
 


 
behdad
http://behdad.org/
 
 ?
 
 ?
 
On Mon, Feb 5, 2024 at 5:04?PM Skef Iterum via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
 

Coming back to this subject --
 
We just did a couple explicit tests and it appears that the developing understanding is still conflating two distinct things: whether and how thecontext that the font is being rendered in is transformed, and whether and how a component of a composite glyph is transformed.
 
One might imagine a rasterizer that does something like the following:
    
   - Each component is given access to CVT-derived values that take into account the total transformation of the component (any "external" transformation plus any transformation at the composite level).
   - Whether grid-fitting is active depends on those component-specific CVT values. If there is rotation or skew the fitting might always be off. If there is just scaling maybe it is left on.
   - If the instructions are on, they apply to the points of the component post-tranformation.
 
What our experiments imply is:
    
   - The CVT values only vary by "external" transformation, not component transformation. Therefore if there is no "external" skew or rotation, instructions will generally be turned on for every component.
   - Grid-fitting of the component occurs pre-transformation. The points of the component are transformed to their final locations in a later step.
 
So if this is accurate the typical result of rendering a component with a skew and/or rotation in a context that does not have skew and/or rotation will be to grid-fit the "original" component using its hint data and then transforming the result. This will yield a glyph that is distorted (due to the grid-fitting) but not hinted according to the pixel grid it is rendered against.
 
So, one thing the VARC specification could, well, specify is that VARC components extracted from the glyf table are hinted more like the first list above than the second -- with further details presumably to be worked out. That way, with an appropriate header, grid fitting could be on or off depending on the total transformation of the component. Whether the existing instruction set is rich enough to handle non-uniform scaling when grid-fitting isn't cancelled by skew or rotation still seems like an open question, given that that's not how things seem to work in practice now. But such a change would be a start.
 
However, the VARC spec being added to the working draft says nothing about hinting, apparently leaving the question of how hinting is supposed to be managed in the face of component transformation -- the latter being a central part of VARC -- unresolved.
 
Skef
 
On 1/26/24 13:04, Greg Hitchcock wrote:
 

Through a combination of the GETINFO instruction and the INSTCTRL instruction, glyphs or fonts can make educated decisions about whether to apply instructions under different circumstances such as rotations, stretching, &c. Typically we recommend in the pre-program to disable hints under rotation, but if someone comes up with a clever algorithm for handling this, that is an option.
 
?
 
GregH
 
?
 
From: mpeg-otspec<mpeg-otspec-bounces at lists.aau.at>On Behalf Of Skef Iterum via mpeg-otspec
Sent: Friday, January 26, 2024 11:33 AM
To: Laurence Penney <lorp at lorp.org>
Cc: mpeg-otspec <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
 
?
 
|  | 
You don't often get email frommpeg-otspec at lists.aau.at.Learn why this is important
  |  |


?
 
On 1/24/24 23:47, Laurence Penney wrote:
 


On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec<mpeg-otspec at lists.aau.at> wrote:
 


There is a distinction between whether the text path itself is skewed or
rotated and whether a component in a composite is skewed or rotated.
Asking around it seems as though with the existing glyf components
instructions are not automatically turned off when "compositing", but
perhaps that info is wrong. 
 
Either way, though, that seems like something the specification should
clarify.
 

I asked similar questions when I was getting my head around TT hinting, and recall being told that skewed or rotated components were not hinted. The person I asked would most likely have been Greg Hitchcock.
 
?
 

Josh Hadley on our team got curious about this and did an experiment or two
in VTT. As far as we can tell there is no automatic disabling of hints when using
"not nice" transformations, at least in that tool. We can provide a specific
example or two if anyone needs them.

It's possible that the "client side" implementations work differently than the 
development tools but designers are likely to take the guidance of those tools
unless there is very strong conventional wisdom pointing in a different
direction.
 
Skef
 

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
 
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240207/561b2f74/attachment.htm>

From htl10 at users.sourceforge.net  Thu Feb  8 16:05:17 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Thu, 8 Feb 2024 15:05:17 +0000 (UTC)
Subject: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
In-Reply-To: <130869330.10181893.1707317318935@mail.yahoo.com>
References: <47d8e424-1793-412f-a711-8def6afc7ec3@skef.org>
 <B02B15FD-D72A-46DD-BC77-50D5729E47E9@lorp.org>
 <a80c6236-f441-4715-9468-bc142ba6536b@skef.org>
 <SJ0PR00MB103926806416F78F8915D807BE792@SJ0PR00MB1039.namprd00.prod.outlook.com>
 <d11ab5a1-8adb-4e59-8a9e-7a1b6f91a223@skef.org>
 <CAF63+7Vw0kkAihgtuOBnGPJvOR3-eF202PsEPPnZWOVY=q_+Lg@mail.gmail.com>
 <DS1PEPF0000B07D5931E0B2A2FFCE86E7E4BE462@DS1PEPF0000B07D.namprd00.prod.outlook.com>
 <1240201732.9709744.1707269832780@mail.yahoo.com>
 <CAF63+7XqRuKsMLHe9KYzgOpjwu3dxfgR==u7SAuanwdRLWfN8A@mail.gmail.com>
 <130869330.10181893.1707317318935@mail.yahoo.com>
Message-ID: <306788230.11022176.1707404717975@mail.yahoo.com>

 Just an idea (and along some other ideas I have had for a while): although historically Apple has not been very forthcoming on some aspects of their technology, they HAD experience with hinting variable fonts. Since they have moved on from it and it is no longer crucial, maybe they are willing to dig up some of their two-decade old know-hows and share their experience / documentation / etc on GX. Those were hinted, with those un/under-documented instructions.

    On Wednesday, 7 February 2024 at 14:48:39 GMT, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:  
 
  The more relevant url is https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions#miscellaneous-instructions . But as I said, a fair chunk of it is under-documented.


    On Wednesday, 7 February 2024 at 01:42:12 GMT, Behdad Esfahbod <behdad at behdad.org> wrote:  
 
 On Tue, Feb 6, 2024, 6:37?PM Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:

 Apparently GETINFO bit 10 returns GX variation font support (this is undocumented AFAIK, and also what GETINFO does for the higher bits 10 onwards are undocumented), and there is an undocumented truetype instruction GETVARIATION for obtaining GX variation axes.

Search for GET in:https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview




Might be interesting to "overload" that bit 10 and that instruction with new meanings for opentype variable fonts.
    On Tuesday, 6 February 2024 at 20:36:58 GMT, Greg Hitchcock via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 
Behdad is correct that CVT values are calculated once per font at the parent transform.
 
 ?
 
The full component transform is not available to the bytecode.
 
 ?
 
The GETINFO instruction returns Bit 8 equal to 1 if the current glyph has been rotated, and bit 9 equal to 1 if the current glyph has been stretched.
 
 ?
 
GregH
 
 ?
 
From: Behdad Esfahbod <behdad at behdad.org> Tuesday, February 6, 2024 8:56 AM


 
 ?
 
Hi Skef,
 
 ?
 
* Indeed, CVT values are only calculated once per font, not per transformed components.
 
 ?
 
* Is the full component transformation available to the bytecode? If yes, we can spec that the VARC components are hinted post-transformation.
 
 ?
 
* What transformations are safe to hint can be left to the font. It can have a function to determine that. It can even be in the `prep` code which is run once, and set a CVT value to disable hinting fontwide if necessary.
 
 ?
 
b
 
 ?
 


 
behdad
http://behdad.org/
 
 ?
 
 ?
 
On Mon, Feb 5, 2024 at 5:04?PM Skef Iterum via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
 

Coming back to this subject --
 
We just did a couple explicit tests and it appears that the developing understanding is still conflating two distinct things: whether and how thecontext that the font is being rendered in is transformed, and whether and how a component of a composite glyph is transformed.
 
One might imagine a rasterizer that does something like the following:
    
   - Each component is given access to CVT-derived values that take into account the total transformation of the component (any "external" transformation plus any transformation at the composite level).
   - Whether grid-fitting is active depends on those component-specific CVT values. If there is rotation or skew the fitting might always be off. If there is just scaling maybe it is left on.
   - If the instructions are on, they apply to the points of the component post-tranformation.
 
What our experiments imply is:
    
   - The CVT values only vary by "external" transformation, not component transformation. Therefore if there is no "external" skew or rotation, instructions will generally be turned on for every component.
   - Grid-fitting of the component occurs pre-transformation. The points of the component are transformed to their final locations in a later step.
 
So if this is accurate the typical result of rendering a component with a skew and/or rotation in a context that does not have skew and/or rotation will be to grid-fit the "original" component using its hint data and then transforming the result. This will yield a glyph that is distorted (due to the grid-fitting) but not hinted according to the pixel grid it is rendered against.
 
So, one thing the VARC specification could, well, specify is that VARC components extracted from the glyf table are hinted more like the first list above than the second -- with further details presumably to be worked out. That way, with an appropriate header, grid fitting could be on or off depending on the total transformation of the component. Whether the existing instruction set is rich enough to handle non-uniform scaling when grid-fitting isn't cancelled by skew or rotation still seems like an open question, given that that's not how things seem to work in practice now. But such a change would be a start.
 
However, the VARC spec being added to the working draft says nothing about hinting, apparently leaving the question of how hinting is supposed to be managed in the face of component transformation -- the latter being a central part of VARC -- unresolved.
 
Skef
 
On 1/26/24 13:04, Greg Hitchcock wrote:
 

Through a combination of the GETINFO instruction and the INSTCTRL instruction, glyphs or fonts can make educated decisions about whether to apply instructions under different circumstances such as rotations, stretching, &c. Typically we recommend in the pre-program to disable hints under rotation, but if someone comes up with a clever algorithm for handling this, that is an option.
 
?
 
GregH
 
?
 
From: mpeg-otspec<mpeg-otspec-bounces at lists.aau.at>On Behalf Of Skef Iterum via mpeg-otspec
Sent: Friday, January 26, 2024 11:33 AM
To: Laurence Penney <lorp at lorp.org>
Cc: mpeg-otspec <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
 
?
 
|  | 
You don't often get email frommpeg-otspec at lists.aau.at.Learn why this is important
  |  |


?
 
On 1/24/24 23:47, Laurence Penney wrote:
 


On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec<mpeg-otspec at lists.aau.at> wrote:
 


There is a distinction between whether the text path itself is skewed or
rotated and whether a component in a composite is skewed or rotated.
Asking around it seems as though with the existing glyf components
instructions are not automatically turned off when "compositing", but
perhaps that info is wrong. 
 
Either way, though, that seems like something the specification should
clarify.
 

I asked similar questions when I was getting my head around TT hinting, and recall being told that skewed or rotated components were not hinted. The person I asked would most likely have been Greg Hitchcock.
 
?
 

Josh Hadley on our team got curious about this and did an experiment or two
in VTT. As far as we can tell there is no automatic disabling of hints when using
"not nice" transformations, at least in that tool. We can provide a specific
example or two if anyone needs them.

It's possible that the "client side" implementations work differently than the 
development tools but designers are likely to take the guidance of those tools
unless there is very strong conventional wisdom pointing in a different
direction.
 
Skef
 

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
 
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240208/ea4cf4ed/attachment-0001.htm>

From liam at fromoldbooks.org  Fri Feb  9 07:20:43 2024
From: liam at fromoldbooks.org (Liam R. E. Quin)
Date: Fri, 09 Feb 2024 01:20:43 -0500
Subject: [MPEG-OTSPEC] two new documents - Corrections, and DMAP
Message-ID: <bc8bf107e31a27de2fdc8b4466b4de486c71e116.camel@fromoldbooks.org>

Hello!

At
https://github.com/harfbuzz/boring-expansion-spec/tree/main/iso_docs

if you scroll down (or Find Within Page) to February, you can find

https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-varc-and-other-updates.pdf

https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-dmap-2024-01.pdf

The Updates document responds to all the public feedback we've seen so
far on the Beyond 64K proposals. It corrects a minor typo (thank you),
updates the source of numGlyphs in LTSH and hdmx, and adds some more
320bit offsets.

The DMAP proposal was originally from Peter Constable and others; this
document contains a slightly simplified version, but it probably does
need more work around Format 14 - especial thanks to Peter here.

Both of these documents are short.

Please feel free to file github issues on these documents, and/or to
comment here.

Maybe these documents can be discussed at the Feb. 20th meeting; the
Corrections one should not take significant time.

liam

-- 
Liam Quin,?https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
The barefoot typographer.

From skef at skef.org  Fri Feb  9 12:14:14 2024
From: skef at skef.org (Skef Iterum)
Date: Fri, 9 Feb 2024 03:14:14 -0800
Subject: [MPEG-OTSPEC] VARC CFF2 hint guidance proposal, and links to others
Message-ID: <cc4b5579-0306-4267-a44b-96a104cf3543@skef.org>

Hello -

The last proposal we are submitting prior to the April deadline provides 
guidance on hinting the CFF2-derived components of a composite VARC glyph:

https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf

This also adds a new optional "CFSH" table for storing PrivateDICT and 
FDSelect structures related to VARC. This new table isn't 100% necessary 
-- one could almost entirely duplicate its function in the CFF2 table 
itself -- but it allows separation of CFF2 component data and VARC 
composite data. Anyway, we can talk about it.

I've also added the earlier documents to our repository:

https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/newfeatvar_spec.pdf
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/negation.pdf
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/cff2hintorder.pdf

Only the last has been edited, and only to change "master" to "instance" 
as suggested.

Skef


From pconstable at microsoft.com  Fri Feb  9 21:03:12 2024
From: pconstable at microsoft.com (Peter Constable)
Date: Fri, 9 Feb 2024 20:03:12 +0000
Subject: [MPEG-OTSPEC] B64K: sbix 'dupe' tag
Message-ID: <PH7PR21MB3094B78659D649DF03C2201ADE4B2@PH7PR21MB3094.namprd21.prod.outlook.com>

Within the sbix glyph data, graphicType = 'dupe' indicates that the data that follows is a 16-bit glyph ID. (This type means that the bitmap data of the referenced glyph is used for the current glyph ID.) Since the docs currently assume that sbix data can be used for >64K glyphs, then I think a new tag 'dp24' (or 'dp32'?) should be defined.

In 5.5.7.3, the existing paragraph that begins "The special graphicType of 'dupe'..." could be replaced with the following:
The special graphicType value 'dupe' and 'dp24' indicate that the data field contains a two- or three-byte, big-endian glyph ID. With either type, the bitmap data for the indicated glyph shall be used for the current glyph. The type 'dp24' shall only be used in fonts that have a MAXP table and use 24-bit glyph IDs. If an application supports the 'sbix' table but does not support 24-bit glyph IDs, glyph data with graphicType = 'dp24' may be ignored.



Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240209/80d58abf/attachment.htm>

From ned at apple.com  Fri Feb  9 21:57:42 2024
From: ned at apple.com (Ned Holbrook)
Date: Fri, 09 Feb 2024 12:57:42 -0800
Subject: [MPEG-OTSPEC] B64K: sbix 'dupe' tag
In-Reply-To: <PH7PR21MB3094B78659D649DF03C2201ADE4B2@PH7PR21MB3094.namprd21.prod.outlook.com>
References: <PH7PR21MB3094B78659D649DF03C2201ADE4B2@PH7PR21MB3094.namprd21.prod.outlook.com>
Message-ID: <DC278EE1-A772-4F80-8892-5DCE9AACE49B@apple.com>

Or stick with the favored convention for SFNT tables and call it 'DUPE' ?

> On Feb 9, 2024, at 12:03?PM, Peter Constable via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> 
> Within the sbix glyph data, graphicType = ?dupe? indicates that the data that follows is a 16-bit glyph ID. (This type means that the bitmap data of the referenced glyph is used for the current glyph ID.) Since the docs currently assume that sbix data can be used for >64K glyphs, then I think a new tag ?dp24? (or ?dp32??) should be defined.
>  
> In 5.5.7.3, the existing paragraph that begins ?The special graphicType of ?dupe??? could be replaced with the following:
> The special graphicType value 'dupe' and 'dp24' indicate that the data field contains a two- or three-byte, big-endian glyph ID. With either type, the bitmap data for the indicated glyph shall be used for the current glyph. The type 'dp24' shall only be used in fonts that have a MAXP table and use 24-bit glyph IDs. If an application supports the ?sbix? table but does not support 24-bit glyph IDs, glyph data with graphicType = 'dp24' may be ignored.
>  
>  
>  
> Peter
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at <mailto:mpeg-otspec at lists.aau.at>
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240209/5b84156b/attachment-0001.htm>

From behdad at behdad.org  Sat Feb 10 15:26:45 2024
From: behdad at behdad.org (Behdad Esfahbod)
Date: Sat, 10 Feb 2024 07:26:45 -0700
Subject: [MPEG-OTSPEC] B64K: sbix 'dupe' tag
In-Reply-To: <DC278EE1-A772-4F80-8892-5DCE9AACE49B@apple.com>
References: <PH7PR21MB3094B78659D649DF03C2201ADE4B2@PH7PR21MB3094.namprd21.prod.outlook.com>
 <DC278EE1-A772-4F80-8892-5DCE9AACE49B@apple.com>
Message-ID: <CAF63+7VhSZmjE2FoD-=oud=OGbNYVfCpkqhiiP3VtNt+jM5_-A@mail.gmail.com>

`DUPE` sounds good to me.

It has also been brought to our attention that newer Apple systems support
a `flip` tag. Should `flip` and a respective `FLIP` also be added to the
proposal?

  https://github.com/fonttools/fonttools/pull/3433

behdad
http://behdad.org/


On Fri, Feb 9, 2024 at 1:58?PM Ned Holbrook via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> Or stick with the favored convention for SFNT tables and call it 'DUPE' ?
>
> On Feb 9, 2024, at 12:03?PM, Peter Constable via mpeg-otspec <
> mpeg-otspec at lists.aau.at> wrote:
>
> Within the sbix glyph data, graphicType = ?dupe? indicates that the data
> that follows is a 16-bit glyph ID. (This type means that the bitmap data of
> the referenced glyph is used for the current glyph ID.) Since the docs
> currently assume that sbix data can be used for >64K glyphs, then I think a
> new tag ?dp24? (or ?dp32??) should be defined.
>
> In 5.5.7.3, the existing paragraph that begins ?The special graphicType of
> ?dupe??? could be replaced with the following:
> The special graphicType value 'dupe' and 'dp24' indicate that the data
> field contains a two- or three-byte, big-endian glyph ID. With either type,
> the bitmap data for the indicated glyph shall be used for the current
> glyph. The type 'dp24' shall only be used in fonts that have a MAXP table
> and use 24-bit glyph IDs. If an application supports the ?sbix? table but
> does not support 24-bit glyph IDs, glyph data with graphicType = 'dp24' may
> be ignored.
>
>
>
> Peter
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240210/977b79f8/attachment.htm>

From skef at skef.org  Mon Feb 12 10:24:53 2024
From: skef at skef.org (Skef Iterum)
Date: Mon, 12 Feb 2024 01:24:53 -0800
Subject: [MPEG-OTSPEC] VARC hinting guidance document update
Message-ID: <19250db0-25b0-4589-976a-59a049ca157b@skef.org>

I updated the VARC hinting guidance proposal with some fixes and 
clarifications
concerning CFSH PrivateDICTs. The new draft is still at

https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf

Here is a diff of the Markdown:

diff --git a/varchintguide.md b/varchintguide.md
index 095588c..f5359dd 100644
--- a/varchintguide.md
+++ b/varchintguide.md
@@ -1,7 +1,7 @@
---
title: "VARC Hint Guidance for CFF2"

-date: February 9, 2024
+date: February 12, 2024
author: Skef Iterum
mainfont: LibertinusSerif-Regular.otf
geometry: margin=1.4in
@@ -44,6 +44,10 @@ uint16 ??initialPrivateDICT ????????The FontDICT 
index associated with of
Offset32 fdSelectOffset ????????????Offset (from start of CFSH table) to
 ????????????????????????????????????the FontDICTSelect subtable. Must not
 ????????????????????????????????????be 0.
+
+Offset32 itemVarStoreOffset ????????Offset (from start of CFSH table) to
+ ???????????????????????????????????the Item Variation Store table (may
+ ???????????????????????????????????be 0)
-------------------------------------------------------------------------

## Private DICT Index and initialPrivateDICT {-}
@@ -61,6 +65,13 @@ of the CFF2 FontDICT INDEX, so that the index of the 
first CFSH Private DICT is
one greater than the index of the last CFF2 Private DICT. The indexes of 
the
two sets of Private DICTs must not overlap.

+If the itemVarStoreOffset field is non-zero, then the `vsindex` and 
`blend`
+operators refer to the Item Variation Store it points to. If the field 
is zero
+then those operators refer to the Item Variation Store in the CFF2 table.
+
+PrivateDICTs in the CFSH table must not use the `Subrs` operator, and thus
+are always self-contained.
+
## The FontDICTSelect Offset {-}

The FontDICTSelect offset points to a CFF2 FontDICTSelect subtable
@@ -76,6 +87,10 @@ subtable in the 'CFF2' table but there must not be 
gap between the last glyph
mapped in 'CFF2' and the first glyph mapped in 'CFSH'. The `sentinel` 
field in
'CFSH' must be the highest GID defined in the font.

+## The itemVarStore Offset {-}
+
+When not zero this points to an Item Variation Store used for the 
`vsindex` and
+`blend` operators for the private dicts in the table.

# VARC and Hinting {-}

@@ -110,15 +125,20 @@ transformations and translations through all 
compositing layers.

### The Private DICT {-}

-Two subtables of two different tables define the association between a 
GID and
-a Private DICT. The first is the FontDICTSelect subtable of the 'CFSH' 
table,
-which, with one exception, is checked first. If the GID is not mapped 
there, the
-mapping falls back to the FontDICTSelect subtable of 'CFF2'.
-
-The exception case is if the two FontDICTSelect mappings overlap for a 
GID and
-both the CFF2 glyph and the VARC glyph with that GID have non-empty 
content.
-In that case the FontDICTSelect subtable from 'CFSH' is used for the 
VARC glyph
-while the FontDICTSelect subtable from CFF2 is used for the CFF2 glyph.
+Two subtables of two different tables define the association between 
the GID of
+a VARC composite and a Private DICT. The first is the FontDICTSelect 
subtable
+of the 'CFSH' table, which is checked first. If the GID is not mapped 
there,
+the mapping falls back to the FontDICTSelect subtable of 'CFF2'.
+
+Note that rendering a CFF2 component of a composite glyph will typically
+require data from both the component's Private DICT and the composite's 
Private
+DICT. The former is always stored in the CFF2 table and mapped by the CFF2
+FontDICTSelect subtable, and may contain `Subrs` and `vsindex` 
operators needed
+to desubroutinize and resolve any `blend`s. The composite PrivateDICT 
can be in
+either the CFF2 table or the CFSH table and defines the composite glyph's
+"Blue" parameters and standard stem sizes. (When a VARC composite loads 
data
+from the CFF2 component with the same GID, tne FontDICTSelect mapping 
in CFSH
+will typically need to overlap with that of the CFF2 table for that 
glyph.)

Fonts that conform to the specification will map all GIDs to at least one
Private DICT, but if a mapping is missing the client should use FontDICT 
index
@@ -217,7 +237,10 @@ that extensively modified the CFF2 text is not yet 
integrated.)
 ????maxp count.

2. ?When a font has a VARC table, the highest glyph mapped by the
- ???FontDICTSelect structure can be less than the maxp count as long as 
there
- ???is a `CFSH` table mapping any remaining glyphs. The ranges of 
mapped glyphs
- ???can overlap as described in (cross-reference `CFSH` section "The
- ???FontDICTSelect Offset")
+ ???FontDICTSelect structure can be less than the maxp count as long as 
two
+ ???requirements are met. The first requirement is that there is a 
`CFSH` table
+ ???that maps any remaining glyphs. The second requirement is that 
every glyph
+ ???in the CharStringINDEX must be mapped.
+
+ ???The ranges of mapped glyphs can overlap as described in 
(cross-reference
+ ???`CFSH` section "The FontDICTSelect Offset")

Skef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240212/a795d3c2/attachment.htm>

From htl10 at users.sourceforge.net  Mon Feb 12 23:07:27 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Mon, 12 Feb 2024 22:07:27 +0000 (UTC)
Subject: [MPEG-OTSPEC] questions on OT-SVG in Chrome, MS Edge and Firefox
In-Reply-To: <1162638087.7873418.1703443395311@mail.yahoo.com>
References: <mailman.1.1687860001.1927.mpeg-otspec@lists.aau.at>
 <SN6PR02MB5310EF203DFF33453B1D3D49C02AA@SN6PR02MB5310.namprd02.prod.outlook.com>
 <CAOgqPYdSayQZ4OFpRjGaB_uLMfUM6z+EXp4SHpFhbD6JLpgAKg@mail.gmail.com>
 <CAOgqPYfH9xhOJ2pi9+WOhdzBpkwhzLiL4xbMWY5RhUFdY9kjkA@mail.gmail.com>
 <70ab013a-fca5-1602-bc4a-12633a4d97d9@tiro.ca>
 <CACJZqjD8K-1iyZ3mid+bkQNmpRuQX7Bd4yk5tqGP_r9wecfabA@mail.gmail.com>
 <ece0b03a804549be95bb208430bdc3a0@OSAPR01MB4306.jpnprd01.prod.outlook.com>
 <06b4c922-9570-a5d5-56f3-01b909c67e40@hiroshima-u.ac.jp>
 <55581361.143875.1701761916764@mail.yahoo.com>
 <1162638087.7873418.1703443395311@mail.yahoo.com>
Message-ID: <1771533532.2386696.1707775647192@mail.yahoo.com>

 Hi,

I have continued to keep the blink/skia patches [1] up to date to current Chromium. And continue to test them [2] with QT WebEngine, which is a slimmed-down Chromium code variant up to about 3 months behind in latest Chromium development. Am trying to get the QT folks to take the patches [3].

Since some claimed that MS Edge supports OT-SVG back in 2017, and MS Edge has been available for Linux for a while, I gave it a try, and it is a NO. Guess OT-SVG support was broken when MS Edge moved to a Chromium-based backend in April 2021.

Anyway, here is a question for Peter and possibly also other Microsoft folks:

 - I have no idea how much current MS Edge on windows differs from Chrome on windows, but would you pass the URL for the patches to the relevant people and let them see what they see fit to adapt please? Thanks. Feedbacks and corrections/modifications can go to [1]'s issues, etc or directly/privately to me if needed.

And here is a question for Jonathan, and possibly other Firefox folks:

 - logically my chrome patches are in 3 parts, a one-liner switching OT-SVG support on in Skia, tell OTS to let such fonts pass-through as a usable font format, and get Blink to use freetype for non-OS-native font formats similar to sbix for windows etc. The 2nd part is somewhat common to Firefox - how does firefox deal with OT-SVG web-font sanitizing-wise? Does its copy of OTS (AFAIK) let them through and just hope the SVG processing is robust enough, or do some XML/etc validation on the way?

Would like to hear what Safari/Apple folks or webkitgtk folks (both of them supoprts OT-SVG, the latter I tested myself with webkitgtk-sharp) who like to comment on the sanitizing/security aspect of OT-SVG web fonts too. 

Hin-Tak


[1] https://github.com/HinTak/chromium-mod-CI
[2] https://github.com/HinTak/Qt6WE-OT-SVG
[3] https://bugreports.qt.io/browse/QTBUG-120543  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240212/ec7c573b/attachment-0001.htm>

From pconstable at microsoft.com  Tue Feb 13 01:44:31 2024
From: pconstable at microsoft.com (Peter Constable)
Date: Tue, 13 Feb 2024 00:44:31 +0000
Subject: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome,
 MS Edge and Firefox
In-Reply-To: <1771533532.2386696.1707775647192@mail.yahoo.com>
References: <mailman.1.1687860001.1927.mpeg-otspec@lists.aau.at>
 <SN6PR02MB5310EF203DFF33453B1D3D49C02AA@SN6PR02MB5310.namprd02.prod.outlook.com>
 <CAOgqPYdSayQZ4OFpRjGaB_uLMfUM6z+EXp4SHpFhbD6JLpgAKg@mail.gmail.com>
 <CAOgqPYfH9xhOJ2pi9+WOhdzBpkwhzLiL4xbMWY5RhUFdY9kjkA@mail.gmail.com>
 <70ab013a-fca5-1602-bc4a-12633a4d97d9@tiro.ca>
 <CACJZqjD8K-1iyZ3mid+bkQNmpRuQX7Bd4yk5tqGP_r9wecfabA@mail.gmail.com>
 <ece0b03a804549be95bb208430bdc3a0@OSAPR01MB4306.jpnprd01.prod.outlook.com>
 <06b4c922-9570-a5d5-56f3-01b909c67e40@hiroshima-u.ac.jp>
 <55581361.143875.1701761916764@mail.yahoo.com>
 <1162638087.7873418.1703443395311@mail.yahoo.com>
 <1771533532.2386696.1707775647192@mail.yahoo.com>
Message-ID: <PH7PR21MB3094D46CC3579E30AA5E98EFDE4F2@PH7PR21MB3094.namprd21.prod.outlook.com>

> Guess OT-SVG support was broken when MS Edge moved to a Chromium-based backend in April 2021.

That?s correct.


Peter

From: Hin-Tak Leung <htl10 at users.sourceforge.net>
Sent: Monday, February 12, 2024 3:07 PM
To: mpeg-otspec at lists.aau.at; Jonathan Kew <jfkthame at gmail.com>; Peter Constable <pconstable at microsoft.com>
Cc: suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp>
Subject: [EXTERNAL] questions on OT-SVG in Chrome, MS Edge and Firefox

Hi,

I have continued to keep the blink/skia patches [1] up to date to current Chromium. And continue to test them [2] with QT WebEngine, which is a slimmed-down Chromium code variant up to about 3 months behind in latest Chromium development. Am trying to get the QT folks to take the patches [3].

Since some claimed that MS Edge supports OT-SVG back in 2017, and MS Edge has been available for Linux for a while, I gave it a try, and it is a NO. Guess OT-SVG support was broken when MS Edge moved to a Chromium-based backend in April 2021.

Anyway, here is a question for Peter and possibly also other Microsoft folks:

- I have no idea how much current MS Edge on windows differs from Chrome on windows, but would you pass the URL for the patches to the relevant people and let them see what they see fit to adapt please? Thanks. Feedbacks and corrections/modifications can go to [1]'s issues, etc or directly/privately to me if needed.

And here is a question for Jonathan, and possibly other Firefox folks:

- logically my chrome patches are in 3 parts, a one-liner switching OT-SVG support on in Skia, tell OTS to let such fonts pass-through as a usable font format, and get Blink to use freetype for non-OS-native font formats similar to sbix for windows etc. The 2nd part is somewhat common to Firefox - how does firefox deal with OT-SVG web-font sanitizing-wise? Does its copy of OTS (AFAIK) let them through and just hope the SVG processing is robust enough, or do some XML/etc validation on the way?

Would like to hear what Safari/Apple folks or webkitgtk folks (both of them supoprts OT-SVG, the latter I tested myself with webkitgtk-sharp) who like to comment on the sanitizing/security aspect of OT-SVG web fonts too.

Hin-Tak


[1] https://github.com/HinTak/chromium-mod-CI
[2] https://github.com/HinTak/Qt6WE-OT-SVG
[3] https://bugreports.qt.io/browse/QTBUG-120543
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240213/ec81a4fe/attachment.htm>

From vladimir.levantovsky at gmail.com  Tue Feb 13 17:54:32 2024
From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky)
Date: Tue, 13 Feb 2024 11:54:32 -0500
Subject: [MPEG-OTSPEC] AHG meeting announcement
In-Reply-To: <CACJZqjDN+LLUaV_KnceSKoYDhrNHh9Y6f6m7QR7gt6Te2QA1ug@mail.gmail.com>
References: <CACJZqjDN+LLUaV_KnceSKoYDhrNHh9Y6f6m7QR7gt6Te2QA1ug@mail.gmail.com>
Message-ID: <CACJZqjCgPCdKMN-0QbSFS8NMRu2c+i8ahfBQ4cHNpDR9HfV1gQ@mail.gmail.com>

Dear all,

Please see below the updated agenda for the AHG meeting scheduled on Feb.
20 (Tuesday next week), which has been updated to include new links /
proposals. We have a packed agenda and limited time to review the documents
- please review the proposals and prepare your comments ahead of time:
1. Review updated Feature Variations proposal, see
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/newfeatvar_spec.pdf
and
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/negation.pdf
2. New proposals:
- relax CFF2 hint requirements in variable fonts, see
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/cff2hintorder.pdf
- VARC CFF2 hint guidance proposal, see
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf
3. Review new 'dmap' table proposal (see
https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-dmap-2024-01.pdf
)
4. Discuss remaining follow-up changes ('LTSH', 'hdmx', 'VARC" updates -
see
https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-varc-and-other-updates.pdf
)
5. New 'sbix' flags, see messages in this thread:
https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003280.html

Like I mentioned earlier, due to the AHG list archives being public, the
Zoom info will not be shared on the list. All prior AHG meeting
participants have been invited directly, and if you did not receive an
invite and want to be added to the list - please send me an email.

Thank you,
Vladimir



On Mon, Feb 5, 2024 at 8:40?PM Vladimir Levantovsky <
vladimir.levantovsky at gmail.com> wrote:

> Dear all,
>
> Like we discussed previously, we will have our next AHG Zoom meeting on
> Feb. 20, 2024 at 15:00 UTC to review additional changes proposed for
> inclusion into the current version of the Working Draft of the 5th edition
> ISO/IEC 14496-22. Please see below the meeting agenda, and please review
> the documents [shared on the AHG list] ahead of time to make the use of AHG
> meeting time most efficient and productive.
>
> If you're working on an updated proposal, please make sure to finalize it
> and make it available for AHG review at least a week prior to the meeting.
>
> Tentative agenda (may be updated if/when new proposals are presented):
> 1. Review updated Feature Variations proposal, see
> https://lists.aau.at/mailman/private/mpeg-otspec/2024-February/003262.html
> (the AHG email archive has recently been restored for private access, you
> may need to login using your list email/PW).
> 2. New proposal to relax CFF2 hint requirements in variable fonts, see
> https://lists.aau.at/mailman/private/mpeg-otspec/2024-February/003263.html
> 3. Tentative - review new 'dmap' table proposal (TBD)
> 4. Tentative - discuss remaining follow-up changes ('LTSH', 'hdmx', 'VARC"
> updates [if any], ...)
>
> Zoom meeting info: no changes since our last meeting. (Individual off-list
> meeting invites will include all necessary info.)
>
> All prior Zoom meeting participants will automatically get an invite, if
> you have not been a participant and would like to be added to the list,
> please respond directly to this email and I will add you to the invite list.
>
> Thank you,
> Vladimir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240213/c82e727f/attachment-0001.htm>

From vladimir.levantovsky at gmail.com  Mon Feb 19 22:16:31 2024
From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky)
Date: Mon, 19 Feb 2024 16:16:31 -0500
Subject: [MPEG-OTSPEC] AHG meeting announcement
In-Reply-To: <CACJZqjCgPCdKMN-0QbSFS8NMRu2c+i8ahfBQ4cHNpDR9HfV1gQ@mail.gmail.com>
References: <CACJZqjDN+LLUaV_KnceSKoYDhrNHh9Y6f6m7QR7gt6Te2QA1ug@mail.gmail.com>
 <CACJZqjCgPCdKMN-0QbSFS8NMRu2c+i8ahfBQ4cHNpDR9HfV1gQ@mail.gmail.com>
Message-ID: <CACJZqjCoUWp_mBhkf8F3QSYcP4R85KqgcbiXJGJgLfJLX0Zxdw@mail.gmail.com>

Dear AHG meeting participants,

This is just a friendly reminder to review the updated meeting agenda and
linked documents in preparation for our meeting tomorrow. We have a packed
agenda, and the time for discussing each proposal in details will be
limited - reviewing the documents and preparing your comments ahead of time
would help greatly to make meeting time more productive.

Thank you,
Vladimir


On Tue, Feb 13, 2024 at 11:54?AM Vladimir Levantovsky <
vladimir.levantovsky at gmail.com> wrote:

> Dear all,
>
> Please see below the updated agenda for the AHG meeting scheduled on Feb.
> 20 (Tuesday next week), which has been updated to include new links /
> proposals. We have a packed agenda and limited time to review the documents
> - please review the proposals and prepare your comments ahead of time:
> 1. Review updated Feature Variations proposal, see
> https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/newfeatvar_spec.pdf
> and
> https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/negation.pdf
> 2. New proposals:
> - relax CFF2 hint requirements in variable fonts, see
> https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/cff2hintorder.pdf
> - VARC CFF2 hint guidance proposal, see
> https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf
> 3. Review new 'dmap' table proposal (see
> https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-dmap-2024-01.pdf
> )
> 4. Discuss remaining follow-up changes ('LTSH', 'hdmx', 'VARC" updates -
> see
> https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-varc-and-other-updates.pdf
> )
> 5. New 'sbix' flags, see messages in this thread:
> https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003280.html
>
> Like I mentioned earlier, due to the AHG list archives being public, the
> Zoom info will not be shared on the list. All prior AHG meeting
> participants have been invited directly, and if you did not receive an
> invite and want to be added to the list - please send me an email.
>
> Thank you,
> Vladimir
>
>
>
> On Mon, Feb 5, 2024 at 8:40?PM Vladimir Levantovsky <
> vladimir.levantovsky at gmail.com> wrote:
>
>> Dear all,
>>
>> Like we discussed previously, we will have our next AHG Zoom meeting on
>> Feb. 20, 2024 at 15:00 UTC to review additional changes proposed for
>> inclusion into the current version of the Working Draft of the 5th edition
>> ISO/IEC 14496-22. Please see below the meeting agenda, and please review
>> the documents [shared on the AHG list] ahead of time to make the use of AHG
>> meeting time most efficient and productive.
>>
>> If you're working on an updated proposal, please make sure to finalize it
>> and make it available for AHG review at least a week prior to the meeting.
>>
>> Tentative agenda (may be updated if/when new proposals are presented):
>> 1. Review updated Feature Variations proposal, see
>> https://lists.aau.at/mailman/private/mpeg-otspec/2024-February/003262.html
>> (the AHG email archive has recently been restored for private access, you
>> may need to login using your list email/PW).
>> 2. New proposal to relax CFF2 hint requirements in variable fonts, see
>> https://lists.aau.at/mailman/private/mpeg-otspec/2024-February/003263.html
>> 3. Tentative - review new 'dmap' table proposal (TBD)
>> 4. Tentative - discuss remaining follow-up changes ('LTSH', 'hdmx',
>> 'VARC" updates [if any], ...)
>>
>> Zoom meeting info: no changes since our last meeting. (Individual
>> off-list meeting invites will include all necessary info.)
>>
>> All prior Zoom meeting participants will automatically get an invite, if
>> you have not been a participant and would like to be added to the list,
>> please respond directly to this email and I will add you to the invite list.
>>
>> Thank you,
>> Vladimir
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240219/41ecad51/attachment.htm>

From skef at skef.org  Tue Feb 20 18:21:29 2024
From: skef at skef.org (Skef Iterum)
Date: Tue, 20 Feb 2024 09:21:29 -0800
Subject: [MPEG-OTSPEC] Copy of previous document plus DMAP idea
Message-ID: <5a338263-77b1-42be-8b1e-aa011e524a60@skef.org>

The previous draft of the "New feature variations" document is attached. 
The sections on the specific implementation in this draft are now out of 
date -- refer to the newer draft for those specifics. However, this 
earlier draft also has the explanatory material referenced in the last 
meeting, particularly concerning the scaling problems with the current 
system and a specific example comparison of the two.

Now, on DMAP and the lack of specifics about other formats ...

Just as a starting point for discussion, suppose the convention was:

 1. Formats 4, 12, ? work as described in the current draft
 2. For all other formats, if there is a cmap subtable of that format
    but no DMAP, the cmap table is used and any implicit or explicit
    references to other formats refer only to the content in cmap, never
    to dmapl

    If there are cmap and DMAP subtables of that format, or just a DMAP
    subtable, the DMAP subtable is used and the cmap table (if any) is
    ignored. Any implicit or explicit references to other formats are to
    the DMAP table (if not format 4, 12, ?) or to the combination of the
    DMAP and cmap tables (if format 4, 12, ?).

This is a relatively simple convention and probably fine for any 
subtable format not likely to be large. So: would people be happy with 
this, or are there other formats likely to be large enough to optimize 
for, and how should sharing be defined for those?

Skef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240220/e2d6c913/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newfeatvar.pdf
Type: application/pdf
Size: 84661 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240220/e2d6c913/attachment-0001.pdf>

From vladimir.levantovsky at gmail.com  Tue Feb 20 18:50:54 2024
From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky)
Date: Tue, 20 Feb 2024 12:50:54 -0500
Subject: [MPEG-OTSPEC] AHG Zoom meeting (Feb. 20) - quick summary and next
 steps
Message-ID: <CACJZqjCRc8whfq_Wced+C350y+a+J7W5zZFJ2H5foPttaoquYQ@mail.gmail.com>

Dear all,

Thank you for your active participation at today's meeting. Please see
below the quick summary of the discussions added to each item of the
agenda, and suggested next steps.

1. Review updated
Feature Variations proposal (
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/newfeatvar_spec.pdf
)
- editorial: more work is needed to bring back some of the explanatory
language from the original proposal and examples;
- for the next round of discussion: clarify performance impact / benefits.
Condition negation (
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/negation.pdf
)
- tentatively accepted, needs clarification of condition set negations and
its relationship with the FeatureVariation.LookupCondition record, and
whether adding flags to conditions would be useful/necessary.
2. New proposals:
CFF2 hint requirements in variable fonts (
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/cff2hintorder.pdf
)
- would benefit from editorial work to add clarifications and normative
language where necessary.
VARC CFF2 hint guidance proposal (
https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf
)
- positive reaction overall, more editorial work is needed.
3. Review new 'dmap' table proposal (see
https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-dmap-2024-01.pdf
)
- more work is needed. We will continue the discussion (both offline /
email list and at the next meeting to determine possible outcomes and next
steps.
4. Follow-up changes ('LTSH', 'hdmx', 'VARC" updates (
https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-varc-and-other-updates.pdf
)
- hdmx / LTSH: questions of reasoning behind proposed "wide glyph ID"
updates and whether we should consider deprecating them instead;
- JSTF: proposed updates are accepted in principle with additional edits
needed  to update ExtenderGlyph2 table data types. (General questions about
the use of JSTF table have been raised - may need further investigation.)
- FVAR updates in support of HOI need separate discussion, before the
agreement on the proposed / alternate approach can be reached.
5. New 'sbix' flags (
https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003280.html)
- not much interest, do nothing at this time.

We will have our next Zoom meeting scheduled on March 19 at the same time
(15:00 UTC) where we will discuss updated proposals. The preliminary agenda
should be finalized by March 5 - please send your proposals of any new /
additional items to the AHG email list.

Thank you,
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240220/4459c65e/attachment.htm>

From vladimir.levantovsky at gmail.com  Tue Feb 20 21:39:20 2024
From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky)
Date: Tue, 20 Feb 2024 15:39:20 -0500
Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb.
 2020)
Message-ID: <CACJZqjD4+3XD8QcfrP-bJ2-jZxvMpoLmFHQ3EvkAqmvbH4-_bQ@mail.gmail.com>

The liaison statement I mentioned during today's call can be found here:
https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf

One of the aspects mentioned in the CSS WG statement is related to using
cursive elongation for text justification purposes, which may be desirable
for cursive writing and could be essential e.g. for many Arabic scripts - I
am wondering if this can already be accomplished using JSTF table, and
whether the existing specification needs to be updated to support it.

Thanks,
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240220/7ebcfee5/attachment.htm>

From john at tiro.ca  Wed Feb 21 17:13:08 2024
From: john at tiro.ca (John Hudson)
Date: Wed, 21 Feb 2024 08:13:08 -0800
Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from
 Feb. 2020)
In-Reply-To: <CACJZqjD4+3XD8QcfrP-bJ2-jZxvMpoLmFHQ3EvkAqmvbH4-_bQ@mail.gmail.com>
References: <CACJZqjD4+3XD8QcfrP-bJ2-jZxvMpoLmFHQ3EvkAqmvbH4-_bQ@mail.gmail.com>
Message-ID: <ee32cbe1-a731-4815-b60c-d0bbfad12092@tiro.ca>

Simon Cozens attempted an implementation of JSTF table support a few 
years ago, in an effort to find out whether it was actually 
implementable. As I recall, he determined that much of it could be 
implemented, but that there were some holes or things that could be 
improved. As far as I know, there is no JSTF table support in any 
shipping software, which I guess at least means we wouldn?t break 
anything were we to revise the spec to produce something workable for CSS.

JH


On 2024-02-20 12:39 pm, Vladimir Levantovsky via mpeg-otspec wrote:
> The liaison statement I mentioned during today's call can be found?here:
> https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf
>
> One of the aspects mentioned in the CSS WG statement is related to 
> using cursive elongation for text justification purposes, which may be 
> desirable for cursive?writing and could be essential e.g. for many 
> Arabic scripts - I am wondering if this can already be accomplished 
> using JSTF table, and whether the existing specification needs to be 
> updated to support it.
>
> Thanks,
> Vladimir
>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

-- 

John Hudson
Tiro Typeworks Ltd    www.tiro.com

Tiro Typeworks is physically located on islands
in the?Salish Sea, on the traditional territory
of the?Snuneymuxw?and Penelakut First Nations.

__________

EMAIL HOUR
In the interests of productivity, I am only dealing
with email towards the end of the day, typically
between 4PM and 5PM. If you need to contact me more
urgently, please use other means.


From johadley at adobe.com  Wed Feb 21 19:45:24 2024
From: johadley at adobe.com (Josh Hadley)
Date: Wed, 21 Feb 2024 18:45:24 +0000
Subject: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision
 Proposal
Message-ID: <BYAPR02MB53028277E4382712CBBCEC0AC0572@BYAPR02MB5302.namprd02.prod.outlook.com>

(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/20240221/11a29327/attachment.htm>

From pconstable at microsoft.com  Thu Feb 22 02:04:19 2024
From: pconstable at microsoft.com (Peter Constable)
Date: Thu, 22 Feb 2024 01:04:19 +0000
Subject: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision
 Proposal
In-Reply-To: <BYAPR02MB53028277E4382712CBBCEC0AC0572@BYAPR02MB5302.namprd02.prod.outlook.com>
References: <BYAPR02MB53028277E4382712CBBCEC0AC0572@BYAPR02MB5302.namprd02.prod.outlook.com>
Message-ID: <PH7PR21MB3094D07F14937D26E22EB572DE562@PH7PR21MB3094.namprd21.prod.outlook.com>

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/2370a523/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/2370a523/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/2370a523/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/2370a523/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/2370a523/attachment-0007.png>

From nmccully at adobe.com  Thu Feb 22 02:28:56 2024
From: nmccully at adobe.com (Nat McCully)
Date: Thu, 22 Feb 2024 01:28:56 +0000
Subject: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision
 Proposal
In-Reply-To: <PH7PR21MB3094D07F14937D26E22EB572DE562@PH7PR21MB3094.namprd21.prod.outlook.com>
References: <BYAPR02MB53028277E4382712CBBCEC0AC0572@BYAPR02MB5302.namprd02.prod.outlook.com>
 <PH7PR21MB3094D07F14937D26E22EB572DE562@PH7PR21MB3094.namprd21.prod.outlook.com>
Message-ID: <MW2PR02MB36598F002663AE8A58AEAC04D7562@MW2PR02MB3659.namprd02.prod.outlook.com>

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>

From pconstable at microsoft.com  Thu Feb 22 03:54:01 2024
From: pconstable at microsoft.com (Peter Constable)
Date: Thu, 22 Feb 2024 02:54:01 +0000
Subject: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision
 Proposal
In-Reply-To: <MW2PR02MB36598F002663AE8A58AEAC04D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
References: <BYAPR02MB53028277E4382712CBBCEC0AC0572@BYAPR02MB5302.namprd02.prod.outlook.com>
 <PH7PR21MB3094D07F14937D26E22EB572DE562@PH7PR21MB3094.namprd21.prod.outlook.com>
 <MW2PR02MB36598F002663AE8A58AEAC04D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
Message-ID: <PH7PR21MB309438772F5362E2E5E90F87DE562@PH7PR21MB3094.namprd21.prod.outlook.com>

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:



[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: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/20240222/fd52ea7b/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/fd52ea7b/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/fd52ea7b/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/20240222/fd52ea7b/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/20240222/fd52ea7b/attachment-0007.png>

From nmccully at adobe.com  Thu Feb 22 06:20:27 2024
From: nmccully at adobe.com (Nat McCully)
Date: Thu, 22 Feb 2024 05:20:27 +0000
Subject: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision
 Proposal
In-Reply-To: <PH7PR21MB309438772F5362E2E5E90F87DE562@PH7PR21MB3094.namprd21.prod.outlook.com>
References: <BYAPR02MB53028277E4382712CBBCEC0AC0572@BYAPR02MB5302.namprd02.prod.outlook.com>
 <PH7PR21MB3094D07F14937D26E22EB572DE562@PH7PR21MB3094.namprd21.prod.outlook.com>
 <MW2PR02MB36598F002663AE8A58AEAC04D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
 <PH7PR21MB309438772F5362E2E5E90F87DE562@PH7PR21MB3094.namprd21.prod.outlook.com>
Message-ID: <MW2PR02MB36591394A4ACD91934FDD3E6D7562@MW2PR02MB3659.namprd02.prod.outlook.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:



[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: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/20240222/1b940588/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/1b940588/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/1b940588/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/20240222/1b940588/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/20240222/1b940588/attachment-0007.png>

From nwillis at glyphography.com  Thu Feb 22 15:49:43 2024
From: nwillis at glyphography.com (nwillis at glyphography.com)
Date: Thu, 22 Feb 2024 14:49:43 +0000
Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from
 Feb. 2020)
In-Reply-To: <ee32cbe1-a731-4815-b60c-d0bbfad12092@tiro.ca>
References: <CACJZqjD4+3XD8QcfrP-bJ2-jZxvMpoLmFHQ3EvkAqmvbH4-_bQ@mail.gmail.com>
 <ee32cbe1-a731-4815-b60c-d0bbfad12092@tiro.ca>
Message-ID: <ac7250d497b06ec4aca2a5ecbc635508@glyphography.com>

The issue that always struck me about the JSTF table definition is that 
there is no accompanying justification engine against which you could 
measure whether or not it works, partly works, or does not work. So it's 
a bit "underanswerable." It would be like attempting to assess whether 
there is enough detail in the GSUB/GPOS spec alone that you could go 
implement HarfBuzz, Uniscribe, or any of the rest: to implement one you 
definitely have to know more about the behavior needed from a shaping 
engine than solely what's defined in GSUB/GPOS ... but, conversely, you 
have to know more about what the shaping engine is going to do in order 
to know whether or not the GSUB/GPOS spec is well-written.

An interesting question might be to ask whether a JSTF table could 
contain all of the info needed to work for some _known_ H&J engine ? a 
particular TeX flavor, hz-program, or so on.

I never really found a detailed account of how JSTF made it into the 
specification originally, such as describing whether it seemed to be 
written to match some particular private justification-engine's needs, 
or to match a hypothetical one that may have never appeared on the 
market.

(If that info is out there, I'd certainly appreciate seeing it.)

Nate

---


On 2024-02-21 16:13, John Hudson via mpeg-otspec wrote:
> Simon Cozens attempted an implementation of JSTF table support a few
> years ago, in an effort to find out whether it was actually
> implementable. As I recall, he determined that much of it could be
> implemented, but that there were some holes or things that could be
> improved. As far as I know, there is no JSTF table support in any
> shipping software, which I guess at least means we wouldn?t break
> anything were we to revise the spec to produce something workable for
> CSS.
> 
> JH
> 
> 
> On 2024-02-20 12:39 pm, Vladimir Levantovsky via mpeg-otspec wrote:
>> The liaison statement I mentioned during today's call can be 
>> found?here:
>> https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf
>> 
>> One of the aspects mentioned in the CSS WG statement is related to 
>> using cursive elongation for text justification purposes, which may be 
>> desirable for cursive?writing and could be essential e.g. for many 
>> Arabic scripts - I am wondering if this can already be accomplished 
>> using JSTF table, and whether the existing specification needs to be 
>> updated to support it.
>> 
>> Thanks,
>> Vladimir
>> 
>> 
>> _______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
> --
> 
> John Hudson
> Tiro Typeworks Ltd    www.tiro.com
> 
> Tiro Typeworks is physically located on islands
> in the?Salish Sea, on the traditional territory
> of the?Snuneymuxw?and Penelakut First Nations.
> 
> __________
> 
> EMAIL HOUR
> In the interests of productivity, I am only dealing
> with email towards the end of the day, typically
> between 4PM and 5PM. If you need to contact me more
> urgently, please use other means.
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

From simon at simon-cozens.org  Thu Feb 22 15:59:25 2024
From: simon at simon-cozens.org (Simon Cozens)
Date: Thu, 22 Feb 2024 14:59:25 +0000
Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from
 Feb. 2020)
In-Reply-To: <ac7250d497b06ec4aca2a5ecbc635508@glyphography.com>
References: <CACJZqjD4+3XD8QcfrP-bJ2-jZxvMpoLmFHQ3EvkAqmvbH4-_bQ@mail.gmail.com>
 <ee32cbe1-a731-4815-b60c-d0bbfad12092@tiro.ca>
 <ac7250d497b06ec4aca2a5ecbc635508@glyphography.com>
Message-ID: <87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org>

When Behdad, I and others did some thinking about the JSTF table last 
year (with a view to potentially making a 2.0 version which interacted 
better with variable fonts), we came to the realisation that everything 
you can do with the JSTF table, you can actually now do with a "JSTF" 
axis. So at this point it's entirely redundant.

In fact, I think Behdad implemented JSTF-axis-based justification in 
harfbuzz. (hb_shape_justify)

On 22/02/2024 14:49, nwillis--- via mpeg-otspec wrote:
> The issue that always struck me about the JSTF table definition is that 
> there is no accompanying justification engine against which you could 
> measure whether or not it works, partly works, or does not work. So it's 
> a bit "underanswerable." It would be like attempting to assess whether 
> there is enough detail in the GSUB/GPOS spec alone that you could go 
> implement HarfBuzz, Uniscribe, or any of the rest: to implement one you 
> definitely have to know more about the behavior needed from a shaping 
> engine than solely what's defined in GSUB/GPOS ... but, conversely, you 
> have to know more about what the shaping engine is going to do in order 
> to know whether or not the GSUB/GPOS spec is well-written.
> 
> An interesting question might be to ask whether a JSTF table could 
> contain all of the info needed to work for some _known_ H&J engine ? a 
> particular TeX flavor, hz-program, or so on.
> 
> I never really found a detailed account of how JSTF made it into the 
> specification originally, such as describing whether it seemed to be 
> written to match some particular private justification-engine's needs, 
> or to match a hypothetical one that may have never appeared on the market.
> 
> (If that info is out there, I'd certainly appreciate seeing it.)
> 
> Nate
> 
> ---
> 
> 
> On 2024-02-21 16:13, John Hudson via mpeg-otspec wrote:
>> Simon Cozens attempted an implementation of JSTF table support a few
>> years ago, in an effort to find out whether it was actually
>> implementable. As I recall, he determined that much of it could be
>> implemented, but that there were some holes or things that could be
>> improved. As far as I know, there is no JSTF table support in any
>> shipping software, which I guess at least means we wouldn?t break
>> anything were we to revise the spec to produce something workable for
>> CSS.
>>
>> JH
>>
>>
>> On 2024-02-20 12:39 pm, Vladimir Levantovsky via mpeg-otspec wrote:
>>> The liaison statement I mentioned during today's call can be found?here:
>>> https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf
>>>
>>> One of the aspects mentioned in the CSS WG statement is related to 
>>> using cursive elongation for text justification purposes, which may 
>>> be desirable for cursive?writing and could be essential e.g. for many 
>>> Arabic scripts - I am wondering if this can already be accomplished 
>>> using JSTF table, and whether the existing specification needs to be 
>>> updated to support it.
>>>

From bobby_devos at sil.org  Thu Feb 22 17:43:38 2024
From: bobby_devos at sil.org (Bobby de Vos)
Date: Thu, 22 Feb 2024 09:43:38 -0700
Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from
 Feb. 2020)
In-Reply-To: <ee32cbe1-a731-4815-b60c-d0bbfad12092@tiro.ca>
References: <CACJZqjD4+3XD8QcfrP-bJ2-jZxvMpoLmFHQ3EvkAqmvbH4-_bQ@mail.gmail.com>
 <ee32cbe1-a731-4815-b60c-d0bbfad12092@tiro.ca>
Message-ID: <52aef73d-5a6f-4e0d-aabf-a4c7f8c3a1eb@sil.org>

Greetings,

SIL added a JSTF table to some of our Arabic fonts (Lateef, Harmattan, 
Scheherazade), you can see what was added to Scheherazade below

https://github.com/silnrsi/font-scheherazade/commit/0aa388a0b3a59221f3c13e6b5803215f22bf6655

The commit message says "Add JSTF table to identify possible kashida 
glyphs". I thought this was added (notes from someone else) because when 
justification was turned on in Word, it would break the lam/alef 
ligature by inserting a kashida. But I am unable to actually test this 
at the moment.

Bobby

On 2024-02-21 09:13, John Hudson via mpeg-otspec wrote:
> Simon Cozens attempted an implementation of JSTF table support a few 
> years ago, in an effort to find out whether it was actually 
> implementable. As I recall, he determined that much of it could be 
> implemented, but that there were some holes or things that could be 
> improved. As far as I know, there is no JSTF table support in any 
> shipping software, which I guess at least means we wouldn?t break 
> anything were we to revise the spec to produce something workable for 
> CSS.
>
> JH
>
>
> On 2024-02-20 12:39 pm, Vladimir Levantovsky via mpeg-otspec wrote:
>> The liaison statement I mentioned during today's call can be found?here:
>> https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf 
>>
>>
>> One of the aspects mentioned in the CSS WG statement is related to 
>> using cursive elongation for text justification purposes, which may 
>> be desirable for cursive?writing and could be essential e.g. for many 
>> Arabic scripts - I am wondering if this can already be accomplished 
>> using JSTF table, and whether the existing specification needs to be 
>> updated to support it.
>>
>> Thanks,
>> Vladimir
>>
>>
>> _______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-- 
Bobby de Vos
/bobby_devos at sil.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240222/03361e59/attachment.htm>

From bobby_devos at sil.org  Thu Feb 22 17:45:23 2024
From: bobby_devos at sil.org (Bobby de Vos)
Date: Thu, 22 Feb 2024 09:45:23 -0700
Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from
 Feb. 2020)
In-Reply-To: <87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org>
References: <CACJZqjD4+3XD8QcfrP-bJ2-jZxvMpoLmFHQ3EvkAqmvbH4-_bQ@mail.gmail.com>
 <ee32cbe1-a731-4815-b60c-d0bbfad12092@tiro.ca>
 <ac7250d497b06ec4aca2a5ecbc635508@glyphography.com>
 <87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org>
Message-ID: <ec95cd0b-cab7-4b14-963d-b4a4851e0ce9@sil.org>

Simon,

When you say "JSTF axis" does that imply that one is building a variable 
font? Or can this technique be applied to static fonts as well?

Thanks, Bobby

On 2024-02-22 07:59, Simon Cozens via mpeg-otspec wrote:
> When Behdad, I and others did some thinking about the JSTF table last 
> year (with a view to potentially making a 2.0 version which interacted 
> better with variable fonts), we came to the realisation that 
> everything you can do with the JSTF table, you can actually now do 
> with a "JSTF" axis. So at this point it's entirely redundant.
>
> In fact, I think Behdad implemented JSTF-axis-based justification in 
> harfbuzz. (hb_shape_justify)
>
> On 22/02/2024 14:49, nwillis--- via mpeg-otspec wrote:
>> The issue that always struck me about the JSTF table definition is 
>> that there is no accompanying justification engine against which you 
>> could measure whether or not it works, partly works, or does not 
>> work. So it's a bit "underanswerable." It would be like attempting to 
>> assess whether there is enough detail in the GSUB/GPOS spec alone 
>> that you could go implement HarfBuzz, Uniscribe, or any of the rest: 
>> to implement one you definitely have to know more about the behavior 
>> needed from a shaping engine than solely what's defined in GSUB/GPOS 
>> ... but, conversely, you have to know more about what the shaping 
>> engine is going to do in order to know whether or not the GSUB/GPOS 
>> spec is well-written.
>>
>> An interesting question might be to ask whether a JSTF table could 
>> contain all of the info needed to work for some _known_ H&J engine ? 
>> a particular TeX flavor, hz-program, or so on.
>>
>> I never really found a detailed account of how JSTF made it into the 
>> specification originally, such as describing whether it seemed to be 
>> written to match some particular private justification-engine's 
>> needs, or to match a hypothetical one that may have never appeared on 
>> the market.
>>
>> (If that info is out there, I'd certainly appreciate seeing it.)
>>
>> Nate
>>
>> ---
>>
>>
>> On 2024-02-21 16:13, John Hudson via mpeg-otspec wrote:
>>> Simon Cozens attempted an implementation of JSTF table support a few
>>> years ago, in an effort to find out whether it was actually
>>> implementable. As I recall, he determined that much of it could be
>>> implemented, but that there were some holes or things that could be
>>> improved. As far as I know, there is no JSTF table support in any
>>> shipping software, which I guess at least means we wouldn?t break
>>> anything were we to revise the spec to produce something workable for
>>> CSS.
>>>
>>> JH
>>>
>>>
>>> On 2024-02-20 12:39 pm, Vladimir Levantovsky via mpeg-otspec wrote:
>>>> The liaison statement I mentioned during today's call can be 
>>>> found?here:
>>>> https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf 
>>>>
>>>>
>>>> One of the aspects mentioned in the CSS WG statement is related to 
>>>> using cursive elongation for text justification purposes, which may 
>>>> be desirable for cursive?writing and could be essential e.g. for 
>>>> many Arabic scripts - I am wondering if this can already be 
>>>> accomplished using JSTF table, and whether the existing 
>>>> specification needs to be updated to support it.
>>>>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
-- 
Bobby de Vos
/bobby_devos at sil.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240222/0ae88004/attachment-0001.htm>

From eisoch at 126.com  Mon Feb 26 01:38:19 2024
From: eisoch at 126.com (=?GBK?B?s8LTwLTP?=)
Date: Mon, 26 Feb 2024 08:38:19 +0800 (GMT+08:00)
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
Message-ID: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>

This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/ 


I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.


If you have any suggestions or feedbacks, please let me know.


Regards,
Eiso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240226/1ce14161/attachment.htm>

From wjgo_10009 at btinternet.com  Tue Feb 27 00:37:26 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Mon, 26 Feb 2024 23:37:26 +0000 (GMT)
Subject: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome,
 MS Edge and Firefox
In-Reply-To: <1771533532.2386696.1707775647192@mail.yahoo.com>
References: <1771533532.2386696.1707775647192@mail.yahoo.com>
Message-ID: <22da5f96.420e.18de7c7c779.Webtop.119@btinternet.com>


Hi
I refer to
https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003285.html 
<https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003285.html>
--
A discussion about the technique of using an SVG file exported from 
Affinity Designer (Affinity Designer not having colour font capability) 
to produce a colour display using Microsoft Edge has arisen.
https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178254 
<https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178254>
https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178261
Is the issue in this thread related to that or is about something 
different please?
Best regards,
William Overington
Monday 26 February 2024
?
?
?
------ Original Message ------
From: mpeg-otspec at lists.aau.at
To: htl10 at users.sourceforge.net; mpeg-otspec at lists.aau.at; 
jfkthame at gmail.com
Sent: Tuesday, February 13th 2024, 00:44
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome, MS 
Edge and Firefox
?
> Guess OT-SVG support was broken when MS Edge moved to a Chromium-based 
> backend in April 2021.
?
That?s correct.
?
?
Peter
?
From: Hin-Tak Leung <htl10 at users.sourceforge.net>?
Sent: Monday, February 12, 2024 3:07 PM
To: mpeg-otspec at lists.aau.at; Jonathan Kew <jfkthame at gmail.com>; Peter 
Constable <pconstable at microsoft.com>
Cc: suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp>
Subject: [EXTERNAL] questions on OT-SVG in Chrome, MS Edge and Firefox
?
Hi,
I have continued to keep the blink/skia patches [1] up to date to 
current Chromium. And continue to test them [2] with QT WebEngine, which 
is a slimmed-down Chromium code variant up to about 3 months behind in 
latest Chromium development. Am trying to get the QT folks to take the 
patches [3].
Since some claimed that MS Edge supports OT-SVG back in 2017, and MS 
Edge has been available for Linux for a while, I gave it a try, and it 
is a NO. Guess OT-SVG support was broken when MS Edge moved to a 
Chromium-based backend in April 2021.
Anyway, here is a question for Peter and possibly also other Microsoft 
folks:
- I have no idea how much current MS Edge on windows differs from Chrome 
on windows, but would you pass the URL for the patches to the relevant 
people and let them see what they see fit to adapt please? Thanks. 
Feedbacks and corrections/modifications can go to [1]'s issues, etc or 
directly/privately to me if needed.
And here is a question for Jonathan, and possibly other Firefox folks:
- logically my chrome patches are in 3 parts, a one-liner switching 
OT-SVG support on in Skia, tell OTS to let such fonts pass-through as a 
usable font format, and get Blink to use freetype for non-OS-native font 
formats similar to sbix for windows etc. The 2nd part is somewhat common 
to Firefox - how does firefox deal with OT-SVG web-font sanitizing-wise? 
Does its copy of OTS (AFAIK) let them through and just hope the SVG 
processing is robust enough, or do some XML/etc validation on the way?
Would like to hear what Safari/Apple folks or webkitgtk folks (both of 
them supoprts OT-SVG, the latter I tested myself with webkitgtk-sharp) 
who like to comment on the sanitizing/security aspect of OT-SVG web 
fonts too.?
Hin-Tak

[1] https://github.com/HinTak/chromium-mod-CI 
<https://github.com/HinTak/chromium-mod-CI>
[2] https://github.com/HinTak/Qt6WE-OT-SVG 
<https://github.com/HinTak/Qt6WE-OT-SVG>
[3] https://bugreports.qt.io/browse/QTBUG-120543 
<https://bugreports.qt.io/browse/QTBUG-120543>

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec 
<https://lists.aau.at/mailman/listinfo/mpeg-otspec>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240226/81f1f194/attachment.htm>

From pconstable at microsoft.com  Tue Feb 27 01:37:47 2024
From: pconstable at microsoft.com (Peter Constable)
Date: Tue, 27 Feb 2024 00:37:47 +0000
Subject: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome,
 MS Edge and Firefox
In-Reply-To: <22da5f96.420e.18de7c7c779.Webtop.119@btinternet.com>
References: <1771533532.2386696.1707775647192@mail.yahoo.com>
 <22da5f96.420e.18de7c7c779.Webtop.119@btinternet.com>
Message-ID: <PH7PR21MB3094C9835BB58D14ADB9BA4CDE5A2@PH7PR21MB3094.namprd21.prod.outlook.com>

OpenType and OFF support a few diffent colour font formats. Two use colour bitmaps:


  *   CBDT/CBLC: this was originally developed by Google to support emoji on Android devices. The format is also supported in at least Windows and in Edge and other Chromium-based browsers, but there are very few fonts and I think I can say the format is pretty much obsolete. (Even Google has since replaced CBDT in the Noto Color Emoji font?see below.)



  *   sbix: this was originally developed by Apple to support emoji. This is also supported in other platforms, some browsers and in some apps (e.g., Corel Graphics Suite). But last I checked it?s not supported in apps from Adobe or Affinity.

Then there are vector formats: two different font tables are used, but one has two versions that need to be distinguished:


  *   COLRv0: this was originally developed by Microsoft to support emoji. It was a relative simple extension to monochrome formats. On the one hand, that means it has limited graphic capabilities?layered shapes with solid colour fills plus alpha blending. But, on the other hand, this is the colour format that?s most widely supported?all platforms, all browsers, and many apps, including Corel Graphics Suite and Affinity Designer, but noticeably absent from Adobe apps.


  *   SVG: this was originally developed by Adobe at the same time as the above, and first supported in Firefox. Support was added in Windows, the Edge browser and in Adobe apps in 2017, and also in Safari in a similar timeframe. There have been many OT-SVG fonts created?probably the vast majority of existing colour fonts, mainly because of support in Adobe apps.

(Most OT-SVG fonts could actually have been implemented using COLRv0, and would have gotten broader app support that way, except that they wouldn?t work in Adobe apps.)

However, when Edge?s edgehtml layout engine was replaced with Chromium, support for OT-SVG in Edge went away. There?s no expectation that this will be coming back.



  *   COLRv1: This was developed by Google and Microsoft a few years ago to provide graphics capabilities similar to OT-SVG but in a binary format that better integrates with the rest of the font format. It has superseded CBDT in the Noto Color Emoji font, and the Segoe UI Emoji font in Windows 11 was recently updated using COLRv1 ? see Bringing new emoji to Windows 11 | Microsoft Design<https://microsoft.design/articles/bringing-new-emoji-to-windows-11?fbclid=IwAR36ro0ec6BHu_YSsDsbnueb2gUjc9k_oPzZBHzlJ5mnfZ62tosMbQg8hqc>. Being still relative new, however, it?s not yet widely supported in apps?Android, Windows and Chromium-based browses are probably it at this point.

At this point, I expect sbix will continue to be used for the indefinite future for colour bitmaps. For vector formats, it remains to be seen whether one or the other of SVG and COLRv1 will become the dominant format.

Peter

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of William_J_G Overington via mpeg-otspec <mpeg-otspec at lists.aau.at>
Date: Monday, February 26, 2024 at 4:37?PM
To: mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome, MS Edge and Firefox

Hi

I refer to

https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003285.html

--

A discussion about the technique of using an SVG file exported from Affinity Designer (Affinity Designer not having colour font capability) to produce a colour display using Microsoft Edge has arisen.

https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178254

https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178261

Is the issue in this thread related to that or is about something different please?

Best regards,

William Overington

Monday 26 February 2024






------ Original Message ------
From: mpeg-otspec at lists.aau.at
To: htl10 at users.sourceforge.net; mpeg-otspec at lists.aau.at; jfkthame at gmail.com
Sent: Tuesday, February 13th 2024, 00:44
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome, MS Edge and Firefox

> Guess OT-SVG support was broken when MS Edge moved to a Chromium-based backend in April 2021.


That?s correct.


Peter

From: Hin-Tak Leung <htl10 at users.sourceforge.net>
Sent: Monday, February 12, 2024 3:07 PM
To: mpeg-otspec at lists.aau.at; Jonathan Kew <jfkthame at gmail.com>; Peter Constable <pconstable at microsoft.com>
Cc: suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp>
Subject: [EXTERNAL] questions on OT-SVG in Chrome, MS Edge and Firefox

Hi,

I have continued to keep the blink/skia patches [1] up to date to current Chromium. And continue to test them [2] with QT WebEngine, which is a slimmed-down Chromium code variant up to about 3 months behind in latest Chromium development. Am trying to get the QT folks to take the patches [3].

Since some claimed that MS Edge supports OT-SVG back in 2017, and MS Edge has been available for Linux for a while, I gave it a try, and it is a NO. Guess OT-SVG support was broken when MS Edge moved to a Chromium-based backend in April 2021.

Anyway, here is a question for Peter and possibly also other Microsoft folks:

- I have no idea how much current MS Edge on windows differs from Chrome on windows, but would you pass the URL for the patches to the relevant people and let them see what they see fit to adapt please? Thanks. Feedbacks and corrections/modifications can go to [1]'s issues, etc or directly/privately to me if needed.

And here is a question for Jonathan, and possibly other Firefox folks:

- logically my chrome patches are in 3 parts, a one-liner switching OT-SVG support on in Skia, tell OTS to let such fonts pass-through as a usable font format, and get Blink to use freetype for non-OS-native font formats similar to sbix for windows etc. The 2nd part is somewhat common to Firefox - how does firefox deal with OT-SVG web-font sanitizing-wise? Does its copy of OTS (AFAIK) let them through and just hope the SVG processing is robust enough, or do some XML/etc validation on the way?

Would like to hear what Safari/Apple folks or webkitgtk folks (both of them supoprts OT-SVG, the latter I tested myself with webkitgtk-sharp) who like to comment on the sanitizing/security aspect of OT-SVG web fonts too.

Hin-Tak


[1] https://github.com/HinTak/chromium-mod-CI
[2] https://github.com/HinTak/Qt6WE-OT-SVG
[3] https://bugreports.qt.io/browse/QTBUG-120543
________________________________

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240227/b9a298cf/attachment-0001.htm>

From wjgo_10009 at btinternet.com  Tue Feb 27 09:35:26 2024
From: wjgo_10009 at btinternet.com (William_J_G Overington)
Date: Tue, 27 Feb 2024 08:35:26 +0000 (GMT)
Subject: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome,
 MS Edge and Firefox
In-Reply-To: <22da5f96.420e.18de7c7c779.Webtop.119@btinternet.com>
References: <22da5f96.420e.18de7c7c779.Webtop.119@btinternet.com>
Message-ID: <6a52f8e4.44cc.18de9b45685.Webtop.119@btinternet.com>


Good morning
Thank you, Peter.
https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178365
Best regards,
William
?
------ Original Message ------
From: pconstable at microsoft.com
To: wjgo_10009 at btinternet.com; mpeg-otspec at lists.aau.at
Sent: Tuesday, February 27th 2024, 00:37
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome, MS 
Edge and Firefox
?
OpenType and OFF support a few diffent colour font formats. Two use 
colour bitmaps:
?
    * CBDT/CBLC: this was originally developed by Google to support 
emoji on Android devices. The format is also supported in at least 
Windows and in Edge and other Chromium-based browsers, but there are 
very few fonts and I think I can say the format is pretty much obsolete. 
(Even Google has since replaced CBDT in the Noto Color Emoji font?see 
below.)
?
    * sbix: this was originally developed by Apple to support emoji. 
This is also supported in other platforms, some browsers and in some 
apps (e.g., Corel Graphics Suite). But last I checked it?s not supported 
in apps from Adobe or Affinity.
?
Then there are vector formats: two different font tables are used, but 
one has two versions that need to be distinguished:
?
    * COLRv0: this was originally developed by Microsoft to support 
emoji. It was a relative simple extension to monochrome formats. On the 
one hand, that means it has limited graphic capabilities?layered shapes 
with solid colour fills plus alpha blending. But, on the other hand, 
this is the colour format that?s most widely supported?all platforms, 
all browsers, and many apps, including Corel Graphics Suite and Affinity 
Designer, but noticeably absent from Adobe apps.
?
    * SVG: this was originally developed by Adobe at the same time as 
the above, and first supported in Firefox. Support was added in Windows, 
the Edge browser and in Adobe apps in 2017, and also in Safari in a 
similar timeframe. There have been many OT-SVG fonts created?probably 
the vast majority of existing colour fonts, mainly because of support in 
Adobe apps.
(Most OT-SVG fonts could actually have been implemented using COLRv0, 
and would have gotten broader app support that way, except that they 
wouldn?t work in Adobe apps.)
However, when Edge?s edgehtml layout engine was replaced with Chromium, 
support for OT-SVG in Edge went away. There?s no expectation that this 
will be coming back.
?
    * COLRv1: This was developed by Google and Microsoft a few years ago 
to provide graphics capabilities similar to OT-SVG but in a binary 
format that better integrates with the rest of the font format. It has 
superseded CBDT in the Noto Color Emoji font, and the Segoe UI Emoji 
font in Windows 11 was recently updated using COLRv1 ? see Bringing new 
emoji to Windows 11 | Microsoft Design 
<https://microsoft.design/articles/bringing-new-emoji-to-windows-11?fbclid=IwAR36ro0ec6BHu_YSsDsbnueb2gUjc9k_oPzZBHzlJ5mnfZ62tosMbQg8hqc> 
. Being still relative new, however, it?s not yet widely supported in 
apps?Android, Windows and Chromium-based browses are probably it at this 
point.
?
At this point, I expect sbix will continue to be used for the indefinite 
future for colour bitmaps. For vector formats, it remains to be seen 
whether one or the other of SVG and COLRv1 will become the dominant 
format.
?
?
Peter
?

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of 
William_J_G Overington via mpeg-otspec <mpeg-otspec at lists.aau.at>
Date: Monday, February 26, 2024 at 4:37?PM
To: mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome, MS 
Edge and Firefox
Hi
I refer to
https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003285.html 
<https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003285.html>
--
A discussion about the technique of using an SVG file exported from 
Affinity Designer (Affinity Designer not having colour font capability) 
to produce a colour display using Microsoft Edge has arisen.
https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178254 
<https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178254>
https://forum.affinity.serif.com/index.php?/topic/199300-color-font-is-not-being-displayed-in-affinity-designer-2-desktop/&do=findComment&comment=1178261
Is the issue in this thread related to that or is about something 
different please?
Best regards,
William Overington
Monday 26 February 2024
?
?
?
------ Original Message ------
From: mpeg-otspec at lists.aau.at
To: htl10 at users.sourceforge.net; mpeg-otspec at lists.aau.at; 
jfkthame at gmail.com
Sent: Tuesday, February 13th 2024, 00:44
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] questions on OT-SVG in Chrome, MS 
Edge and Firefox
?
> Guess OT-SVG support was broken when MS Edge moved to a Chromium-based 
> backend in April 2021.
?
That?s correct.
?
?
Peter
?
From: Hin-Tak Leung <htl10 at users.sourceforge.net>?
Sent: Monday, February 12, 2024 3:07 PM
To: mpeg-otspec at lists.aau.at; Jonathan Kew <jfkthame at gmail.com>; Peter 
Constable <pconstable at microsoft.com>
Cc: suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp>
Subject: [EXTERNAL] questions on OT-SVG in Chrome, MS Edge and Firefox
?
Hi,
I have continued to keep the blink/skia patches [1] up to date to 
current Chromium. And continue to test them [2] with QT WebEngine, which 
is a slimmed-down Chromium code variant up to about 3 months behind in 
latest Chromium development. Am trying to get the QT folks to take the 
patches [3].
Since some claimed that MS Edge supports OT-SVG back in 2017, and MS 
Edge has been available for Linux for a while, I gave it a try, and it 
is a NO. Guess OT-SVG support was broken when MS Edge moved to a 
Chromium-based backend in April 2021.
Anyway, here is a question for Peter and possibly also other Microsoft 
folks:
- I have no idea how much current MS Edge on windows differs from Chrome 
on windows, but would you pass the URL for the patches to the relevant 
people and let them see what they see fit to adapt please? Thanks. 
Feedbacks and corrections/modifications can go to [1]'s issues, etc or 
directly/privately to me if needed.
And here is a question for Jonathan, and possibly other Firefox folks:
- logically my chrome patches are in 3 parts, a one-liner switching 
OT-SVG support on in Skia, tell OTS to let such fonts pass-through as a 
usable font format, and get Blink to use freetype for non-OS-native font 
formats similar to sbix for windows etc. The 2nd part is somewhat common 
to Firefox - how does firefox deal with OT-SVG web-font sanitizing-wise? 
Does its copy of OTS (AFAIK) let them through and just hope the SVG 
processing is robust enough, or do some XML/etc validation on the way?
Would like to hear what Safari/Apple folks or webkitgtk folks (both of 
them supoprts OT-SVG, the latter I tested myself with webkitgtk-sharp) 
who like to comment on the sanitizing/security aspect of OT-SVG web 
fonts too.?
Hin-Tak

[1] https://github.com/HinTak/chromium-mod-CI 
<https://github.com/HinTak/chromium-mod-CI>
[2] https://github.com/HinTak/Qt6WE-OT-SVG 
<https://github.com/HinTak/Qt6WE-OT-SVG>
[3] https://bugreports.qt.io/browse/QTBUG-120543 
<https://bugreports.qt.io/browse/QTBUG-120543>

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec 
<https://lists.aau.at/mailman/listinfo/mpeg-otspec>
?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240227/25541826/attachment.htm>

From kida at mac.com  Wed Feb 28 02:35:21 2024
From: kida at mac.com (=?utf-8?B?5pyo55Sw5rOw5aSr?=)
Date: Wed, 28 Feb 2024 10:35:21 +0900
Subject: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision
 Proposal
In-Reply-To: <MW2PR02MB36591394A4ACD91934FDD3E6D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
References: <MW2PR02MB36591394A4ACD91934FDD3E6D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
Message-ID: <2EDD979C-DA78-4F54-85B2-DA68C70FBB87@mac.com>

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

From lunde at unicode.org  Wed Feb 28 06:06:46 2024
From: lunde at unicode.org (Ken Lunde)
Date: Tue, 27 Feb 2024 21:06:46 -0800
Subject: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision
 Proposal
In-Reply-To: <2EDD979C-DA78-4F54-85B2-DA68C70FBB87@mac.com>
References: <MW2PR02MB36591394A4ACD91934FDD3E6D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
 <2EDD979C-DA78-4F54-85B2-DA68C70FBB87@mac.com>
Message-ID: <BAD89C72-68D1-47A8-821D-6D2FF67FF71D@unicode.org>

All,

While I no longer have skin in this particular game, I would like to remind those who are discussing the interaction between these two specific features that there is also a comparable interaction between the 'vpal' and 'vkrn' features that affects vertical layout. This may also need consideration.

Regards...

-- Ken

> On Feb 27, 2024, at 17:35, ???? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> 
> 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). 
>> 
>> ?NatFrom: 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. Learn why this is important
>> 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. 
>>  ?NatFrom: 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)
>>  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:
>>  <image001.png>  PhotoShop appears to be exposing ?palt? in UI, but it?s set on with no way to toggle it off:
>>  <image002.png> 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):
>>  <image004.png> 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).
>>  <image005.png>   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
>>  
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec



From nmccully at adobe.com  Wed Feb 28 06:30:49 2024
From: nmccully at adobe.com (Nat McCully)
Date: Wed, 28 Feb 2024 05:30:49 +0000
Subject: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision
 Proposal
In-Reply-To: <BAD89C72-68D1-47A8-821D-6D2FF67FF71D@unicode.org>
References: <MW2PR02MB36591394A4ACD91934FDD3E6D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
 <2EDD979C-DA78-4F54-85B2-DA68C70FBB87@mac.com>
 <BAD89C72-68D1-47A8-821D-6D2FF67FF71D@unicode.org>
Message-ID: <MW2PR02MB3659A47637BE9F7BA694ACA2D7582@MW2PR02MB3659.namprd02.prod.outlook.com>

I added mention of 'vpal' and 'vkrn' to the proposal, so it can be assumed the new proposal also will address those features and propose vertical complements to them.


Nat McCully  |  Principal Scientist  |  Adobe  |  T 206 675 7351  |  C 206 409 0624  |  nmccully at adobe.com

________________________________
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of Ken Lunde via mpeg-otspec <mpeg-otspec at lists.aau.at>
Sent: Tuesday, February 27, 2024 21:06
To: mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] OpenType 'palt' and 'kern' Documentation Revision Proposal

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


All,

While I no longer have skin in this particular game, I would like to remind those who are discussing the interaction between these two specific features that there is also a comparable interaction between the 'vpal' and 'vkrn' features that affects vertical layout. This may also need consideration.

Regards...

-- Ken

> On Feb 27, 2024, at 17:35, ???? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>
> 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).
>>
>> ?NatFrom: 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. Learn why this is important
>> 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.
>>  ?NatFrom: 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)
>>  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:
>>  <image001.png>  PhotoShop appears to be exposing ?palt? in UI, but it?s set on with no way to toggle it off:
>>  <image002.png> 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):
>>  <image004.png> 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).
>>  <image005.png>   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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjcitpc%2FCJKFont%2Fblob%2Fmain%2Fdocs%2Fpalt_kern.md&data=05%7C02%7Cnmccully%40adobe.com%7C8f37674c8eb64f2049c408dc381b1e35%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638446936327531748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yrhjd6bkGnLKrk0lypokJTs%2B%2BOxb90sF1vXd8o7oxDA%3D&reserved=0<https://github.com/jcitpc/CJKFont/blob/main/docs/palt_kern.md> for addition to the next AHG meeting agenda.
>>   Thanks,
>>  Josh Hadley
>>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=05%7C02%7Cnmccully%40adobe.com%7C8f37674c8eb64f2049c408dc381b1e35%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638446936327539967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yAdRQYPpM1sJr383p1rZ3e8FKej6OGX%2BVDjt843m%2BPk%3D&reserved=0<https://lists.aau.at/mailman/listinfo/mpeg-otspec>


_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=05%7C02%7Cnmccully%40adobe.com%7C8f37674c8eb64f2049c408dc381b1e35%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638446936327545131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=F1QfYPnSyGu3aSnf3mkmJaNXBZEtUPHmrsdoH2eLPEI%3D&reserved=0<https://lists.aau.at/mailman/listinfo/mpeg-otspec>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240228/25792ba1/attachment-0001.htm>

From pconstable at microsoft.com  Thu Feb 29 02:46:23 2024
From: pconstable at microsoft.com (Peter Constable)
Date: Thu, 29 Feb 2024 01:46:23 +0000
Subject: [MPEG-OTSPEC] [EXTERNAL] Re: OpenType 'palt' and 'kern'
 Documentation Revision Proposal
In-Reply-To: <2EDD979C-DA78-4F54-85B2-DA68C70FBB87@mac.com>
References: <MW2PR02MB36591394A4ACD91934FDD3E6D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
 <2EDD979C-DA78-4F54-85B2-DA68C70FBB87@mac.com>
Message-ID: <PH7PR21MB309441D621504052C20A183ADE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>

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 want 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/ec183e70/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/ec183e70/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/ec183e70/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/ec183e70/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/ec183e70/attachment-0007.png>

From pconstable at microsoft.com  Thu Feb 29 02:50:51 2024
From: pconstable at microsoft.com (Peter Constable)
Date: Thu, 29 Feb 2024 01:50:51 +0000
Subject: [MPEG-OTSPEC] [EXTERNAL] Re: OpenType 'palt' and 'kern'
 Documentation Revision Proposal
In-Reply-To: <PH7PR21MB309441D621504052C20A183ADE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>
References: <MW2PR02MB36591394A4ACD91934FDD3E6D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
 <2EDD979C-DA78-4F54-85B2-DA68C70FBB87@mac.com>
 <PH7PR21MB309441D621504052C20A183ADE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>
Message-ID: <PH7PR21MB30940E4ECE399FF159FAA19DDE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>

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>

From nmccully at adobe.com  Thu Feb 29 04:17:00 2024
From: nmccully at adobe.com (Nat McCully)
Date: Thu, 29 Feb 2024 03:17:00 +0000
Subject: [MPEG-OTSPEC] [EXTERNAL] Re: OpenType 'palt' and 'kern'
 Documentation Revision Proposal
In-Reply-To: <PH7PR21MB30940E4ECE399FF159FAA19DDE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>
References: <MW2PR02MB36591394A4ACD91934FDD3E6D7562@MW2PR02MB3659.namprd02.prod.outlook.com>
 <2EDD979C-DA78-4F54-85B2-DA68C70FBB87@mac.com>
 <PH7PR21MB309441D621504052C20A183ADE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>
 <PH7PR21MB30940E4ECE399FF159FAA19DDE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>
Message-ID: <MW2PR02MB3659AA3E522D98CD9F20A2B0D75F2@MW2PR02MB3659.namprd02.prod.outlook.com>

One additional problem seems to be some apps or browsers have turned on 'kern' by default in Japanese fonts, but not 'palt'. If they do that, the fonts will not be kerned the correct amount. If a font foundry tries to correct this in the font kern amount, it will be kerned too much if combined with 'palt' (if they do not implement 'palt' I suppose they are ok, but you still have the problem that the font will be kerned only if all kern pairs are added (using 'palt' to get you most of the way greatly reduces the necessary kern pairs), and setting Japanese proportionally by default is not considered normal.

So, we wanted to make the spec more clear:

  1.  there is a need for separate default kerning behaviors in the font, Latin and J.
  2.
If you use 'kern' on J, you must also use 'palt'. To do otherwise is not practical and not compatible with fonts/engines that expect it.
  3.
When to use 'kern' by default depends on the text being "Latin" or "J", but different apps will compute this differently, and different fonts will assign "Latin" or "J" glyphs differently, given the same codepoints. Therefore the 'kern'/'palt' issue is not fully resolved (it is a hack).
  4.
A better solution for how and when to apply pair kerning to proportionally-set Japanese text is Peter's proposal.
  5.
Backward compatibility can be maintained as it is today, following the revised recommendations and deciding on the heuristic for when an ambiguous codepoint is a "Latin" glyph or "J" glyph.


Nat McCully  |  Principal Scientist  |  Adobe  |  T 206 675 7351  |  C 206 409 0624  |  nmccully at adobe.com

________________________________
From: Peter Constable <pconstable at microsoft.com>
Sent: Wednesday, February 28, 2024 17:50
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: [EXTERNAL] Re: OpenType 'palt' and 'kern' Documentation Revision Proposal


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


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/300fa1b7/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/300fa1b7/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/300fa1b7/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/300fa1b7/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/300fa1b7/attachment-0007.png>

From kida at mac.com  Thu Feb 29 05:24:36 2024
From: kida at mac.com (=?utf-8?B?5pyo55Sw5rOw5aSr?=)
Date: Thu, 29 Feb 2024 13:24:36 +0900
Subject: [MPEG-OTSPEC] [EXTERNAL] Re: OpenType 'palt' and 'kern'
 Documentation Revision Proposal
In-Reply-To: <PH7PR21MB30940E4ECE399FF159FAA19DDE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>
References: <PH7PR21MB30940E4ECE399FF159FAA19DDE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>
Message-ID: <D8BF74AA-689C-4657-A7B6-9473B2286F2D@mac.com>

An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240229/dcf14e76/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 64 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240229/dcf14e76/attachment-0001.png>

From tfuji at morisawa.co.jp  Thu Feb 29 09:53:39 2024
From: tfuji at morisawa.co.jp (=?utf-8?B?VGFrYWFraSBGdWppIOiXpCDosrTkuq4=?=)
Date: Thu, 29 Feb 2024 17:53:39 +0900
Subject: [MPEG-OTSPEC] [EXTERNAL] OpenType 'palt' and 'kern'
 Documentation Revision Proposal
In-Reply-To: <D8BF74AA-689C-4657-A7B6-9473B2286F2D@mac.com>
References: <PH7PR21MB30940E4ECE399FF159FAA19DDE5F2@PH7PR21MB3094.namprd21.prod.outlook.com>
 <D8BF74AA-689C-4657-A7B6-9473B2286F2D@mac.com>
Message-ID: <CAF87753-CF62-4106-9877-1AE20E79790B@morisawa.co.jp>

Hello Kida-san and all,

Thank you for mentioning me!

Migrating to 'apkn-based? fonts sounds surprisingly promising because we don?t even have to verify if re-using EAW as a kern exclusion list works well for CJK runs. And we would like to see more applications (e.g. web browsers) support the expected behavior that this proposal concerns in a more consistent way, so the ?apkn? idea would make the spec and the implementation way simpler. We might need to compile and share a sort of an EAW-like table among CJK font vendors to maximize compatibles between the ?older? fonts (which don?t have such knowledge in themselves) so that each developer could determine which glyphs should go to ?kern? or ?apkn? in a deterministic manner. That should be a future task when we take this path.

In fact, most of the newly released Japanese fonts in our own library extensively do this ? Kana glyphs are expected to be kerned only when ?palt? is applied to the run. For now we are just putting everything into the ?kern? like any other Adobe-Japan1 fonts, just hoping that smart text layout engines would handle this situation. I understand that?s exactly what Nat-san?s proposal is intended to clarify, and from a more practical standpoint, I really hope to see more clients become aware of such current ?kern? implementation, independently from the ?apkn? solution. 

I expect synthesizing the ?apkn? fonts from the existing ?older? fonts is rather easy, but I would like to emphasize that shipping them as a new version would be super confusing as we lose compatibilities between versions. Also it seems impossible to make a hybrid font that works on the both worlds, just as Kida-san described. Still, there should be no compatibility concerns in scenarios like we host a ?apkn? patched version as a web font. For the same reason, I also see CFF-based Japanese fonts are kind of hesitated to implement ?chws?, ?vchw' or ?vrtr? and ditch ?vrt2? as retail fonts, but instead they are sometimes offered as a tweak for the web font usage[1].

*1 https://fontplus.jp/usage/services/chws-vchw

?vrtr? mentions UTR#50 as a sort of a guidance for which glyphs should be rotated sideways. That sounds to me that it is not meant to be an only way of doing it. While I agree that 'EAW as a kern exclusion list' should work in theory, I?m not yet confident on this and the existing CJK-kern aware applications may not want to adopt the discussed EAW-based exclusion. But at least mentioning EAW as a reference will help readers to understand the idea of how to handle CJK kerning.

Regards,

Takaaki Fuji


> On Feb 29, 2024, at 13:24, ???? <kida at mac.com> wrote:
> 
> Hi Peter,
> 
>> 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?.
> 
> 
> +1. Given that ?palt? converts a fullwidth glyph to a proportional one, it seems logical to use EAW. I also think that Ambiguous characters should be included because fonts with ?palt? are inherently fullwidth. By restricting this to fonts with a ?palt? table, we ensure that kerning is automatically applied to Ambiguous code points in natively proportional fonts.
> 
> Currently, the specification itself is more inconsistent than ambiguous, which could lead to confusion across different font implementations. This inconsistency suggests that the new, more streamlined specification might not align perfectly with some existing fonts. However, there?s a positive aspect: CFF-based Japanese fonts tend to be quite uniform, largely because vendors have been aligning with Adobe?s guidelines. Moreover, as most major vendors are members of CITPC, if deemed necessary this organization could play a crucial role in identifying significant conflicts.
>> 
>> 
>> 
>> 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.
> 
> 
> Although I usually lean towards cleaner solutions, whether we go ahead with them really hinges on font developers' willingness to adopt. For many font vendors, changing their implementation could mean incurring significant costs. And if there's no guarantee that the updated implementation will deliver identical results, they might also have to update the font names, adding another layer of complexity for customers. It would definitely be smoother to adopt new designs for newly created fonts as you mentioned. Plus, it should be easier for platform vendors to make these adjustments.
> 
> Fuji-san, do you have comments?
> 
> - kida
> 
>> 2024/02/29 10:51?Peter Constable <pconstable at microsoft.com>????:
>> 
>> ?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
>> 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). 
>>  ?NatFrom: 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. Learn why this is important
>> 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. 
>>  ?NatFrom: 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)
>>  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:
>>  <image001.png>  PhotoShop appears to be exposing ?palt? in UI, but it?s set on with no way to toggle it off:
>>   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):
>>   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).
>>     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



From tfuji at morisawa.co.jp  Thu Feb 29 11:45:22 2024
From: tfuji at morisawa.co.jp (=?utf-8?B?VGFrYWFraSBGdWppIOiXpCDosrTkuq4=?=)
Date: Thu, 29 Feb 2024 19:45:22 +0900
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
In-Reply-To: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
References: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
Message-ID: <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>

Dear Eiso,

I'm just curious, but for ?hypy?, is there any good source I can look at for the ?official' glyph forms of Hanyu Pinyin?

If I understand the issue correctly, ?hypy? is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation?; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!

Thank you,

Takaaki Fuji

> On Feb 26, 2024, at 9:38, ??? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> 
> This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/ 
> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
> 
> If you have any suggestions or feedbacks, please let me know.
> 
> Regards,
> Eiso_______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec


From eisoch at 126.com  Thu Feb 29 14:28:28 2024
From: eisoch at 126.com (=?utf-8?B?6ZmI5rC46IGq?=)
Date: Thu, 29 Feb 2024 21:28:28 +0800 (GMT+08:00)
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
In-Reply-To: <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
References: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
 <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
Message-ID: <19e21dca.2c08.18df50d5482.Coremail.eisoch@126.com>

Fuji-San,


Thank you for your comments. The most official materials for Hanyu Pinyin forms are ?????? and ??????.


Eiso
---- Replied Message ----
| From | Takaaki Fuji ? ??<tfuji at morisawa.co.jp> |
| Date | 02/29/2024 ??6:45 |
| To | ??? <eisoch at 126.com> |
| Cc | mpeg-otspec <mpeg-otspec at lists.aau.at> |
| Subject | Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy' |
Dear Eiso,

I'm just curious, but for ?hypy?, is there any good source I can look at for the ?official' glyph forms of Hanyu Pinyin?

If I understand the issue correctly, ?hypy? is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation?; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!

Thank you,

Takaaki Fuji

> On Feb 26, 2024, at 9:38, ??? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>
> This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/
> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
>
> If you have any suggestions or feedbacks, please let me know.
>
> Regards,
> Eiso_______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240229/892051e2/attachment.htm>

From lunde at unicode.org  Thu Feb 29 14:56:04 2024
From: lunde at unicode.org (Ken Lunde)
Date: Thu, 29 Feb 2024 05:56:04 -0800
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
In-Reply-To: <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
References: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
 <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
Message-ID: <32A7E19A-C24F-41A1-B7E7-1878CAF74A45@unicode.org>

Fuji-san,

I once discussed this very issue with notable typography Robert Bringhurst, which was almost 25 years ago. He imparted onto me a very useful gem of wisdom, specifically that transliteration and transcription systems are meant to facilitate communication, not hinder it, and imposing specific typographic conventions on what are considered to be insignificant typographic distinctions is counter-productive. This applies to the perceived directionality of the acute accent, and to the specific forms of lowercase a and g.

My personal conclusion is that while conventional fonts need not adhere to the conventions that would be supported by the proposed 'hypy' feature, highly-specialized fonts, such as those used for preparing official educational materials that may include a mixture of foreign words and Chinese words expressed in P?ny?n, would benefit from it. In other words, I would not oppose the registration of this particular layout feature, but its description should mention its highly-specialized usage.

Eiso: About your reply to Fuji-san, it seems that even the official ?????? does not enforce these forms consistently. The 1958 version uses conventional a and g, but uses a directional acute accent mark:

http://www.moe.gov.cn/ewebeditor/uploadfile/2015/03/02/20150302165814246.pdf

The 2012 revision shows only the single-story lowercase g:

http://edu.shandong.gov.cn/attach/0/b72295c44ff442c8b333a481f524dbe9.pdf

I also found this version:

https://jwc.qzc.edu.cn/_upload/article/files/ff/32/cc69a400496186407e64fa4338cc/232fc89a-19af-4b9c-a829-a936d8a8919b.pdf

It would be helpful if you could explain the discrepancies, and if there is a more current and official version, it would be helpful to see the actual document.

Regards...

-- Ken

> On Feb 29, 2024, at 02:45, Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> 
> Dear Eiso,
> 
> I'm just curious, but for ?hypy?, is there any good source I can look at for the ?official' glyph forms of Hanyu Pinyin?
> 
> If I understand the issue correctly, ?hypy? is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation?; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!
> 
> Thank you,
> 
> Takaaki Fuji
> 
>> On Feb 26, 2024, at 9:38, ??? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>> 
>> This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/ 
>> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
>> 
>> If you have any suggestions or feedbacks, please let me know.
>> 
>> Regards,
>> Eiso_______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec


From mpsuzuki at hiroshima-u.ac.jp  Thu Feb 29 15:15:59 2024
From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya)
Date: Thu, 29 Feb 2024 23:15:59 +0900
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
In-Reply-To: <735ef4c6150d49f7a982a97a90985248@TYWPR01MB9542.jpnprd01.prod.outlook.com>
References: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
 <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
 <735ef4c6150d49f7a982a97a90985248@TYWPR01MB9542.jpnprd01.prod.outlook.com>
Message-ID: <87039d79-04ac-4ac9-86c4-91a27c4d24b7@hiroshima-u.ac.jp>

Dear Eiso, Fuji-san,

I checked ????????2012 available at

http://edu.shandong.gov.cn/attach/0/b72295c44ff442c8b333a481f524dbe9.pdf

I guess, the glyphs you want to care might be:

"a" in "ai" (?), "uan" (?), "Van" (?) in ???
"g" in "ang" (?), "eng" (????), "ieng" (?), "ueng" (?), "veng" (?) in ???

Am I understanding correctly?

??????1958 (I'm unsure the source of this scanned image):

http://www.moe.gov.cn/ewebeditor/uploadfile/2015/03/02/20150302165814246.pdf

there is no clear distinction of the typeface for "a" & "g".

A distinction of "a" is mentioned in the ??????, special "a" is used for ??,
maybe it would be the update introduced in 2012.

But yet I'm unsure about the background to distinguish "g".

Regards,
mpsuzuki

On 2024/02/29 22:28, ??? via mpeg-otspec wrote:
> Fuji-San,
> 
> Thank you for your comments. The most official materials for Hanyu Pinyin forms are ?????? and ??????.
> 
> Eiso
> ---- Replied Message ----
>  From    Takaaki Fuji ? ??<tfuji at morisawa.co.jp><mailto:tfuji at morisawa.co.jp>
> Date    02/29/2024 ??6:45
> To      ??? <eisoch at 126.com><mailto:eisoch at 126.com>
> Cc      mpeg-otspec <mpeg-otspec at lists.aau.at><mailto:mpeg-otspec at lists.aau.at>
> Subject Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
> Dear Eiso,
> 
> I'm just curious, but for ?hypy?, is there any good source I can look at for the ?official' glyph forms of Hanyu Pinyin?
> 
> If I understand the issue correctly, ?hypy? is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation?; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!
> 
> Thank you,
> 
> Takaaki Fuji
> 
>> On Feb 26, 2024, at 9:38, ??? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>>
>> This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/
>> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
>>
>> If you have any suggestions or feedbacks, please let me know.
>>
>> Regards,
>> Eiso_______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 

From tfuji at morisawa.co.jp  Thu Feb 29 17:40:52 2024
From: tfuji at morisawa.co.jp (=?utf-8?B?VGFrYWFraSBGdWppIOiXpCDosrTkuq4=?=)
Date: Fri,  1 Mar 2024 01:40:52 +0900
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
In-Reply-To: <32A7E19A-C24F-41A1-B7E7-1878CAF74A45@unicode.org>
References: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
 <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
 <32A7E19A-C24F-41A1-B7E7-1878CAF74A45@unicode.org>
Message-ID: <70C7CFDD-62D6-4612-94E4-4BCFA2E29785@morisawa.co.jp>

Dear Eiso, Ken, and Suzuki-san,

FYI, I found a writeup by Eric-san at https://www.thetype.com/2017/08/11606/ yesterday and it was a good introductory reading for me. Although I know I am not in the position to say something on this matter, I thought the fact that the ?hypy? proposal clearly discourages encoding Pinyin Forms as default would help most of the font developers (like us) not to get into the controversy in the first place ;)

Eiso, thank you for the info and I?ll get a copy of ?????? just for future reference!

> highly-specialized fonts, such as those used for preparing official educational materials that may include a mixture of foreign words and Chinese words expressed in P?ny?n, would benefit from it

Thank you for your insight as always Ken-san! I personally agree with your views, and I feel the recommendation that the proposal makes allows us to implement Pinyin Forms only for a selection of Chinese fonts, which are specialized for such educational purposes. That was the reason why I thought Eiso's proposal would be an improvement over the status quo. Apart from the spec, the substitutions could be implemented not only in the proposed ?hypy? but also in ?ssXX? as a compatibility stopgap, like we often do in Latin fonts for single-story a/g alternates.

BTW, another set of documents I had a look for curiosity were ISO 7098 and GB/T 16159 ? the former seemed typeset with Cambria, while the latter looked similar to ???????s convention, but they just might not be the sources as official as ?????? or ??????, which Eiso recommends.

Regards,

Takaaki Fuji

> On Feb 29, 2024, at 22:56, Ken Lunde <lunde at unicode.org> wrote:
> 
> Fuji-san,
> 
> I once discussed this very issue with notable typography Robert Bringhurst, which was almost 25 years ago. He imparted onto me a very useful gem of wisdom, specifically that transliteration and transcription systems are meant to facilitate communication, not hinder it, and imposing specific typographic conventions on what are considered to be insignificant typographic distinctions is counter-productive. This applies to the perceived directionality of the acute accent, and to the specific forms of lowercase a and g.
> 
> My personal conclusion is that while conventional fonts need not adhere to the conventions that would be supported by the proposed 'hypy' feature, highly-specialized fonts, such as those used for preparing official educational materials that may include a mixture of foreign words and Chinese words expressed in P?ny?n, would benefit from it. In other words, I would not oppose the registration of this particular layout feature, but its description should mention its highly-specialized usage.
> 
> Eiso: About your reply to Fuji-san, it seems that even the official ?????? does not enforce these forms consistently. The 1958 version uses conventional a and g, but uses a directional acute accent mark:
> 
> http://www.moe.gov.cn/ewebeditor/uploadfile/2015/03/02/20150302165814246.pdf
> 
> The 2012 revision shows only the single-story lowercase g:
> 
> http://edu.shandong.gov.cn/attach/0/b72295c44ff442c8b333a481f524dbe9.pdf
> 
> I also found this version:
> 
> https://jwc.qzc.edu.cn/_upload/article/files/ff/32/cc69a400496186407e64fa4338cc/232fc89a-19af-4b9c-a829-a936d8a8919b.pdf
> 
> It would be helpful if you could explain the discrepancies, and if there is a more current and official version, it would be helpful to see the actual document.
> 
> Regards...
> 
> -- Ken
> 
>> On Feb 29, 2024, at 02:45, Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>> 
>> Dear Eiso,
>> 
>> I'm just curious, but for ?hypy?, is there any good source I can look at for the ?official' glyph forms of Hanyu Pinyin?
>> 
>> If I understand the issue correctly, ?hypy? is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation?; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!
>> 
>> Thank you,
>> 
>> Takaaki Fuji
>> 
>>> On Feb 26, 2024, at 9:38, ??? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>>> 
>>> This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/ 
>>> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
>>> 
>>> If you have any suggestions or feedbacks, please let me know.
>>> 
>>> Regards,
>>> Eiso_______________________________________________
>>> mpeg-otspec mailing list
>>> mpeg-otspec at lists.aau.at
>>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>> 
>> _______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 


From behdad at behdad.org  Thu Feb 29 21:11:35 2024
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 29 Feb 2024 13:11:35 -0700
Subject: [MPEG-OTSPEC] Final touches to the `VARC` proposal
Message-ID: <CAF63+7UMmqN_VRsU3porztYuozFLDhOQRNGkt0Wp3_pynWQbag@mail.gmail.com>

Hi,

Please see (and discuss):

  https://github.com/harfbuzz/boring-expansion-spec/issues/137

Thanks,

behdad
http://behdad.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240229/d9e65c24/attachment.htm>

From Renzhi.Li at microsoft.com  Thu Feb 29 23:25:33 2024
From: Renzhi.Li at microsoft.com (Renzhi Li)
Date: Thu, 29 Feb 2024 22:25:33 +0000
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
In-Reply-To: <70C7CFDD-62D6-4612-94E4-4BCFA2E29785@morisawa.co.jp>
References: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
 <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
 <32A7E19A-C24F-41A1-B7E7-1878CAF74A45@unicode.org>
 <70C7CFDD-62D6-4612-94E4-4BCFA2E29785@morisawa.co.jp>
Message-ID: <CH0PR00MB1427F244B12478262867627DE85F2@CH0PR00MB1427.namprd00.prod.outlook.com>

Shouldn't we just use ruby?? ruby? under latn? script and ZHS? language, indicating "Ruby for Chinese written in Latin Script".
________________________________
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at>
Sent: Thursday, February 29, 2024 08:40
To: ??? <eisoch at 126.com>; Ken Lunde <lunde at unicode.org>; suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp>
Cc: mpeg-otspec <mpeg-otspec at lists.aau.at>
Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'

[You don't often get email from mpeg-otspec at lists.aau.at. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Dear Eiso, Ken, and Suzuki-san,

FYI, I found a writeup by Eric-san at https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thetype.com%2F2017%2F08%2F11606%2F&data=05%7C02%7Crenzhi.li%40microsoft.com%7C2d47eda370b94c7a907c08dc39453ba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638448217941389266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FL7qd5lH8gFctwfhKDLCJNvkVJdu4PJMFK%2Bhh8nK48Y%3D&reserved=0<https://www.thetype.com/2017/08/11606/> yesterday and it was a good introductory reading for me. Although I know I am not in the position to say something on this matter, I thought the fact that the ?hypy? proposal clearly discourages encoding Pinyin Forms as default would help most of the font developers (like us) not to get into the controversy in the first place ;)

Eiso, thank you for the info and I?ll get a copy of ?????? just for future reference!

> highly-specialized fonts, such as those used for preparing official educational materials that may include a mixture of foreign words and Chinese words expressed in P?ny?n, would benefit from it

Thank you for your insight as always Ken-san! I personally agree with your views, and I feel the recommendation that the proposal makes allows us to implement Pinyin Forms only for a selection of Chinese fonts, which are specialized for such educational purposes. That was the reason why I thought Eiso's proposal would be an improvement over the status quo. Apart from the spec, the substitutions could be implemented not only in the proposed ?hypy? but also in ?ssXX? as a compatibility stopgap, like we often do in Latin fonts for single-story a/g alternates.

BTW, another set of documents I had a look for curiosity were ISO 7098 and GB/T 16159 ? the former seemed typeset with Cambria, while the latter looked similar to ???????s convention, but they just might not be the sources as official as ?????? or ??????, which Eiso recommends.

Regards,

Takaaki Fuji

> On Feb 29, 2024, at 22:56, Ken Lunde <lunde at unicode.org> wrote:
>
> Fuji-san,
>
> I once discussed this very issue with notable typography Robert Bringhurst, which was almost 25 years ago. He imparted onto me a very useful gem of wisdom, specifically that transliteration and transcription systems are meant to facilitate communication, not hinder it, and imposing specific typographic conventions on what are considered to be insignificant typographic distinctions is counter-productive. This applies to the perceived directionality of the acute accent, and to the specific forms of lowercase a and g.
>
> My personal conclusion is that while conventional fonts need not adhere to the conventions that would be supported by the proposed 'hypy' feature, highly-specialized fonts, such as those used for preparing official educational materials that may include a mixture of foreign words and Chinese words expressed in P?ny?n, would benefit from it. In other words, I would not oppose the registration of this particular layout feature, but its description should mention its highly-specialized usage.
>
> Eiso: About your reply to Fuji-san, it seems that even the official ?????? does not enforce these forms consistently. The 1958 version uses conventional a and g, but uses a directional acute accent mark:
>
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.moe.gov.cn%2Fewebeditor%2Fuploadfile%2F2015%2F03%2F02%2F20150302165814246.pdf&data=05%7C02%7Crenzhi.li%40microsoft.com%7C2d47eda370b94c7a907c08dc39453ba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638448217941398105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ipEbMQdomySsgdO7LRknAsBbYJ%2BR7aGFtuIEawE%2FHXM%3D&reserved=0<http://www.moe.gov.cn/ewebeditor/uploadfile/2015/03/02/20150302165814246.pdf>
>
> The 2012 revision shows only the single-story lowercase g:
>
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fedu.shandong.gov.cn%2Fattach%2F0%2Fb72295c44ff442c8b333a481f524dbe9.pdf&data=05%7C02%7Crenzhi.li%40microsoft.com%7C2d47eda370b94c7a907c08dc39453ba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638448217941405027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mKKQPzlkoFb77wSRSZzb%2BoxusXEplR66ymxUdszAFz0%3D&reserved=0<http://edu.shandong.gov.cn/attach/0/b72295c44ff442c8b333a481f524dbe9.pdf>
>
> I also found this version:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjwc.qzc.edu.cn%2F_upload%2Farticle%2Ffiles%2Fff%2F32%2Fcc69a400496186407e64fa4338cc%2F232fc89a-19af-4b9c-a829-a936d8a8919b.pdf&data=05%7C02%7Crenzhi.li%40microsoft.com%7C2d47eda370b94c7a907c08dc39453ba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638448217941410417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=e63PhAxLVoae6XI8R7RJEFRyih7hEscjDZmzfHi3oSc%3D&reserved=0<https://jwc.qzc.edu.cn/_upload/article/files/ff/32/cc69a400496186407e64fa4338cc/232fc89a-19af-4b9c-a829-a936d8a8919b.pdf>
>
> It would be helpful if you could explain the discrepancies, and if there is a more current and official version, it would be helpful to see the actual document.
>
> Regards...
>
> -- Ken
>
>> On Feb 29, 2024, at 02:45, Takaaki Fuji ? ?? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>>
>> Dear Eiso,
>>
>> I'm just curious, but for ?hypy?, is there any good source I can look at for the ?official' glyph forms of Hanyu Pinyin?
>>
>> If I understand the issue correctly, ?hypy? is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation?; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!
>>
>> Thank you,
>>
>> Takaaki Fuji
>>
>>> On Feb 26, 2024, at 9:38, ??? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>>>
>>> This is my first proposal for OFF. Please see https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcloud.caaph.com%3A10121%2Ff%2Ffed7bd2e3d%2F&data=05%7C02%7Crenzhi.li%40microsoft.com%7C2d47eda370b94c7a907c08dc39453ba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638448217941417027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FRTur53IcaLuNCUoGieWTBrgGH6QhChidC4DSxQsLqA%3D&reserved=0<http://cloud.caaph.com:10121/f/fed7bd2e3d/>
>>> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
>>>
>>> If you have any suggestions or feedbacks, please let me know.
>>>
>>> Regards,
>>> Eiso_______________________________________________
>>> mpeg-otspec mailing list
>>> mpeg-otspec at lists.aau.at
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=05%7C02%7Crenzhi.li%40microsoft.com%7C2d47eda370b94c7a907c08dc39453ba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638448217941422251%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=P1AMSq2Gsi%2FKQrEjhkFd9C0A58UCjAHx1GAI%2FAiLhuk%3D&reserved=0<https://lists.aau.at/mailman/listinfo/mpeg-otspec>
>>
>> _______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=05%7C02%7Crenzhi.li%40microsoft.com%7C2d47eda370b94c7a907c08dc39453ba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638448217941427945%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Suvll7skstOQ%2BmlHQJ3N3zRNazZWRWtHydEFn18nAzg%3D&reserved=0<https://lists.aau.at/mailman/listinfo/mpeg-otspec>
>

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=05%7C02%7Crenzhi.li%40microsoft.com%7C2d47eda370b94c7a907c08dc39453ba1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638448217941433679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CsR02VAkHNm64m8yfUmT3Pddq0PbJ%2F5GudG59l0346A%3D&reserved=0<https://lists.aau.at/mailman/listinfo/mpeg-otspec>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240229/a7535843/attachment-0001.htm>

From htl10 at users.sourceforge.net  Thu Feb 29 23:41:12 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Thu, 29 Feb 2024 22:41:12 +0000 (UTC)
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
In-Reply-To: <87039d79-04ac-4ac9-86c4-91a27c4d24b7@hiroshima-u.ac.jp>
References: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
 <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
 <735ef4c6150d49f7a982a97a90985248@TYWPR01MB9542.jpnprd01.prod.outlook.com>
 <87039d79-04ac-4ac9-86c4-91a27c4d24b7@hiroshima-u.ac.jp>
Message-ID: <1977511956.4155878.1709246472593@mail.yahoo.com>

 For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might behttps://www.chinesestandard.net/AMP/English.amp.aspx/GBZ40637-2021

https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=52E2DE28D439C1937EE09AE4B5AA615B

For the English and Chinese version of it respectively (behind pay walls), and a somewhat reliable Chinese version available for download at:
https://archive.org/details/GB-Z40637-2021/page/n5/mode/1up

I am mostly with Ken Lunde on this: transliteration itself is a work-around (trying to approximate one language's sound with another), and diacritics on transliteration is a refinement of a workaround... for actual scholarly work, the traditional way of indicating the pronunciation of a rare word in Chinese is to say "XY ?" where you indicates the starting consonant and the ending vowel with two common native words.e.g. my surname "?"'s Cantonese pronunciation might be written down as "???", where you take the consonant of the first (?"leen") and join with the ending vowel of another ("?""yeung") to form "leung". Most people can't quite pronounce English "leung" correctly anyway, so the traditional way of annotating it as e.g.?"???" would be preferable... it is somewhat a lost cause to try to standardise on hyphenation and diacritics of transliterations...
    On Thursday, 29 February 2024 at 14:16:26 GMT, suzuki toshiya via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 Dear Eiso, Fuji-san,

I checked ????????2012 available at

http://edu.shandong.gov.cn/attach/0/b72295c44ff442c8b333a481f524dbe9.pdf

I guess, the glyphs you want to care might be:

"a" in "ai" (?), "uan" (?), "Van" (?) in ???
"g" in "ang" (?), "eng" (????), "ieng" (?), "ueng" (?), "veng" (?) in ???

Am I understanding correctly?

??????1958 (I'm unsure the source of this scanned image):

http://www.moe.gov.cn/ewebeditor/uploadfile/2015/03/02/20150302165814246.pdf

there is no clear distinction of the typeface for "a" & "g".

A distinction of "a" is mentioned in the ??????, special "a" is used for ??,
maybe it would be the update introduced in 2012.

But yet I'm unsure about the background to distinguish "g".

Regards,
mpsuzuki

On 2024/02/29 22:28, ??? via mpeg-otspec wrote:
> Fuji-San,
> 
> Thank you for your comments. The most official materials for Hanyu Pinyin forms are ?????? and ??????.
> 
> Eiso
> ---- Replied Message ----
>? From? ? Takaaki Fuji ? ??<tfuji at morisawa.co.jp><mailto:tfuji at morisawa.co.jp>
> Date? ? 02/29/2024 ??6:45
> To? ? ? ??? <eisoch at 126.com><mailto:eisoch at 126.com>
> Cc? ? ? mpeg-otspec <mpeg-otspec at lists.aau.at><mailto:mpeg-otspec at lists.aau.at>
> Subject Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
> Dear Eiso,
> 
> I'm just curious, but for ?hypy?, is there any good source I can look at for the ?official' glyph forms of Hanyu Pinyin?
> 
> If I understand the issue correctly, ?hypy? is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation?; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!
> 
> Thank you,
> 
> Takaaki Fuji
> 
>> On Feb 26, 2024, at 9:38, ??? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>>
>> This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/
>> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
>>
>> If you have any suggestions or feedbacks, please let me know.
>>
>> Regards,
>> Eiso_______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240229/d8ca46a3/attachment.htm>

From htl10 at users.sourceforge.net  Thu Feb 29 23:54:36 2024
From: htl10 at users.sourceforge.net (Hin-Tak Leung)
Date: Thu, 29 Feb 2024 22:54:36 +0000 (UTC)
Subject: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
In-Reply-To: <1977511956.4155878.1709246472593@mail.yahoo.com>
References: <7201cbf8.3da4.18de2d92a48.Coremail.eisoch@126.com>
 <4CDCF2A3-542D-44FD-A947-E8CBF05FD353@morisawa.co.jp>
 <735ef4c6150d49f7a982a97a90985248@TYWPR01MB9542.jpnprd01.prod.outlook.com>
 <87039d79-04ac-4ac9-86c4-91a27c4d24b7@hiroshima-u.ac.jp>
 <1977511956.4155878.1709246472593@mail.yahoo.com>
Message-ID: <1049591952.4160733.1709247276951@mail.yahoo.com>

 That's especially true in mainland China where the teaching of spoken English is generally poor (and even deprecated) and subjected to local /personal variations. Not sure what is the intended audience of this kind of standardisation - is it for non-Chinese learning Chinese as a non-native language?
There is also rumours that English is to be banned / deprecated / not taught in junior schools.
    On Thursday, 29 February 2024 at 22:44:16 GMT, Hin-Tak Leung via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
  For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might behttps://www.chinesestandard.net/AMP/English.amp.aspx/GBZ40637-2021

https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=52E2DE28D439C1937EE09AE4B5AA615B

For the English and Chinese version of it respectively (behind pay walls), and a somewhat reliable Chinese version available for download at:
https://archive.org/details/GB-Z40637-2021/page/n5/mode/1up

I am mostly with Ken Lunde on this: transliteration itself is a work-around (trying to approximate one language's sound with another), and diacritics on transliteration is a refinement of a workaround... for actual scholarly work, the traditional way of indicating the pronunciation of a rare word in Chinese is to say "XY ?" where you indicates the starting consonant and the ending vowel with two common native words.e.g. my surname "?"'s Cantonese pronunciation might be written down as "???", where you take the consonant of the first (?"leen") and join with the ending vowel of another ("?""yeung") to form "leung". Most people can't quite pronounce English "leung" correctly anyway, so the traditional way of annotating it as e.g.?"???" would be preferable... it is somewhat a lost cause to try to standardise on hyphenation and diacritics of transliterations...
    On Thursday, 29 February 2024 at 14:16:26 GMT, suzuki toshiya via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 Dear Eiso, Fuji-san,

I checked ????????2012 available at

http://edu.shandong.gov.cn/attach/0/b72295c44ff442c8b333a481f524dbe9.pdf

I guess, the glyphs you want to care might be:

"a" in "ai" (?), "uan" (?), "Van" (?) in ???
"g" in "ang" (?), "eng" (????), "ieng" (?), "ueng" (?), "veng" (?) in ???

Am I understanding correctly?

??????1958 (I'm unsure the source of this scanned image):

http://www.moe.gov.cn/ewebeditor/uploadfile/2015/03/02/20150302165814246.pdf

there is no clear distinction of the typeface for "a" & "g".

A distinction of "a" is mentioned in the ??????, special "a" is used for ??,
maybe it would be the update introduced in 2012.

But yet I'm unsure about the background to distinguish "g".

Regards,
mpsuzuki

On 2024/02/29 22:28, ??? via mpeg-otspec wrote:
> Fuji-San,
> 
> Thank you for your comments. The most official materials for Hanyu Pinyin forms are ?????? and ??????.
> 
> Eiso
> ---- Replied Message ----
>? From? ? Takaaki Fuji ? ??<tfuji at morisawa.co.jp><mailto:tfuji at morisawa.co.jp>
> Date? ? 02/29/2024 ??6:45
> To? ? ? ??? <eisoch at 126.com><mailto:eisoch at 126.com>
> Cc? ? ? mpeg-otspec <mpeg-otspec at lists.aau.at><mailto:mpeg-otspec at lists.aau.at>
> Subject Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
> Dear Eiso,
> 
> I'm just curious, but for ?hypy?, is there any good source I can look at for the ?official' glyph forms of Hanyu Pinyin?
> 
> If I understand the issue correctly, ?hypy? is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation?; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!
> 
> Thank you,
> 
> Takaaki Fuji
> 
>> On Feb 26, 2024, at 9:38, ??? via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
>>
>> This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/
>> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637?2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
>>
>> If you have any suggestions or feedbacks, please let me know.
>>
>> Regards,
>> Eiso_______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  _______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240229/84153845/attachment-0001.htm>