[MPEG-OTSPEC] [EXTERNAL] Re: Two GSUB Proposals for OFF: 'cabp' and 'hypy'

Sat Mar 2 06:48:22 CET 2024

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 <behdad at behdad.org> 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 <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 <htl10 at users.sourceforge.net> 
> Sent: Friday, March 1, 2024 3:01 PM
> To: Peter Constable <pconstable at microsoft.com>; 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 <mpeg-otspec-bounces at lists.aau.at> on behalf of Hin-Tak Leung via mpeg-otspec <mpeg-otspec at lists.aau.at>
> > Date: Thursday, February 29, 2024 at 3:56 PM
> > To: mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>, suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp>
> > Cc: Eiso CHAN <eisoch at 126.com>
> > 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 <mpeg-otspec at lists.aau.at> wrote:
> >  For those who want to read the source material, it seems that the canonical sources for GBZ 40637 might 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 <mpeg-otspec at lists.aau.at> wrote:
> >  Dear Eiso, Fuji-san,
> >  I checked 現代漢語拼音方案2012 available at
> >  http://edu.shandong.gov.cn/attach/0/b72295c44ff442c8b333a481f524dbe9.pdf
> >  I guess, the glyphs you want to care might be:
> >  "a" in "ai" (哀), "uan" (弯), "Van" (冤) in 韻母表
> > "g" in "ang" (昂), "eng" (亨的韵母), "ieng" (英), "ueng" (翁), "veng" (雍) in 韻母表
> >  Am I understanding correctly?
> >  漢語拼音方案1958 (I'm unsure the source of this scanned image):
> >  http://www.moe.gov.cn/ewebeditor/uploadfile/2015/03/02/20150302165814246.pdf
> >  there is no clear distinction of the typeface for "a" & "g".
> >  A distinction of "a" is mentioned in the 四、声調符号, special "a" is used for 軽声,
> > maybe it would be the update introduced in 2012.
> >  But yet I'm unsure about the background to distinguish "g".
> >  Regards,
> > mpsuzuki
> >  On 2024/02/29 22:28, 陈永聪 via mpeg-otspec wrote:
> > > Fuji-San,
> > > > Thank you for your comments. The most official materials for Hanyu Pinyin forms are 汉语拼音方案and 现代汉语词典.
> > > > Eiso
> > > ---- Replied Message ----
> > >  From    Takaaki Fuji 藤 貴亮<tfuji at morisawa.co.jp><mailto:tfuji at morisawa.co.jp>
> > > Date    02/29/2024 下午6:45
> > > To      陈永聪 <eisoch at 126.com><mailto:eisoch at 126.com>
> > > Cc      mpeg-otspec <mpeg-otspec at lists.aau.at><mailto:mpeg-otspec at lists.aau.at>
> > > Subject Re: [MPEG-OTSPEC] Two GSUB Proposals for OFF: 'cabp' and 'hypy'
> > > Dear Eiso,
> > > > I'm just curious, but for ‘hypy’, is there any good source I can look at for the ‘official' glyph forms of Hanyu Pinyin?
> > > > If I understand the issue correctly, ‘hypy’ is not only about the Futura-like one-story a/g shown in Example, but also the tone marks are preferred to have a 'reverse-modulation’; while an acute is always stroked from top to bottom as a Latin accent, as a Pinyin mark it goes upwards from left to right to illustrate the second/rising tone. I imagine this conflict/divergence has long been such an issue in a dual-script situation, so switching between the two via GSUB sounds like a great improvement to me!
> > > > Thank you,
> > > > Takaaki Fuji
> > > >> On Feb 26, 2024, at 9:38, 陈永聪 via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> > >> >> This is my first proposal for OFF. Please see http://cloud.caaph.com:10121/f/fed7bd2e3d/
> > >> I suggest adding two GSUB features. 'cabp' is used to support GB/Z 40637—2021, 'hypy' is used to support the special glyphs forms used for Hanyu Pinyin.
> > >> >> If you have any suggestions or feedbacks, please let me know.
> > >> >> Regards,
> > >> Eiso_______________________________________________
> > >> mpeg-otspec mailing list
> > >> mpeg-otspec at lists.aau.at
> > >> https://lists.aau.at/mailman/listinfo/mpeg-otspec
> > > _______________________________________________
> > mpeg-otspec mailing list
> > mpeg-otspec at lists.aau.at
> > https://lists.aau.at/mailman/listinfo/mpeg-otspec
> 
> > _______________________________________________
> > mpeg-otspec mailing list
> > mpeg-otspec at lists.aau.at
> > https://lists.aau.at/mailman/listinfo/mpeg-otspec
> > _______________________________________________
> > 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