[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with OTF support

From: Werner LEMBERG
Subject: Re: Problem with OTF support
Date: Thu, 22 Oct 2020 21:23:39 +0200 (CEST)

>> 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.


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...[*]


[*] 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->`  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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]