Re: Problem with OTF support

[Jonas Hahnfeld]

Am Montag, den 19.10.2020, 19:44 +0200 schrieb Werner LEMBERG:
> [lilypond dcd531b0f, gs 9.52]
> 
> Processing the following sample code
> 
>   \paper {
>     #(define fonts
>       (set-global-fonts
>        #:roman "Source Han Serif TW"
>        #:sans "sans-serif"
>        #:typewriter "monospace"
>      ))
>   }
> 
>   \markup { "ろ" }   % This is character U+308D.
> 
> causes the attached image, which is obviously wrong (inspite of the
> name, the 'TW' variant of the 'Source Han Serif' family contains
> Hiragana syllables).  Running `pdffonts` on the output PDF
> demonstrates that the right font gets used:
> 
>   UOIEOY+SourceHanSerifTW-Regular  CID Type 0C  Identity-H  yes yes no   9  0
> 
> Looking into the `--eps` output of LilyPond I see the following:
> 
>   /SourceHanSerifTW-Regular /CIDFont findresource [...]
>   2.1852 0.0000 0.0000 1277
>   1 print_glyphs
> 
> The main question is where the value 1277 comes from.
> 
> In the (OTF) font's `cmap` table, U+308D maps to glyph 'cid01536',
> which has index 1277 in the font.
> 
> However, the glyph shown in the image is U+2609, glyph 'cid01277'.
> index 1021.
> 
> If I extract the (raw) CFF file from the EPS file, glyph index 1277 is
> U+2609 (so CID numbers are one-to-one mapped to glyph indices, as
> indicated by the 'Identity-H' entry above).  The correct value should
> be – as can be guessed now – 1536.
> 
> In other words, CID values (this is, glyph indices in the raw CFF
> font) and OpenType glyph indices are mixed up.

If this is indeed a bug (not sure I understand Masamichi-san's answer
correctly), could you please open an issue at GitLab? That makes it
much easier to track, especially for backporting should the fix be
available in time and sufficiently non-risky.

Jonas

signature.asc
Description: This is a digitally signed message part