>> If I understand correctly, "Source Han Serif TW" is one of
>> "Region-specific Subset OTFs". They are subset fonts, so CID !=
>> GID.
>>
>> "Language-specific OTFs" (e.g. "Source Han Serif TC") are not subset
>> fonts, so CID==GID. I think these non-subset fonts would be fine.
>
> Maybe your analysis is correct. However, I've just tried
> 'NotoSerifJP-Regular.otf' – it is this font that gets packaged by many
> GNU/Linux distributions, and not its sibling
> 'NotoSerifCJKjp-Regular.otf' –, and I get exactly the same problem.
> Since this is quite a popular font we have a serious issue that should
> be fixed.
Masamichi-san,
do you think this can be solved within LilyPond? Otherwise I could
add a service to FreeType so that function `cff_charset_cid_to_gindex`
(in FreeType's file `src/cff/cffload.c`) gets a public API...[*]
Werner
[*] Without an API we would have to access internal fields of
FreeType's `FT_Face` structure: The following chain
`FT_Face` cast to `TT_Face`
`TT_Face->extra.data` cast to `CFF_Font`
is necessary so that we can eventually get
glyph_index = CFF_Font->charset->cids[cid_index]
Veeery ugly, and tied to non-public FreeType data :-) I don't
think that this could be solved in a portable way.
