I have not yet used LilyPond with TeX, so I have no opinion.
I looked up the history: Use of PostScript glyphshow, rather than show, for all characters seems to have started with http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=c3d6497157576dc0d4ae77c44978d54e7a212074 after some discussion at http://lists.gnu.org/archive/html/lilypond-devel/2004-10/msg00150.html 1 The Ghostscript maintainer explains that for purposes of creating a PDF, ghostscript emulates glyphshow by collecting the glyphshow-ed glyphs into a font with an encoding : http://bugs.ghostscript.com/show_bug.cgi?id=695728 When several segments of Lilypond output are merged into one PDF, several of these fonts created on-the-fly take up space in the output file. https://codereview.appspot.com/194090043/diff/20001/ps/encodingdefs.ps File ps/encodingdefs.ps (right): https://codereview.appspot.com/194090043/diff/20001/ps/encodingdefs.ps#newcode8 ps/encodingdefs.ps:8: /LilyNoteHeadEncoding [ This is a little different from "FetaNoteheadsEncoding" in 'mf/out/feta-noteheads11.enc' generated by 'scripts/build/mf-to-table.py' https://codereview.appspot.com/194090043/diff/20001/ps/encodingdefs.ps#newcode108 ps/encodingdefs.ps:108: /noteheads.d0doFunk {<01> show} def I suppose you use PS definitions here because the Scheme code does not know the encoding table, so the Scheme does not know what number to write in '\?? show' https://codereview.appspot.com/194090043/diff/20001/scm/output-ps.scm File scm/output-ps.scm (right): https://codereview.appspot.com/194090043/diff/20001/scm/output-ps.scm#newcode64 scm/output-ps.scm:64: (ly:inexact->string i 8))) This is the old code that output PS 'show' rather than 'glyphshow' https://codereview.appspot.com/194090043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
