From pconstable at microsoft.com Fri Mar 1 00:00:04 2024 From: pconstable at microsoft.com (Peter Constable) Date: Thu, 29 Feb 2024 23:00:04 +0000 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' In-Reply-To: <1049591952.4160733.1709247276951@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> <1049591952.4160733.1709247276951@mail.yahoo.com> Message-ID: I?m not sure why standardization of transliteration conventions is being mentioned. An OT feature would simply be providing a way for content authors to access particular glyph variants from a font to suit their typographic preference. Peter From: mpeg-otspec on behalf of Hin-Tak Leung via mpeg-otspec Date: Thursday, February 29, 2024 at 3:56?PM To: mpeg-otspec at lists.aau.at , suzuki toshiya Cc: Eiso CHAN Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy' 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 wrote: For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might be https://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 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 ? ??> > Date 02/29/2024 ??6:45 > To ??? > > Cc mpeg-otspec > > 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 > 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: From lunde at unicode.org Fri Mar 1 19:34:02 2024 From: lunde at unicode.org (Ken Lunde) Date: Fri, 1 Mar 2024 10:34:02 -0800 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' In-Reply-To: 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> <1049591952.4160733.1709247276951@mail.yahoo.com> Message-ID: Peter, That is precisely why I explicitly stated that I had no strong objection to registering said feature, though that seemed to have become lost to the noise. In my mind, the question we should be asking is whether the number of fonts that would likely include this feature would rise to the level that it would make sense to register it, as opposed to simply using named character variant or stylistic set features for this purpose. Regards... -- Ken > On Feb 29, 2024, at 15:00, Peter Constable via mpeg-otspec wrote: > > I?m not sure why standardization of transliteration conventions is being mentioned. An OT feature would simply be providing a way for content authors to access particular glyph variants from a font to suit their typographic preference. > Peter > From: mpeg-otspec on behalf of Hin-Tak Leung via mpeg-otspec > Date: Thursday, February 29, 2024 at 3:56?PM > To: mpeg-otspec at lists.aau.at , suzuki toshiya > Cc: Eiso CHAN > Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy' > 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 wrote: > For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might be > https://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 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 ? ?? > > Date 02/29/2024 ??6:45 > > To ??? > > Cc mpeg-otspec

Message-ID: <1021364732.4874856.1709330489026@mail.yahoo.com> Yes, sorry for derailing that discussion. This feature seems to be raised by one vendor for one intended usage, a relation with a national standard. There are a few existing feature tags of a similar nature (in Japanese for historical forms). I was just saying that it is somewhat strange to have features tags concerning the Latin glyphs and Latin diacritics in a Chinese font. (and also questioning the relation with the said national standard). IMO it is a specialised and perhaps even a vendor-specific feature... so I shall point the discussion back: is another vendor likely to want to ship a font with these feature tags? On Friday, 1 March 2024 at 18:34:37 GMT, Ken Lunde via mpeg-otspec wrote: Peter, That is precisely why I explicitly stated that I had no strong objection to registering said feature, though that seemed to have become lost to the noise. In my mind, the question we should be asking is whether the number of fonts that would likely include this feature would rise to the level that it would make sense to register it, as opposed to simply using named character variant or stylistic set features for this purpose. Regards... -- Ken > On Feb 29, 2024, at 15:00, Peter Constable via mpeg-otspec wrote: > > I?m not sure why standardization of transliteration conventions is being mentioned. An OT feature would simply be providing a way for content authors to access particular glyph variants from a font to suit their typographic preference. >? Peter >? From: mpeg-otspec on behalf of Hin-Tak Leung via mpeg-otspec > Date: Thursday, February 29, 2024 at 3:56?PM > To: mpeg-otspec at lists.aau.at , suzuki toshiya > Cc: Eiso CHAN > Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy' > 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 wrote: >? For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might be > https://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 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 ? ?? > > Date? ? 02/29/2024 ??6:45 > > To? ? ? ??? > > Cc? ? ? mpeg-otspec

<1021364732.4874856.1709330489026@mail.yahoo.com> Message-ID: For both of these proposed features, I?m also wondering why using existing stylistic set features wouldn?t be sufficient. Peter From: Hin-Tak Leung Sent: Friday, March 1, 2024 3:01 PM To: Peter Constable ; Ken Lunde Cc: mpeg-otspec at lists.aau.at Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' Yes, sorry for derailing that discussion. This feature seems to be raised by one vendor for one intended usage, a relation with a national standard. There are a few existing feature tags of a similar nature (in Japanese for historical forms). I was just saying that it is somewhat strange to have features tags concerning the Latin glyphs and Latin diacritics in a Chinese font. (and also questioning the relation with the said national standard). IMO it is a specialised and perhaps even a vendor-specific feature... so I shall point the discussion back: is another vendor likely to want to ship a font with these feature tags? On Friday, 1 March 2024 at 18:34:37 GMT, Ken Lunde via mpeg-otspec > wrote: Peter, That is precisely why I explicitly stated that I had no strong objection to registering said feature, though that seemed to have become lost to the noise. In my mind, the question we should be asking is whether the number of fonts that would likely include this feature would rise to the level that it would make sense to register it, as opposed to simply using named character variant or stylistic set features for this purpose. Regards... -- Ken > On Feb 29, 2024, at 15:00, Peter Constable via mpeg-otspec > wrote: > > I?m not sure why standardization of transliteration conventions is being mentioned. An OT feature would simply be providing a way for content authors to access particular glyph variants from a font to suit their typographic preference. > Peter > From: mpeg-otspec > on behalf of Hin-Tak Leung via mpeg-otspec > > Date: Thursday, February 29, 2024 at 3:56?PM > To: mpeg-otspec at lists.aau.at

>, suzuki toshiya > > Cc: Eiso CHAN > > Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy' > 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 > wrote: > For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might be > https://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 > 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 ? ??> > > Date 02/29/2024 ??6:45 > > To ??? > > > Cc mpeg-otspec > > > 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 > 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 > _______________________________________________ > 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: From behdad at behdad.org Sat Mar 2 00:51:38 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Fri, 1 Mar 2024 16:51:38 -0700 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' In-Reply-To: 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> <1049591952.4160733.1709247276951@mail.yahoo.com>

<1021364732.4874856.1709330489026@mail.yahoo.com> Message-ID: For the 'hypy' I think it's simply the Chinese language tag under the Latin script. Any reason why not use that as is? behdad http://behdad.org/ On Fri, Mar 1, 2024 at 3:10?PM Peter Constable via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > For both of these proposed features, I?m also wondering why using existing > stylistic set features wouldn?t be sufficient. > > > > > > Peter > > > > *From:* Hin-Tak Leung > *Sent:* Friday, March 1, 2024 3:01 PM > *To:* Peter Constable ; Ken Lunde < > lunde at unicode.org> > *Cc:* mpeg-otspec at lists.aau.at > *Subject:* Re: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: > 'cabp' and 'hypy' > > > > Yes, sorry for derailing that discussion. This feature seems to be raised > by one vendor for one intended usage, a relation with a national standard. > There are a few existing feature tags of a similar nature (in Japanese for > historical forms). I was just saying that it is somewhat strange to have > features tags concerning the Latin glyphs and Latin diacritics in a Chinese > font. (and also questioning the relation with the said national standard). > IMO it is a specialised and perhaps even a vendor-specific feature... so I > shall point the discussion back: is another vendor likely to want to ship a > font with these feature tags? > > > > > > > > On Friday, 1 March 2024 at 18:34:37 GMT, Ken Lunde via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > > > > > > Peter, > > That is precisely why I explicitly stated that I had no strong objection > to registering said feature, though that seemed to have become lost to the > noise. In my mind, the question we should be asking is whether the number > of fonts that would likely include this feature would rise to the level > that it would make sense to register it, as opposed to simply using named > character variant or stylistic set features for this purpose. > > Regards... > > -- Ken > > > On Feb 29, 2024, at 15:00, Peter Constable via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > > > > I?m not sure why standardization of transliteration conventions is being > mentioned. An OT feature would simply be providing a way for content > authors to access particular glyph variants from a font to suit their > typographic preference. > > Peter > > From: mpeg-otspec on behalf of > Hin-Tak Leung via mpeg-otspec > > Date: Thursday, February 29, 2024 at 3:56?PM > > To: mpeg-otspec at lists.aau.at , suzuki toshiya > > > Cc: Eiso CHAN > > Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' > and 'hypy' > > 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 wrote: > > For those who want to read the source material, it seems that the > canonical sources for GBZ 40637 might be > > https://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 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 ? ??< > mailto:tfuji at morisawa.co.jp > > > > Date 02/29/2024 ??6:45 > > > To ??? > > > > Cc mpeg-otspec < > 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 > > _______________________________________________ > > 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: From tyamamot at adobe.com Sat Mar 2 03:47:38 2024 From: tyamamot at adobe.com (Taro Yamamoto) Date: Sat, 2 Mar 2024 02:47:38 +0000 Subject: [MPEG-OTSPEC] [EXTERNAL] OpenType 'palt' and 'kern' Documentation Revision Proposal In-Reply-To: References:

Message-ID: Fuji-san, You?wrote: > 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 completely agree, and also think that the clarification that Nat made is essentially important. Best, Taro Yamamoto From lunde at unicode.org Sat Mar 2 06:48:22 2024 From: lunde at unicode.org (Ken Lunde) Date: Fri, 1 Mar 2024 21:48:22 -0800 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' In-Reply-To: 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> <1049591952.4160733.1709247276951@mail.yahoo.com>

<1021364732.4874856.1709330489026@mail.yahoo.com> Message-ID: <4BADB86D-FDF8-4ED8-ADA6-EE74670821A8@unicode.org> Behdad, Although it is a bit depressing, about the only environments that support language tagging these days are still modern browsers and some apps, such as Adobe InDesign, so relying on language tagging doesn't seem like a realistic option in this particular case. Regards... -- Ken > On Mar 1, 2024, at 15:51, Behdad Esfahbod wrote: > > For the 'hypy' I think it's simply the Chinese language tag under the Latin script. Any reason why not use that as is? > > behdad > http://behdad.org/ > > > On Fri, Mar 1, 2024 at 3:10?PM Peter Constable via mpeg-otspec wrote: > For both of these proposed features, I?m also wondering why using existing stylistic set features wouldn?t be sufficient. > Peter > From: Hin-Tak Leung > Sent: Friday, March 1, 2024 3:01 PM > To: Peter Constable ; Ken Lunde > Cc: mpeg-otspec at lists.aau.at > Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' > Yes, sorry for derailing that discussion. This feature seems to be raised by one vendor for one intended usage, a relation with a national standard. There are a few existing feature tags of a similar nature (in Japanese for historical forms). I was just saying that it is somewhat strange to have features tags concerning the Latin glyphs and Latin diacritics in a Chinese font. (and also questioning the relation with the said national standard). IMO it is a specialised and perhaps even a vendor-specific feature... so I shall point the discussion back: is another vendor likely to want to ship a font with these feature tags? > On Friday, 1 March 2024 at 18:34:37 GMT, Ken Lunde via mpeg-otspec wrote: > Peter, > > That is precisely why I explicitly stated that I had no strong objection to registering said feature, though that seemed to have become lost to the noise. In my mind, the question we should be asking is whether the number of fonts that would likely include this feature would rise to the level that it would make sense to register it, as opposed to simply using named character variant or stylistic set features for this purpose. > > Regards... > > -- Ken > > > On Feb 29, 2024, at 15:00, Peter Constable via mpeg-otspec wrote: > > > > I?m not sure why standardization of transliteration conventions is being mentioned. An OT feature would simply be providing a way for content authors to access particular glyph variants from a font to suit their typographic preference. > > Peter > > From: mpeg-otspec on behalf of Hin-Tak Leung via mpeg-otspec > > Date: Thursday, February 29, 2024 at 3:56?PM > > To: mpeg-otspec at lists.aau.at , suzuki toshiya > > Cc: Eiso CHAN > > Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy' > > 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 wrote: > > For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might be > > https://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 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 ? ?? > > > Date 02/29/2024 ??6:45 > > > To ??? > > > Cc mpeg-otspec

> > > 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 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 > > _______________________________________________ > > 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 From htl10 at users.sourceforge.net Sat Mar 2 13:30:08 2024 From: htl10 at users.sourceforge.net (Hin-Tak Leung) Date: Sat, 2 Mar 2024 12:30:08 +0000 (UTC) Subject: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' In-Reply-To: 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> <1049591952.4160733.1709247276951@mail.yahoo.com>

<1021364732.4874856.1709330489026@mail.yahoo.com> Message-ID: <602757046.890061.1709382608196@mail.yahoo.com> No, as far as I understand the proposal, 'hypy' is meant to be the Latin language tag under the Chinese script. They want a different Latin language tag than default, because of certain transliteration-specific typographical conventions. On Friday, 1 March 2024 at 23:52:24 GMT, Behdad Esfahbod wrote: For the 'hypy' I think it's simply the Chinese language tag under the Latin script. Any reason why not use that as is? behdad http://behdad.org/ On Fri, Mar 1, 2024 at 3:10?PM Peter Constable via mpeg-otspec wrote: For both of these proposed features, I?m also wondering why using existing stylistic set features wouldn?t be sufficient. ? ? Peter ? From: Hin-Tak Leung Sent: Friday, March 1, 2024 3:01 PM To: Peter Constable ; Ken Lunde Cc: mpeg-otspec at lists.aau.at Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' ? Yes, sorry for derailing that discussion. This feature seems to be raised by one vendor for one intended usage, a relation with a national standard. There are a few existing feature tags of a similar nature (in Japanese for historical forms). I was just saying that it is somewhat strange to have features tags concerning the Latin glyphs and Latin diacritics in a Chinese font. (and also questioning the relation with the said national standard). IMO it is a specialised and perhaps even a vendor-specific feature... so I shall point the discussion back: is another vendor likely to want to ship a font with these feature tags? ? ? ? On Friday, 1 March 2024 at 18:34:37 GMT, Ken Lunde via mpeg-otspec wrote: ? ? Peter, That is precisely why I explicitly stated that I had no strong objection to registering said feature, though that seemed to have become lost to the noise. In my mind, the question we should be asking is whether the number of fonts that would likely include this feature would rise to the level that it would make sense to register it, as opposed to simply using named character variant or stylistic set features for this purpose. Regards... -- Ken > On Feb 29, 2024, at 15:00, Peter Constable via mpeg-otspec wrote: > > I?m not sure why standardization of transliteration conventions is being mentioned. An OT feature would simply be providing a way for content authors to access particular glyph variants from a font to suit their typographic preference. >? Peter >? From: mpeg-otspec on behalf of Hin-Tak Leung via mpeg-otspec > Date: Thursday, February 29, 2024 at 3:56?PM > To: mpeg-otspec at lists.aau.at , suzuki toshiya > Cc: Eiso CHAN > Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy' > 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 wrote: >? For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might be > https://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 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 ??? > > Date? ? 02/29/2024 ??6:45 > > To? ? ? ??? > > Cc? ? ? mpeg-otspec

<1021364732.4874856.1709330489026@mail.yahoo.com> <602757046.890061.1709382608196@mail.yahoo.com> Message-ID: <994632520.5069500.1709384960302@mail.yahoo.com> Hmm, sorry that didn't sound right. But the explanation/rationale is that they want a run of Latin glyphs / diacritics to be shaped according to a special-use convention (for the purpose /convention of transliterating chinese) . On Saturday, 2 March 2024 at 12:32:43 GMT, Hin-Tak Leung via mpeg-otspec wrote: No, as far as I understand the proposal, 'hypy' is meant to be the Latin language tag under the Chinese script. They want a different Latin language tag than default, because of certain transliteration-specific typographical conventions. On Friday, 1 March 2024 at 23:52:24 GMT, Behdad Esfahbod wrote: For the 'hypy' I think it's simply the Chinese language tag under the Latin script. Any reason why not use that as is? behdad http://behdad.org/ On Fri, Mar 1, 2024 at 3:10?PM Peter Constable via mpeg-otspec wrote: For both of these proposed features, I?m also wondering why using existing stylistic set features wouldn?t be sufficient. ? ? Peter ? From: Hin-Tak Leung Sent: Friday, March 1, 2024 3:01 PM To: Peter Constable ; Ken Lunde Cc: mpeg-otspec at lists.aau.at Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy' ? Yes, sorry for derailing that discussion. This feature seems to be raised by one vendor for one intended usage, a relation with a national standard. There are a few existing feature tags of a similar nature (in Japanese for historical forms). I was just saying that it is somewhat strange to have features tags concerning the Latin glyphs and Latin diacritics in a Chinese font. (and also questioning the relation with the said national standard). IMO it is a specialised and perhaps even a vendor-specific feature... so I shall point the discussion back: is another vendor likely to want to ship a font with these feature tags? ? ? ? On Friday, 1 March 2024 at 18:34:37 GMT, Ken Lunde via mpeg-otspec wrote: ? ? Peter, That is precisely why I explicitly stated that I had no strong objection to registering said feature, though that seemed to have become lost to the noise. In my mind, the question we should be asking is whether the number of fonts that would likely include this feature would rise to the level that it would make sense to register it, as opposed to simply using named character variant or stylistic set features for this purpose. Regards... -- Ken > On Feb 29, 2024, at 15:00, Peter Constable via mpeg-otspec wrote: > > I?m not sure why standardization of transliteration conventions is being mentioned. An OT feature would simply be providing a way for content authors to access particular glyph variants from a font to suit their typographic preference. >? Peter >? From: mpeg-otspec on behalf of Hin-Tak Leung via mpeg-otspec > Date: Thursday, February 29, 2024 at 3:56?PM > To: mpeg-otspec at lists.aau.at , suzuki toshiya > Cc: Eiso CHAN > Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy' > 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 wrote: >? For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might be > https://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 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 ??? > > Date? ? 02/29/2024 ??6:45 > > To? ? ? ??? > > Cc? ? ? mpeg-otspec

> > 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 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 > _______________________________________________ > 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 _______________________________________________ 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: From behdad at behdad.org Sun Mar 3 17:08:29 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Sun, 3 Mar 2024 09:08:29 -0700 Subject: [MPEG-OTSPEC] Fully defining DMAP behavior Message-ID: Hi, I filed an issue, with a proposal for the Format 14 issue raised before. Please discuss there: https://github.com/harfbuzz/boring-expansion-spec/issues/138 behdad http://behdad.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.levantovsky at gmail.com Thu Mar 7 21:13:55 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Thu, 7 Mar 2024 15:13:55 -0500 Subject: [MPEG-OTSPEC] Tentative agenda topics for the AHG meeting on March 19 Message-ID: Dear all, Based on the results of the previous meeting and the discussions conducted on the AHG email list ( https://lists.aau.at/pipermail/mpeg-otspec/2024-February/thread.html), I have the following tentative agenda for our next meeting: 1. Review relevant updates / follow-up on the results and outcome of the previous AHG meeting (see https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003289.html for details & resolutions summary). 2. New GSUB features proposal: 'cabp' and 'hypy' (see the link to the draft proposal and the discussion thread at https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003301.html). 3. Proposed revisions to 'palt' and 'kern' documentation (see https://github.com/jcitpc/CJKFont/blob/main/docs/palt_kern.md and the discussion thread at https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003292.html). 4. Clarifying / defining DMAP behavior (see https://github.com/harfbuzz/boring-expansion-spec/issues/138). 5. Updates to VARC table description (see https://github.com/harfbuzz/boring-expansion-spec/issues/137) Please review the proposed agenda items and let me know if I missed anything. Please also note that as a result of the AHG meeting discussion (on Feb. 20) we identified a number of proposals that need further clarifications and updates - please share your updated proposals for review prior to the meeting. I plan to have a final meeting agenda distributed early next week (no later than Tuesday, March 12) along with the Zoom meeting info for participants. All prior participants will be added to the meeting invite and will receive a direct email. If you have not been a participant in the prior meetings and would like to be added to the invite list - please contact me directly. Thank you, Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam at fromoldbooks.org Sun Mar 10 06:57:33 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Sun, 10 Mar 2024 00:57:33 -0500 Subject: [MPEG-OTSPEC] Tentative agenda topics for the AHG meeting on March 19 In-Reply-To: References: Message-ID: <080ec4ee4219daafd4ded503844c884142b040e9.camel@fromoldbooks.org> On Thu, 2024-03-07 at 15:13 -0500, Vladimir Levantovsky via mpeg-otspec > Please review the proposed agenda items and let me know if I missed > anything. Note, i hope to get the boring-expansion :) documents updated in the next day or so, have been a little unwell the past week or two. OK, a lot unwell. There will also be a new document, for fvar, although it?s pretty short; its goal is just to state explicitly what happens when you have multiple axes of the same name in fvar - it's being done today, so we should specify it. I?ve updated the other documents to reflect the last meeting, but not posted them yet, will try to do that today or tomorrow. liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From skef at skef.org Mon Mar 11 06:36:22 2024 From: skef at skef.org (Skef Iterum) Date: Sun, 10 Mar 2024 22:36:22 -0700 Subject: [MPEG-OTSPEC] "master" terminology In-Reply-To: <1709905589.8795378.1707168775084@mail.yahoo.com> References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org> <2140608869.8781385.1707166407350@mail.yahoo.com> <1709905589.8795378.1707168775084@mail.yahoo.com> Message-ID: Had a shower thought this evening: What about "design instance"? And then calling what is the list in fvar, when there is a need to differentiate, a "user instance"? This would be, in effect, extending the distinction between design coordinates and user coordinates to instances. One thing I like about this is that it doesn't carry the heavy weight connotation that "master" seems to, in that it seems natural to talk about the "design instance" of a whole font or of a single glyph, while using "master" for the latter doesn't seem quite right. (A single word would be easier but those tend to be taken one or twice over at this late date.) Skef On 2/5/24 13:32, Hin-Tak Leung 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? > > "primary/primaries" probably can work? "primary source data"? "Source > primary"? > > On Monday, 5 February 2024 at 21:04:50 GMT, Thomas Phinney > 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 > 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 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 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: From dcrossland at google.com Mon Mar 11 06:51:39 2024 From: dcrossland at google.com (Dave Crossland) Date: Sun, 10 Mar 2024 23:51:39 -0600 Subject: [MPEG-OTSPEC] "master" terminology In-Reply-To: References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org> <2140608869.8781385.1707166407350@mail.yahoo.com> <1709905589.8795378.1707168775084@mail.yahoo.com> Message-ID: Hi Personally I am all for changing master/slave naming to primary/secondary, but master is not only contrasted with slave. I have a master's degree. My father was a ship's master. Chess players are masterminds. Mastering is a process in music production, and this is where the word comes to font production from, in my opinion. I don't see this use in opentype as similar at all to say database replication. If we are going to change it, don't think 2 words is going to stick. "Sources", perhaps. Cheers Dave On Sun, Mar 10, 2024, 11:36?PM Skef Iterum via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > Had a shower thought this evening: What about "design instance"? And then > calling what is the list in fvar, when there is a need to differentiate, a > "user instance"? This would be, in effect, extending the distinction > between design coordinates and user coordinates to instances. > > One thing I like about this is that it doesn't carry the heavy weight > connotation that "master" seems to, in that it seems natural to talk about > the "design instance" of a whole font or of a single glyph, while using > "master" for the latter doesn't seem quite right. > > (A single word would be easier but those tend to be taken one or twice > over at this late date.) > > Skef > On 2/5/24 13:32, Hin-Tak Leung 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? > > "primary/primaries" probably can work? "primary source data"? "Source > primary"? > > On Monday, 5 February 2024 at 21:04:50 GMT, Thomas Phinney > 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 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 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 > > _______________________________________________ > 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: From pconstable at microsoft.com Mon Mar 11 21:07:04 2024 From: pconstable at microsoft.com (Peter Constable) Date: Mon, 11 Mar 2024 20:07:04 +0000 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: "master" terminology In-Reply-To: References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org> <2140608869.8781385.1707166407350@mail.yahoo.com> <1709905589.8795378.1707168775084@mail.yahoo.com> Message-ID: Skef: It?s not clear to me in what context you?re suggesting new terminology. You had used it in your doc on CFF2 stem hints in a way that appeared to mean any runtime-selectable variation of the font. The OT and OFF specs already use the terminology ?design-variation instance?, ?design instance?, ?variation instance? or simply ?instance? for that meaning. The things listed in the ?fvar? table are already referred to as ?named instances?, both in the spec and in common parlance. And, as I pointed out earlier, ?master? is defined in the spec as having to do with source data in a font development workflow? I don?t think that?s inconsistent with what Dave has said. Font face: A logical collection of glyph data sharing specific design parameters, along with associated metric data, and names or other metadata. Variation instance: A font face corresponding to a particular position within the variation space of a variable font. Named instance: A variation instance that is specifically defined and assigned a name within the 'fvar' table. Master: A set of source font data that includes complete outline data for a particular font face, used in a font-development workflow. (See Terminology.) Peter From: mpeg-otspec On Behalf Of Dave Crossland via mpeg-otspec Sent: Sunday, March 10, 2024 10:52 PM To: Skef Iterum Cc: mpeg-otspec Subject: [EXTERNAL] Re: [MPEG-OTSPEC] "master" terminology Hi Personally I am all for changing master/slave naming to primary/secondary, but master is not only contrasted with slave. I have a master's degree. My father was a ship's master. Chess players are masterminds. Mastering is a process in music production, and this is where the word comes to font production from, in my opinion. I don't see this use in opentype as similar at all to say database replication. If we are going to change it, don't think 2 words is going to stick. "Sources", perhaps. Cheers Dave On Sun, Mar 10, 2024, 11:36?PM Skef Iterum via mpeg-otspec > wrote: Had a shower thought this evening: What about "design instance"? And then calling what is the list in fvar, when there is a need to differentiate, a "user instance"? This would be, in effect, extending the distinction between design coordinates and user coordinates to instances. One thing I like about this is that it doesn't carry the heavy weight connotation that "master" seems to, in that it seems natural to talk about the "design instance" of a whole font or of a single glyph, while using "master" for the latter doesn't seem quite right. (A single word would be easier but those tend to be taken one or twice over at this late date.) Skef On 2/5/24 13:32, Hin-Tak Leung 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? "primary/primaries" probably can work? "primary source data"? "Source primary"? On Monday, 5 February 2024 at 21:04:50 GMT, Thomas Phinney 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 > 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 > 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 > 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 _______________________________________________ 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: From skef at skef.org Mon Mar 11 21:49:27 2024 From: skef at skef.org (Skef Iterum) Date: Mon, 11 Mar 2024 13:49:27 -0700 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: "master" terminology In-Reply-To: References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org> <2140608869.8781385.1707166407350@mail.yahoo.com> <1709905589.8795378.1707168775084@mail.yahoo.com> Message-ID: <8f27eb90-1280-4afe-80f9-53e0ee8b3ea8@skef.org> I thought by the context of what I was responding to that it would be clear I was offering another alternative to "master", which some people (regardless of etymology, see GitHub) may want to change. Note that I don't have strong opinions on that either way; I didn't bring it up. As far as my use of that term in the document that started this thread, I had already changed that before the last meeting, as I noted on the list in a different message. Skef On 3/11/24 13:07, Peter Constable wrote: > > Skef: > > It?s not clear to me in what context you?re suggesting new > terminology. You had used it in your doc on CFF2 stem hints in a way > that appeared to mean any runtime-selectable variation of the font. > The OT and OFF specs already use the terminology ?design-variation > instance?, ?design instance?, ?variation instance? or simply > ?instance? for that meaning. The things listed in the ?fvar? table are > already referred to as ?named instances?, both in the spec and in > common parlance. And, as I pointed out earlier, ?master? is defined in > the spec as having to do with source data in a font development > workflow? I don?t think that?s inconsistent with what Dave has said. > > *Font face:*?A logical collection of glyph data sharing specific > design parameters, along with associated metric data, and names or > other metadata. > > *Variation instance:*?A font face corresponding to a particular > position within the variation space of a variable font. > > *Named instance:*?A variation instance that is specifically defined > and assigned a name within the 'fvar' table. > > *Master:*?A set of source font data that includes complete outline > data for a particular font face, used in a font-development workflow. > > (See Terminology > .) > > Peter > > *From:*mpeg-otspec *On Behalf Of > *Dave Crossland via mpeg-otspec > *Sent:* Sunday, March 10, 2024 10:52 PM > *To:* Skef Iterum > *Cc:* mpeg-otspec > *Subject:* [EXTERNAL] Re: [MPEG-OTSPEC] "master" terminology > > Hi > > Personally I am all for changing master/slave naming to > primary/secondary, but master is not only contrasted with slave. I > have a master's degree. My father was a ship's master. Chess players > are masterminds. > > Mastering is a process in music production, and this is where the word > comes to font production from, in my opinion. I don't see this use in > opentype as similar at all to say database replication. > > If we are going to change it, don't think 2 words is going to stick. > "Sources", perhaps. > > Cheers > > Dave > > On Sun, Mar 10, 2024, 11:36?PM Skef Iterum via mpeg-otspec > wrote: > > Had a shower thought this evening: What about "design instance"? > And then calling what is the list in fvar, when there is a need to > differentiate, a "user instance"? This would be, in effect, > extending the distinction between design coordinates and user > coordinates to instances. > > One thing I like about this is that it doesn't carry the heavy > weight connotation that "master" seems to, in that it seems > natural to talk about the "design instance" of a whole font or of > a single glyph, while using "master" for the latter doesn't seem > quite right. > > (A single word would be easier but those tend to be taken one or > twice over at this late date.) > > Skef > > On 2/5/24 13:32, Hin-Tak Leung 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? > > "primary/primaries" probably can work? "primary source data"? > "Source primary"? > > On Monday, 5 February 2024 at 21:04:50 GMT, Thomas Phinney > > 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 > 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 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 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 > > _______________________________________________ > 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: From pconstable at microsoft.com Tue Mar 12 00:54:39 2024 From: pconstable at microsoft.com (Peter Constable) Date: Mon, 11 Mar 2024 23:54:39 +0000 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: "master" terminology In-Reply-To: <8f27eb90-1280-4afe-80f9-53e0ee8b3ea8@skef.org> References: <6e69b907-68bc-4e25-9ca5-86438fef6218@skef.org> <2140608869.8781385.1707166407350@mail.yahoo.com> <1709905589.8795378.1707168775084@mail.yahoo.com> <8f27eb90-1280-4afe-80f9-53e0ee8b3ea8@skef.org> Message-ID: Got it. Since 2016, the spec has already adopted alternative terminology along the lines you proposed. But over the past 7+ years, something I?ve noticed is that some people?a minority, I think?have continued to use ?master? instead of ?instance?. Your original document was a case of that. My impression has been that this comes, in part, from past familiarity with Adobe Multiple Master fonts, though that is a bit odd since ?instance? was already used in relation to MM fonts. E.g., Developer Resources (archive.org) LCDF Type Software Multiple Masters - FreeType-2.13.2 API Reference It could also stem from contexts like FreeType documentation (see link above) that continue to refer to ?Multiple Masters? two decades after Adobe stopped selling or offering tech support for MM fonts. Or, perhaps it stems from seeing ?master? used in the context of development workflows and under-appreciation that the data contained in OT variable fonts is not the same as what might be used in sources. Glyphs for example, continues to talk about ?masters?. But also distinguishes that term from ?instances?: ?Masters are what you draw. They are the input for the ensuing interpolation. ? Instances or styles are what the computer calculates. They are the output, the exported result of the interpolation.? Multiple Masters, part 1: setting up masters | Glyphs (glyphsapp.com) (This article reflects a MM conceptualization, the only difference being that instances are generated by the font developer, not by a MM font user. It doesn?t take into consideration variable fonts.) As for use of the term ?master? in the context of font development workflows, I think that?s outside the scope of the OT / OFF spec. The only reason ?master? was included in the terminology section in OT 1.8 was to clarify that the term is not directly relevant to OT as a distribution format. If a different term for font development workflows became conventional, ?master? could certainly be removed from the OT / OFF spec terminology. Peter From: Skef Iterum Sent: Monday, March 11, 2024 1:49 PM To: Peter Constable ; Dave Crossland Cc: mpeg-otspec Subject: Re: [EXTERNAL] Re: [MPEG-OTSPEC] "master" terminology You don't often get email from skef at skef.org. Learn why this is important I thought by the context of what I was responding to that it would be clear I was offering another alternative to "master", which some people (regardless of etymology, see GitHub) may want to change. Note that I don't have strong opinions on that either way; I didn't bring it up. As far as my use of that term in the document that started this thread, I had already changed that before the last meeting, as I noted on the list in a different message. Skef On 3/11/24 13:07, Peter Constable wrote: Skef: It?s not clear to me in what context you?re suggesting new terminology. You had used it in your doc on CFF2 stem hints in a way that appeared to mean any runtime-selectable variation of the font. The OT and OFF specs already use the terminology ?design-variation instance?, ?design instance?, ?variation instance? or simply ?instance? for that meaning. The things listed in the ?fvar? table are already referred to as ?named instances?, both in the spec and in common parlance. And, as I pointed out earlier, ?master? is defined in the spec as having to do with source data in a font development workflow? I don?t think that?s inconsistent with what Dave has said. Font face: A logical collection of glyph data sharing specific design parameters, along with associated metric data, and names or other metadata. Variation instance: A font face corresponding to a particular position within the variation space of a variable font. Named instance: A variation instance that is specifically defined and assigned a name within the 'fvar' table. Master: A set of source font data that includes complete outline data for a particular font face, used in a font-development workflow. (See Terminology.) Peter From: mpeg-otspec

On Behalf Of Dave Crossland via mpeg-otspec Sent: Sunday, March 10, 2024 10:52 PM To: Skef Iterum Cc: mpeg-otspec

Subject: [EXTERNAL] Re: [MPEG-OTSPEC] "master" terminology Hi Personally I am all for changing master/slave naming to primary/secondary, but master is not only contrasted with slave. I have a master's degree. My father was a ship's master. Chess players are masterminds. Mastering is a process in music production, and this is where the word comes to font production from, in my opinion. I don't see this use in opentype as similar at all to say database replication. If we are going to change it, don't think 2 words is going to stick. "Sources", perhaps. Cheers Dave On Sun, Mar 10, 2024, 11:36?PM Skef Iterum via mpeg-otspec > wrote: Had a shower thought this evening: What about "design instance"? And then calling what is the list in fvar, when there is a need to differentiate, a "user instance"? This would be, in effect, extending the distinction between design coordinates and user coordinates to instances. One thing I like about this is that it doesn't carry the heavy weight connotation that "master" seems to, in that it seems natural to talk about the "design instance" of a whole font or of a single glyph, while using "master" for the latter doesn't seem quite right. (A single word would be easier but those tend to be taken one or twice over at this late date.) Skef On 2/5/24 13:32, Hin-Tak Leung 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? "primary/primaries" probably can work? "primary source data"? "Source primary"? On Monday, 5 February 2024 at 21:04:50 GMT, Thomas Phinney 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 > 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 > 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 > 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 _______________________________________________ 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: From skef at skef.org Tue Mar 12 08:53:50 2024 From: skef at skef.org (Skef Iterum) Date: Tue, 12 Mar 2024 00:53:50 -0700 Subject: [MPEG-OTSPEC] Update on Adobe ISO proposals Message-ID: This is the current status of Adobe's proposals, in advance of next week's Ad Hoc meeting: * "negation" is unchanged: https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/negation.pdf * "cff2hintorder": Peter and I discussed this over email and concluded that this counts as a couple of clarifications of what had been ambiguous rather than outright changes. We tentatively decided that he would edit the language and roll the content in through his ongoing OpenType synchronization project. We can discuss this approach at the meeting if anyone has concerns. The (unedited original) document is still https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/cff2hintorder.pdf * I gave "varchintguide" a substantial editing pass. https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf * I gave "newfeatvar_spec" an editing pass as well. Note that the Microsoft reps have not yet had an opportunity to take up their concerns from the last meeting about this with me, but I'm hoping that can still happen before next Tuesday. https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/newfeatvar_spec.pdf Thanks, Skef -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam at fromoldbooks.org Tue Mar 12 21:45:36 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Tue, 12 Mar 2024 16:45:36 -0400 Subject: [MPEG-OTSPEC] Tentative agenda topics for the AHG meeting on March 19 In-Reply-To: <080ec4ee4219daafd4ded503844c884142b040e9.camel@fromoldbooks.org> References: <080ec4ee4219daafd4ded503844c884142b040e9.camel@fromoldbooks.org> Message-ID: <304cfd7fd3a55a87e9b6d8aa638c39f5a8f1db61.camel@fromoldbooks.org> Sorry for delay. We now have. (1) Updates based on Public Feedback to Changes to the OFF Font Format As before, but with fvar and dmap removed (2) Improving interoperability of OpenFontFormat files (fonts) in the area of duplicated axis names This is the clarification regarding fvar (3) Increasing file-size and bandwidth efficiency, and improving internationalization support, of OpenFont files using delta tables (DMAP) The documents are at https://github.com/harfbuzz/boring-expansion-spec/tree/main/iso_docs Scroll past the list of files to get to the heading, 2024-03 (March 2024) liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From vladimir.levantovsky at gmail.com Wed Mar 13 00:29:17 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Tue, 12 Mar 2024 19:29:17 -0400 Subject: [MPEG-OTSPEC] Agenda topics for the AHG meeting on March 19 Message-ID: Dear AHG members, Thank you for your active participation and contributions to the OFF 5th edition (ISO/IEC 14496-22) development. Like we previously planned, we will have our next AHG meeting scheduled next week on March 19 at 14:00-16:00 UTC. The following are the agenda topics for the meeting: 1. Review updated proposals that were discussed at the previous AHG meeting (see https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003289.html for details & resolutions summary): - proposed DMAP updates: https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-dmap-2024-03.pdf - proposed 'fvar' changes and clarifications for improved handling of duplicate axis names: https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-fvar-2024-03.pdf -proposed minor changes and clarifications to 'hdmx', LTSH, and JSTF tables based on public feedback: https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-varc-and-other-updates-03.pdf - updated "VARC hint guidance for CFF2": https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf - editorial updates to "Feature Variations: New LookupVariation Mechanism" proposal: https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/newfeatvar_spec.pdf - CFF2 hint ordering: https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/cff2hintorder.pdf 2. New GSUB features proposal: 'cabp' and 'hypy' (see the link to the draft proposal and the discussion thread at https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003301.html). 3. Proposed revisions to 'palt' and 'kern' documentation (see https://github.com/jcitpc/CJKFont/blob/main/docs/palt_kern.md and the discussion thread at https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003292.html). As you can see, we have a packed agenda and I would very much appreciate it if you review the updated documents and prepare your comments ahead of the meeting. Due to the public nature of the AHG email list archive, a formal Zoom meeting invite will not be shared on this list, and will be sent directly to participants. All prior meeting participants will be added to the meeting invite and will receive a direct email. If you have not been a participant in the prior meetings and would like to be added to the invite list - please contact me directly. Thank you, Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at tiro.ca Wed Mar 13 18:24:37 2024 From: john at tiro.ca (John Hudson) Date: Wed, 13 Mar 2024 10:24:37 -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:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> Message-ID: <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> On 2024-02-22 6:59 am, 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) How does the axis handle prioritisation of justification techniques? In answer to Nate?s query about how the JSTF table made it into the spec, I discussed this, quite a few years ago, with Eliyezer Kohen. The table had been spec?d to provide mechanisms to address Arabic justification as the problem space had been described to Eliyezer by Tom Milo. This involved being able to define multiple mechanisms to affect justification?alternate forms, elongation, spacing adjustments?and then /prioritise/ these mechanisms. I think Nate is quite right that the table is not useful or really understandable without a corresponding justification engine specification, and my impression has long been that the JSTF table spec was something that would need to be revised in implementation (as various other parts of OpenType have been). JH -- John Hudson Tiro Typeworks Ltdwww.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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at simon-cozens.org Wed Mar 13 18:59:31 2024 From: simon at simon-cozens.org (Simon Cozens) Date: Wed, 13 Mar 2024 17:59:31 +0000 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> Message-ID: <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org> On 13/03/2024 17:24, John Hudson via mpeg-otspec wrote: > How does the axis handle prioritisation of justification techniques? A combination of Feature Variations ("alternate layers") and per-glyph masters ("intermediate layers") means that you can prioritize different techniques at different parts of the design space. For example, perhaps at JSTF=0 - JSTF=100 the space glyph expands to its full width; but meanwhile at JSTF=50 the kashida glyph begins to expand until it reaches its full width at JSTF=1000; at JSTF=500 final kafs and final nuns begin to expand; then at JSTF=800 they switch over to swash forms... With per-glyph masters, one axis can be seen as the union of multiple per-glyphs axes... Simon From skef at skef.org Thu Mar 14 09:46:44 2024 From: skef at skef.org (Skef Iterum) Date: Thu, 14 Mar 2024 01:46:44 -0700 Subject: [MPEG-OTSPEC] Negated condition sets Message-ID: Vladimir reminded me that there were some outstanding issues relating to flags, conditions, and condition sets. I'm just going to give my views on this subject briefly. Do condition tables need flags? The main use case for a flag we discussed was to negate the condition, and in my view using a different format number is both more compatible (in that the existing type doesn't change) and more compact. One could split the existing uint16 format field into a format and flags, but given that the existing format is 1 the flags would come in the first byte rather than the second. Do condition sets need to be negate-able? The only use of condition sets in the working draft is part of the Feature Variations mechanism, and Adobe's proposal for updating that system supports something equivalent to a negated condition set (the set of lookups to add when at least one condition is false). So until condition sets are used elsewhere (perhaps in VARC) the need for explicit negated condition sets is speculative. How would we make condition sets negate-able? Condition sets don't have flags for a format field, so there's no entirely clean way of altering their behavior. The least ugly way that I've thought of is to add a special offset value with that meaning to the list, e.g. 1 or 2. (One could imagine not implementing explicitly negated conditions at all, and instead making an offset of 1 mean "negate the whole set", 2 mean "negate the condition at the following offset" and perhaps even an offset of 3 mean "or". However, there are already other means of achieving what amounts to an "or" and this kind of a approach seems hacky. Still, just adding the 1 with that meaning might be the best solution for negating the set if we need that.) Skef -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at tiro.ca Thu Mar 14 16:02:39 2024 From: john at tiro.ca (John Hudson) Date: Thu, 14 Mar 2024 08:02:39 -0700 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org> References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org> Message-ID: On 2024-03-13 10:59 am, Simon Cozens via mpeg-otspec wrote: > >> How does the axis handle prioritisation of justification techniques? > > A combination of Feature Variations ("alternate layers") and per-glyph > masters ("intermediate layers") means that you can prioritize > different techniques at different parts of the design space. > > For example, perhaps at JSTF=0 - JSTF=100 the space glyph expands to > its full width; but meanwhile at JSTF=50 the kashida glyph begins to > expand until it reaches its full width at JSTF=1000; at JSTF=500 final > kafs and final nuns begin to expand; then at JSTF=800 they switch over > to swash forms... > > With per-glyph masters, one axis can be seen as the union of multiple > per-glyphs axes... Interesting. Will need to think about this. ?JSTF=0 - JSTF=1000? implies that justification always means expanding-to-fill. Conceptually, the model could handle contraction also, I think. Has this been considered in the implementation? I am thinking about paragraph level justification, where justification may involve re-wrapping text, and designs that have mechanisms that compress text horizontally. JH -- 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 simon at simon-cozens.org Fri Mar 15 12:29:21 2024 From: simon at simon-cozens.org (Simon Cozens) Date: Fri, 15 Mar 2024 11:29:21 +0000 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org> Message-ID: On 14/03/2024 15:02, John Hudson via mpeg-otspec wrote: > ?JSTF=0 - JSTF=1000? implies that justification always means > expanding-to-fill. Conceptually, the model could handle contraction > also, I think. Has this been considered in the implementation? Sure, starting the JSTF axis at zero was just an example to how different things could be done along different expansion values. It works mutatis mutandis the other way around: if you want a font that runs JSTF=-1000 to JSTF=1000, just arrange for the glyphs to contract or switch to condensed shapes at appropriate points along the negative part of the axis. S From john at tiro.ca Fri Mar 15 16:07:50 2024 From: john at tiro.ca (John Hudson) Date: Fri, 15 Mar 2024 08:07:50 -0700 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org>

Message-ID: <9d0feb4e-3990-45d2-bf61-a25091d2e6d7@tiro.ca> I presume the idea is that all the intelligence for substitutions and insertions resides in the feature variations GSUB for the JSTF axis, including contextually controlled kashida insertion logic, and the justification engine would only be responsible for figuring out how much to contract or expand lines to fit the measure? For the benefit of the engine, we would need to define what should happen if the JSTF axis maxes out and the measure still has not been filled?probably allowing further expansion of inter-word spacing as per most existing justification engines. As an axis that is intended to interact with common software functionality, this looks to me like something that might be a clear candidate for formal registration in the spec alongside weight, width, etc. JH On 2024-03-15 4:29 am, Simon Cozens via mpeg-otspec wrote: > On 14/03/2024 15:02, John Hudson via mpeg-otspec wrote: >> ?JSTF=0 - JSTF=1000? implies that justification always means >> expanding-to-fill. Conceptually, the model could handle contraction >> also, I think. Has this been considered in the implementation? > > Sure, starting the JSTF axis at zero was just an example to how > different things could be done along different expansion values. It > works mutatis mutandis the other way around: if you want a font that > runs JSTF=-1000 to JSTF=1000, just arrange for the glyphs to contract > or switch to condensed shapes at appropriate points along the negative > part of the axis. > > S > > _______________________________________________ > 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 lorp at lorp.org Fri Mar 15 16:27:03 2024 From: lorp at lorp.org (Laurence Penney) Date: Fri, 15 Mar 2024 15:27:03 +0000 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: <9d0feb4e-3990-45d2-bf61-a25091d2e6d7@tiro.ca> References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org>

<9d0feb4e-3990-45d2-bf61-a25091d2e6d7@tiro.ca> Message-ID: In general it would be nice to have a method of knowing, given a designspace location, if any clamping has taken place. Currently the only way to do this would be for an app to load the fvar table and compare with the requested designspace location: not hard in principle, but often not possible (e.g. in a browser). Providing min/max/default for each axis would be the simplest way to achieve this. - Laurence > On 15 Mar 2024, at 15:07, John Hudson via mpeg-otspec wrote: > > I presume the idea is that all the intelligence for substitutions and insertions resides in the feature variations GSUB for the JSTF axis, including contextually controlled kashida insertion logic, and the justification engine would only be responsible for figuring out how much to contract or expand lines to fit the measure? > > For the benefit of the engine, we would need to define what should happen if the JSTF axis maxes out and the measure still has not been filled?probably allowing further expansion of inter-word spacing as per most existing justification engines. > > As an axis that is intended to interact with common software functionality, this looks to me like something that might be a clear candidate for formal registration in the spec alongside weight, width, etc. > > JH > > > On 2024-03-15 4:29 am, Simon Cozens via mpeg-otspec wrote: >> On 14/03/2024 15:02, John Hudson via mpeg-otspec wrote: >>> ?JSTF=0 - JSTF=1000? implies that justification always means expanding-to-fill. Conceptually, the model could handle contraction also, I think. Has this been considered in the implementation? >> >> Sure, starting the JSTF axis at zero was just an example to how different things could be done along different expansion values. It works mutatis mutandis the other way around: if you want a font that runs JSTF=-1000 to JSTF=1000, just arrange for the glyphs to contract or switch to condensed shapes at appropriate points along the negative part of the axis. >> >> S From skef at skef.org Fri Mar 15 16:52:45 2024 From: skef at skef.org (Skef Iterum) Date: Fri, 15 Mar 2024 08:52:45 -0700 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org>

Message-ID: Just from a conceptual level, it seems like one thing that would be easy to do with an engine but hard to do with an axis is to control the number of times the /same/ contracting or expanding mechanism is used on a given line. So, to be over-simplistic, if there's a larger "fi" and a smaller "fi" and two "fi" candidates on a line, making it so that only one uses the smaller and one uses the larger. Another thing that seems harder to with an axis is to trade off expanding and contracting elements. So, for example, if you have a way of making "Qu" significantly larger and a way of making "ch" slightly smaller, achieving a happy medium increase in length by using both of those. For reference for this discussion Is there some means of controlling the number of times a given substitution is applied or trading off expanding and contracting applications? (One could use context, of course, to introduce some gradualness, but not always the specific degree of it one wants.) Skef On 3/15/24 04:29, Simon Cozens via mpeg-otspec wrote: > On 14/03/2024 15:02, John Hudson via mpeg-otspec wrote: >> ?JSTF=0 - JSTF=1000? implies that justification always means >> expanding-to-fill. Conceptually, the model could handle contraction >> also, I think. Has this been considered in the implementation? > > Sure, starting the JSTF axis at zero was just an example to how > different things could be done along different expansion values. It > works mutatis mutandis the other way around: if you want a font that > runs JSTF=-1000 to JSTF=1000, just arrange for the glyphs to contract > or switch to condensed shapes at appropriate points along the negative > part of the axis. > > S > > _______________________________________________ > 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: From simon at simon-cozens.org Fri Mar 15 17:09:03 2024 From: simon at simon-cozens.org (Simon Cozens) Date: Fri, 15 Mar 2024 16:09:03 +0000 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: <9d0feb4e-3990-45d2-bf61-a25091d2e6d7@tiro.ca> References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org>

<9d0feb4e-3990-45d2-bf61-a25091d2e6d7@tiro.ca> Message-ID: <8fd18227-4945-47f1-a614-8a56023424f2@simon-cozens.org> On 15/03/2024 15:07, John Hudson via mpeg-otspec wrote: > I presume the idea is that all the intelligence for substitutions and > insertions resides in the feature variations GSUB for the JSTF axis, > including contextually controlled kashida insertion logic, and the > justification engine would only be responsible for figuring out how much > to contract or expand lines to fit the measure? Exactly, yes. I'm only familiar with it in concept from the font side of things; you'll have to discuss with Behdad how he implemented it on the Harfbuzz side. > As an axis that is intended to interact with common software > functionality, this looks to me like something that might be a clear > candidate for formal registration in the spec alongside weight, width, etc. Well, yes; but the premise of this discussion was "variable fonts can do everything that the JSTF table promised, so I don't think we need updates to the JSTF table any more." S From john at tiro.ca Fri Mar 15 17:47:01 2024 From: john at tiro.ca (John Hudson) Date: Fri, 15 Mar 2024 09:47:01 -0700 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org>

Message-ID: On 2024-03-15 8:52 am, Skef Iterum via mpeg-otspec wrote: > > Just from a conceptual level, it seems like one thing that would be easy > to do with an engine but hard to do with an axis is to control the number > of times the /same/ contracting or expanding mechanism is used on a given > line. So, to be over-simplistic, if there's a larger "fi" and a > smaller "fi" and two > "fi" candidates on a line, making it so that only one uses the smaller > and > one uses the larger. > > Another thing that seems harder to with an axis is to trade off expanding > and contracting elements. So, for example, if you have a way of making > "Qu" significantly larger and a way of making "ch" slightly smaller, > achieving > a happy medium increase in length by using both of those. > So, for example, if an expansion substitution made the width slightly too much for the measure, a contraction substitution elsewhere in the line might bring it to where it needs to be? Yes, that seems problematic unless the engine is able to apply the JSTF axis selectively within a line rather than across the whole line. JH -- John Hudson Tiro Typeworks Ltdwww.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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Fri Mar 15 17:54:46 2024 From: skef at skef.org (Skef Iterum) Date: Fri, 15 Mar 2024 09:54:46 -0700 Subject: [MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020) In-Reply-To: References:

<87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org> <5109148e-9346-4a42-aebf-a19063ae39ef@tiro.ca> <54cdc81c-1d6f-4579-b6bc-3cc2f2c9f9f8@simon-cozens.org>

Message-ID: Selective application would be an option, but because the actual mechanisms implemented as part of the axis would (presumably) be opaque at that level, you'd either be stabbing around in the dark hoping to get a good combination, or iteratively "discovering" the particular mechanisms based on the substitutions or adjustments being made and then applying the axis to parts of the line on that basis. Skef On 3/15/24 09:47, John Hudson via mpeg-otspec wrote: > On 2024-03-15 8:52 am, Skef Iterum via mpeg-otspec wrote: >> >> Just from a conceptual level, it seems like one thing that would be easy >> to do with an engine but hard to do with an axis is to control the number >> of times the /same/ contracting or expanding mechanism is used on a given >> line. So, to be over-simplistic, if there's a larger "fi" and a >> smaller "fi" and two >> "fi" candidates on a line, making it so that only one uses the >> smaller and >> one uses the larger. >> >> Another thing that seems harder to with an axis is to trade off expanding >> and contracting elements. So, for example, if you have a way of making >> "Qu" significantly larger and a way of making "ch" slightly smaller, >> achieving >> a happy medium increase in length by using both of those. >> > So, for example, if an expansion substitution made the width slightly > too much for the measure, a contraction substitution elsewhere in the > line might bring it to where it needs to be? Yes, that seems > problematic unless the engine is able to apply the JSTF axis > selectively within a line rather than across the whole line. > > JH > -- > > John Hudson > Tiro Typeworks Ltdwww.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.levantovsky at gmail.com Tue Mar 19 17:36:05 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Tue, 19 Mar 2024 12:36:05 -0400 Subject: [MPEG-OTSPEC] Tentative agenda topics for the AHG meeting on March 19 In-Reply-To: References: Message-ID: Dear all, This is just a quick update on the results of the AHG meeting today. We had a packed agenda and ran out of meeting time before we could discuss all scheduled topics. We decided to schedule an additional time this week to discuss the remaining topics - the additional follow-up call is scheduled on Thursday, March 21st at 14:00 UTC (same time of day as today's meeting). We also plan to have another AHG Zoom call scheduled for April 9 to discuss any and all remaining issues and still have time to finalize the input submissions for the next SC29/WG3 meeting, which will be held on April 22-26. The input submission deadlines for the next WG meeting are as follows: - April 15: deadline for registration of input contributions; - April 17: upload deadline for registered input contributions. Thanks again to all participants for your valuable contributions to this work! Vladimir On Thu, Mar 7, 2024 at 3:13?PM Vladimir Levantovsky < vladimir.levantovsky at gmail.com> wrote: > Dear all, > > Based on the results of the previous meeting and the discussions conducted > on the AHG email list ( > https://lists.aau.at/pipermail/mpeg-otspec/2024-February/thread.html), I > have the following tentative agenda for our next meeting: > > 1. Review relevant updates / follow-up on the results and outcome of the > previous AHG meeting (see > https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003289.html for > details & resolutions summary). > 2. New GSUB features proposal: 'cabp' and 'hypy' (see the link to the > draft proposal and the discussion thread at > https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003301.html). > 3. Proposed revisions to 'palt' and 'kern' documentation (see > https://github.com/jcitpc/CJKFont/blob/main/docs/palt_kern.md and the > discussion thread at > https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003292.html). > 4. Clarifying / defining DMAP behavior (see > https://github.com/harfbuzz/boring-expansion-spec/issues/138). > 5. Updates to VARC table description (see > https://github.com/harfbuzz/boring-expansion-spec/issues/137) > > Please review the proposed agenda items and let me know if I missed > anything. Please also note that as a result of the AHG meeting discussion > (on Feb. 20) we identified a number of proposals that need further > clarifications and updates - please share your updated proposals for review > prior to the meeting. > > I plan to have a final meeting agenda distributed early next week (no > later than Tuesday, March 12) along with the Zoom meeting info for > participants. All prior participants will be added to the meeting invite > and will receive a direct email. If you have not been a participant in the > prior meetings and would like to be added to the invite list - please > contact me directly. > > Thank you, > Vladimir > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Tue Mar 19 18:48:19 2024 From: skef at skef.org (Skef Iterum) Date: Tue, 19 Mar 2024 10:48:19 -0700 Subject: [MPEG-OTSPEC] "newfeatvar" and the LookupCondition record Message-ID: Towards the end of today's meeting Peter raised a potential concern about one aspect of the "LookupVariation" proposal for Feature Variations. This may well have just been one example of more general concerns, but that particular aspect of the spec does serve as a useful jumping-off point for explanation of where this proposal, and some of the other proposals Adobe has made (condition negations) and promoted (conditional VARC), are coming from. In the vast majority of cases, the glyphs and other properties in a variable font vary smoothly and linearly. We generally discuss two archetypal cases of non-linear variation that stand in for a larger set: Changing the appearance of a dollar sign at different points in variation space, and changing the kerning between "T" and "o" so that the latter scoots under the former when there is room (or scoots out from under it when there isn't room). For each of these cases there are two approaches to getting the desired effect. One involves simulating a non-linear change with an abrupt linear change. By putting two "masters" very close to one another in design space, values appear to change suddenly. So, if you have one master of a "$" glyph with two bars separated by a space, and another where those two bars overlap and appear as one bar, you can put those close together on an axis and it will appear that the two suddenly become one when moving the axis in one direction, and vice versa when moving it in the other. The other approach is to use the Feature Variations mechanism to switch between two options, each of which varies in the usual way across the designspace. So you make a "$" glyph with one bar and a different glyph with two bars and you switch between them by having a substitution that is only active in some regions of designspace. Now, consider this same dichotomy for the "T" and "o" case. If you want the kerning to change suddenly you can put two "masters" -- each of which is just a kerning value: an integer -- close together in design space. So if there is just one axis 200,400,900 wght axis maybe something analogous to: ??? pos T o (wght=200u:40 wght=400u:45 wght=500u:47 wght=500+u:60 wght=900u:61); (Where the "+" indicates that the location on that axis should be one F2dot14 unit higher than "500" in user-units.) However, although this seems to be only rarely noted, you can also use Feature Variations to approach this problem -- that mechanism is available in GPOS just as much as in GSUB. As with the dollar sign case one would "design" two linearly-varying kerning values, one that is correct for the "T" and "o" near each other in the less bold regions of the axis and the other that is correct in the more bold regions of the axis when they are further away. But now there is an important difference: With the dollar-sign case you need a substitution to be present in some regions of designspace and absent in others. With the kerning case you need one value to be present in some regions of designspace and the other value to be present in others. That need is where the feature Peter asked about is coming from. As currently proposed the LookupCondition record has an offset to a trueLookupIndexList (with lookups to add when the condition set is true) and an offset to a falseLookupIndexList (with lookups to add when the condition set is false). This is in effect an if/else structure. It's that way because when Behdad and I were discussing this need that was his preference and it seemed fine to me. The other way to do it would be to have a means of negating a condition set, and then using a separate LookupCondition record with the negation. But as we've discussed, condition sets aren't versioned so you can't do that with the condition set itself, and would therefore need a flag in the LookupCondition record to do it. The else is (arguably) cleaner. Anyway, the more general point is that in making our proposals in this space Adobe has been trying to ensure that the functionality of Feature Variations is /general/, that the tools you might need are in the box. Sometimes you might need to effect a change across a non-rectilinear surface of design space, hence /condition values/. Sometimes you might want to switch between kerning values rather than playing "master games", hence /negated condition sets/ in some form (currently an "else"). Much of this thinking has come out of our ongoing work on extending the feature file format to directly support variable fonts, which I am currently implementing in prototype form. The things you might want to do at the feature file level help clarify where and how the underlying functionality is lacking. These things can be frustrating to specify because there are often many different ways of meeting the set of needs. Still, we believe that the needs are there, and we haven't gone off into the weeds in terms of the proposed functionality. Skef -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.levantovsky at gmail.com Wed Mar 20 16:38:24 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Wed, 20 Mar 2024 11:38:24 -0400 Subject: [MPEG-OTSPEC] Updated Working Draft text is now available for public review Message-ID: Dear all, I am pleased to let you know that the updated text of the WD of ISO/IEC 14496-22 5th edition Open font format is now available for download. Your review and comments would be much appreciated. Thank you, Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsuzuki at hiroshima-u.ac.jp Sat Mar 23 16:21:14 2024 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Sun, 24 Mar 2024 00:21:14 +0900 Subject: [MPEG-OTSPEC] Questions about "cabp" feature proposal (Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy') In-Reply-To: References: Message-ID: <9d9476df-7b3e-4496-a5f4-a244ea6844c0@hiroshima-u.ac.jp> Dear Eiso, Please let me ask a few questions on "cabp" feature. 1) The name "cabp" looks wide, general, but GB/Z 40637-2011 might have more limited context. As the proposed description states, GB/Z 40637 is a subset of GB 18030-2011, 14250 characters, a repertoire selected for the typesetting of ancient Chinese books. To avoid the confusion by the variants of the source separated or cognate characters, GB/Z 40637 chosen a representativeb one from the cognate character groups. For example, "?" (sourced from GB 2312) is included, but "?" or "?" (tagged GE source, introduced for the compatibility with ISO/IEC 10646) are not included. "?" is chosen, but "?" is not. The characters not listed in GB/Z 40637-2011 should be untouched by the cabp feature? If so (cabp should not change the characters not listed in GB/Z 40637), how about the stability of the character set of GB/Z 40637? Is there any possibility to extend it to cover the unlisted and non-cognate characters? If there is a possibility, the name "cabp" is slightly too generic, having some suffix to specify the version number would be safer. 2) Is there any documentation about the glyph design policy of GB/Z 40637? Taking a glance on the glyphs in GB/Z 40637, some glyphs have clear difference from the G-column glyphs in ISO/IEC 10646 (like "?" and "++", described in the proposal - ?, ?, ?, ?/?, ? ...), but there are many glyphs which I cannot find clear differences between G-column glyphs in ISO/IEC 10646 versus the glyphs in GB/Z 40637, like, ?, ?, ?, ?, ?, ?, etc etc. You may wonder "what is the problem with that? similar situations are found for jp78, jp83, jp90, hojo and jp04, there are no JIS documentation describing the glyph difference of them". It is true, but these features were designed by Adobe, for Adobe-Japan1 glyph set. Although they are not the parts of 14496-22, Adobe published detailed info which CID is designed for which feature, like: https://raw.githubusercontent.com/adobe-type-tools/Adobe-Japan1/master/aj17-kanji.txt The developers can, but don't have to compare the JIS code charts by themselves to select glyphs to be differentiated. I think it was very helpful for the developers. I hope similar list, or, a document describing the policies "how to change GB 18030-savvy glyphs to conform GB/Z 40637-savvy". Is it possible? Regards, mpsuzuki On 2024/02/26 9:38, ??? via mpeg-otspec 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 > > [c5f6] From vladimir.levantovsky at gmail.com Tue Mar 26 21:50:44 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Tue, 26 Mar 2024 16:50:44 -0400 Subject: [MPEG-OTSPEC] Tentative agenda topics for the AHG meeting on March 19 In-Reply-To: References: Message-ID: Dear all, As a follow up to my previous email, the intent of this message is to confirm that we will have another AHG Zoom call on April 9, 2024 at 14:00 UTC (7am US Pacific / 10 am US Eastern / 16:00 Central EU / 11 pm Japan). I am in the process of finalizing the agenda topics with the primary goal of reviewing final draft submissions for the upcoming SC29/WG3 meeting to be held on April 22-26, which are based on the documents we already discussed during prior AHG meetings in February and March. We will also discuss the issue that was raised at the last AHG meeting by Peter Constable in response to my comments on the WD text related to versioning of the ConditionSet table and related changes introduced in the most recent revision of the Working Draft (subclause 6.2.9). Please submit any additional proposed agenda topics in response to this email. and please send the links to updated draft submissions text (if any) for inclusion in the meeting agenda. Due to public access to the email list archive, the meeting link information will not be shared on this email list and will be sent directly to all meeting participants. If you have not been a participant at any of the previous meetings and would like to be included on this meeting invite - please respond to me directly. Thank you, Vladimir On Tue, Mar 19, 2024 at 12:36?PM Vladimir Levantovsky < vladimir.levantovsky at gmail.com> wrote: > Dear all, > > This is just a quick update on the results of the AHG meeting today. > We had a packed agenda and ran out of meeting time before we could discuss > all scheduled topics. We decided to schedule an additional time this week > to discuss the remaining topics - the additional follow-up call is > scheduled on Thursday, March 21st at 14:00 UTC (same time of day as today's > meeting). > > We also plan to have another AHG Zoom call scheduled for April 9 to > discuss any and all remaining issues and still have time to finalize the > input submissions for the next SC29/WG3 meeting, which will be held on > April 22-26. > > The input submission deadlines for the next WG meeting are as follows: > - April 15: deadline for registration of input contributions; > - April 17: upload deadline for registered input contributions. > > Thanks again to all participants for your valuable contributions to this > work! > Vladimir > > > On Thu, Mar 7, 2024 at 3:13?PM Vladimir Levantovsky < > vladimir.levantovsky at gmail.com> wrote: > >> Dear all, >> >> Based on the results of the previous meeting and the discussions >> conducted on the AHG email list ( >> https://lists.aau.at/pipermail/mpeg-otspec/2024-February/thread.html), I >> have the following tentative agenda for our next meeting: >> >> 1. Review relevant updates / follow-up on the results and outcome of the >> previous AHG meeting (see >> https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003289.html for >> details & resolutions summary). >> 2. New GSUB features proposal: 'cabp' and 'hypy' (see the link to the >> draft proposal and the discussion thread at >> https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003301.html). >> 3. Proposed revisions to 'palt' and 'kern' documentation (see >> https://github.com/jcitpc/CJKFont/blob/main/docs/palt_kern.md and the >> discussion thread at >> https://lists.aau.at/pipermail/mpeg-otspec/2024-February/003292.html). >> 4. Clarifying / defining DMAP behavior (see >> https://github.com/harfbuzz/boring-expansion-spec/issues/138). >> 5. Updates to VARC table description (see >> https://github.com/harfbuzz/boring-expansion-spec/issues/137) >> >> Please review the proposed agenda items and let me know if I missed >> anything. Please also note that as a result of the AHG meeting discussion >> (on Feb. 20) we identified a number of proposals that need further >> clarifications and updates - please share your updated proposals for review >> prior to the meeting. >> >> I plan to have a final meeting agenda distributed early next week (no >> later than Tuesday, March 12) along with the Zoom meeting info for >> participants. All prior participants will be added to the meeting invite >> and will receive a direct email. If you have not been a participant in the >> prior meetings and would like to be added to the invite list - please >> contact me directly. >> >> Thank you, >> Vladimir >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconstable at microsoft.com Sat Mar 30 18:04:28 2024 From: pconstable at microsoft.com (Peter Constable) Date: Sat, 30 Mar 2024 17:04:28 +0000 Subject: [MPEG-OTSPEC] format field names Message-ID: I'd like to hear other's opinions: While preparing revisions for OpenType 1.9.1 and proposed revisions to OFF 5th Edn WD, I noticed in sections for OT Layout tables that some tables that have a format field have a field name that reflects the table it is contained in. * GPOS lookup subtables: "posFormat" * GSUB lookup subtables: "substFormat" * Coverage tables: "coverageFormat" * CaretValue tables: "caretValueFormat" * Anchor tables: "anchorFormat" * BaseCoord tables: "baseCoordFormat" This convention isn't followed elsewhere in the spec: * not in CFF / CFF2 FontDICTSelect * not in cmap subtables * not in COLR Paint, ClipList or ClipBox tables * not in DSIG SignatureRecord * not in ItemVariationStore or in DeltaSetIndexMap tables I'm inclined to rename fields like "posFormat" to simply "format", and have started to implement that in draft content for OT 1.9.1. But this is nothing more than wanting consistency-it's not as though having redundant info in the field names creates confusion. Anyone with a strong opinion for making these field name changes, or for _not_ making these changes? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at tiro.ca Sun Mar 31 22:32:58 2024 From: john at tiro.ca (John Hudson) Date: Sun, 31 Mar 2024 13:32:58 -0700 Subject: [MPEG-OTSPEC] format field names In-Reply-To: References: Message-ID: <83663d34-4352-4884-b27d-db4a15608adc@tiro.ca> Might it be helpful for searching in documentation, and perhaps for some kinds of discussions, to have the field names be specific rather than general? J. On 2024-03-30 10:04 am, Peter Constable via mpeg-otspec wrote: > > I?d like to hear other?s opinions: > > While preparing revisions for OpenType 1.9.1 and proposed revisions to > OFF 5^th Edn WD, I noticed in sections for OT Layout tables that some > tables that have a format field have a field name that reflects the > table it is contained in. > > * GPOS lookup subtables: ?posFormat? > * GSUB lookup subtables: ?substFormat? > * Coverage tables: ?coverageFormat? > * CaretValue tables: ?caretValueFormat? > * Anchor tables: ?anchorFormat? > * BaseCoord tables: ?baseCoordFormat? > > This convention isn?t followed elsewhere in the spec: > > * not in CFF / CFF2 FontDICTSelect > * not in cmap subtables > * not in COLR Paint, ClipList or ClipBox tables > * not in DSIG SignatureRecord > * not in ItemVariationStore or in DeltaSetIndexMap tables > > I?m inclined to rename fields like ?posFormat? to simply ?format?, and > have started to implement that in draft content for OT 1.9.1 > . > But this is nothing more than wanting consistency?it?s not as though > having redundant info in the field names creates confusion. > > Anyone with a strong opinion for making these field name changes, or > for _/not/_ making these changes? > > Peter > > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec -- John Hudson Tiro Typeworks Ltdwww.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. -------------- next part -------------- An HTML attachment was scrubbed... URL: