[HarfBuzz] 'vert' substitutions in CJK fonts

[suzuki toshiya]

Hi,

Thank you for opening the interesting discussion.
I think, the script names in OpenType spec are not identical with the
block names in Unicode; "kana" does not specify the small group of katakana
and hiragana, but also specify the group including katakana, hiragana,
CJK ideographs, CJK punctuations, CJK symbols etc etc.

When I worked for poppler (PDF rendering library), I got similar problem;
http://lists.freedesktop.org/archives/poppler/2012-March/008860.html
I should note that the default language system strategy would not work
well with (old versions of?) Batang font (a Korean font bundled to Microsoft
Windows).

when vertical text is requested without embedded font, how OpenType layout
feature should be configured; I used the combinations CHN/hani for Chinese
Simplified or Traditional, JAN/kana for Japanese, KOR/hang for Korean.
But it was designed to fit the internal design of the poppler, more
comprehensive consideration would be expected for real i18n software.

Regards,
mpsuzuki

Grigori Goronzy wrote:
> Hi,
> 
> a user of my library reported that vertical alternates are not correctly
> subtituted in many CJK fonts. I am a bit puzzled by this.
> 
> When doing vertical layout of Japanese text, the 'vert' feature is
> enabled in the library to select vertical variants of some Kanji, Kana
> and punctuation characters. This works fine with many fonts, but with
> some it does not.
> 
> The GSUB table of problematic fonts typically looks a bit too...
> minimal. Here's an example, that's the "MOTOYA LMaru" font, Android's
> standard CJK font:
> 
>>   Table  0 of 16: GSUB (0x0000010c+0x0000016c)
>>     1 script(s) found in table
>>     Script  0 of  1: kana
>>       No default language system
>>       1 language system(s) found in script
>>       Language System  0 of  1: JAN 
>>         No required feature
>>         1 feature(s) found in language system
>>         Feature index  0 of  1: 0
>>     1 feature(s) found in table
>>     Feature  0 of  1: vert; 1 lookup(s)
>>         1 lookup(s) found in feature
>>         Lookup index  0 of  1: 0
>>     1 lookup(s) found in table
>>     Lookup  0 of  1: type 1, props 0x0001
> 
> So subtitutions are only used if the run that is shaped has Katakana
> (kana) script and language is set to Japanese (JAN). It works if I
> explicitly set the language and force the script to Katakana.
> 
> But, in practice, that's of course not true! First, it breaks as soon as
> the system language is not Japanese, unless the language has been
> overridden. Second, not only Katakana characters have vertical variants.
> Punctuation might or might not be substituted depending on context,
> because punctuation characters have common script and assume the script
> of characters around them. If they're next to Kanji characters, it will
> break.
> 
> Should fonts with GSUB tables like that considered broken? What does
> Uniscribe do to make this work? And lastly, can I force HarfBuzz to just
> use the first 'vert' substitution lookup in case there's none to be
> found with matching or DFLT script/language system?
> 
> Best regards
> Grigori
> _______________________________________________
> HarfBuzz mailing list
> HarfBuzz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz