[Top][All Lists]

[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
       #: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?


PNG image

reply via email to

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