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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
