Ken Sharp <ken.sh...@artifex.com> writes: > At 07:01 22/09/2017 +0900, Masamichi Hosoda wrote: > >>If there is a full font embedded (non-subset) PDF, >>does the bigpdfs trick work effectively? > > Its still, in my opinion, a risky thing to do. However, if the font > were fully embedded, you wouldn't need to use Ghostscript and the > PDFDontUseFontObjectNum bug approach (which is the risky part).
Well, if we could delay the embedding, I'd not be particularly sad: "make doc" currently(?) eats up more than 3Gb which is sort of ridiculous. The intermediate PDFs for lilypond-book are arranged in some "database" and not really externalized, so if they don't work on their own, this isn't a showstopper. Generating the images is usually done by a limited number of LilyPond jobs (depending on the number of processors available), each of them converting hundreds of input files into corresponding PDF files. It would be conceivable to at least keep some sort of font identifier consistent in a single job. Embedding a font 10 times (for 10 graphics-generating jobs) seems at least better than embedding it hundreds of times. At any rate, any such strategy could not be implemented and tested in short time, so if in the mean time the font merging expedient would stay available for some time, it would make things a lot smoother for us. > The Font and FontDescriptor dictionaries might not be possible to > remove, so the effect wouldn't be quite as good as the current > approach, but these dictionaries run to a few tens or at most a few > hundred bytes. The FontFile streams are where most of the space is > going, and those would be possible to remove, if they were truly > duplicates. We are not really striving for "optimum" rather than "better than awful" regarding the resulting file sizes. This seems like being close enough. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel