[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problem with OTF support
From: |
Werner LEMBERG |
Subject: |
Problem with OTF support |
Date: |
Mon, 19 Oct 2020 19:44:59 +0200 (CEST) |
[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. Masamichi-san, do you
have a quick fix for this?
Werner
- Problem with OTF support,
Werner LEMBERG <=
Re: Problem with OTF support, Jonas Hahnfeld, 2020/10/20