lilypond-devel
[Top][All Lists]
Advanced

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

two failing files during `make doc'


From: Werner LEMBERG
Subject: two failing files during `make doc'
Date: Thu, 30 Apr 2009 08:57:53 +0200 (CEST)

Folks,


the files

  lily-50e2bfee.ly
  lily-7d242e8d.ly

fail to be properly built during `make doc'.  Using gs 8.64, I get
messages like

  Substituting .notdef for glyphIndex11C in the font IPAGothic

while converting the EPS.  Older gs versions like 8.62 abort with an
error, BTW.  Reason is that lilypond accesses the Japanese IPAGothic
font with artificial glyph names of the form `glyphIndexXXX' since the
original TrueType font (ipag.ttf) doesn't contain glyph names in its
`post' table -- virtually all CJK fonts miss that.  If lilypond embeds
the font itself in the EPS, it properly constructs the input code ->
glyph index mapping table.  However, loading the font with

  (/usr/share/fonts/truetype/ipag.ttf) (r) file .loadfont

doesn't do this.

Is there someone out here who has sufficient PS experience and
knowledge of ghostscript to write some code which fixes this?  A few
months ago I asked on the gs-devel list how a TTF can be accessed by
glyph indices within gs, and I got this answer, which isn't very
helpful for me, unfortunately:

  You should load it as [a] CID font with specifying it in
  gs/Resource/Init/cidfmap .  Then you can access glyphs by char codes
  in `cmap'.  As to accessing by glyph indices, Ghostscript library
  doesn't provide that, but it may be done with a small development in
  Postscript.

Note that access by character codes is *not* a possibility since we
received the glyph indices by the Pango library which does the layout
for text objects within lilypond.

A quick fix is to handle those two files specially, explicitly
activating font embedding while lilypond processes the files.


    Werner




reply via email to

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