> I put the patch in the usual LilyPond form at
> https://codereview.appspot.com/191360043/
> along with links to LilyPond history and the Ghostscript discussion.
Unfortunately, this doesn't correctly include the new file
`encodingdefs.ps' – it is tagged as a `binary'...
> This helps with TeX documents having several LilyPond inclusions,
> but only after post-processing with pdfsizeopt.py.
Yes. It's unfortunate that pdfsizeopt is too picky currently to work
reliably with lilypond output.
> My first impression that we do not want this patch,
Can you explain why? As Knut writes, he wants it encapsulated with a
command line option so that it has be to explicitly activated. It
should be thus straightforward to remove the related code as soon as a
better solution becomes available.
> but might be wise to go back LilyPond's former use of encoding
> vectors, if we can avoid whatever problems induced HanWen to move to
> using glyph names in the .ps.
Indeed, encoding vector support should be implemented on a lower
level, but until someone works on this, Knut's approach seems
legitimate to me.
Werner
PS: I'm not happy with the answer from the GS people who simply say
that the use of the `glyphshow' operator is `rare' and thus not
supported well. I consider the use of `glyphshow' quite elegant
since encoding vectors with its limitation to 256 glyphs is
technology from 30 years ago...
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
