On 2017/09/25 12:54:24, knupero wrote:
A bit more far-reaching.
As newer versions of gs - don't need the helpemmentaler functions and - don't need the real inclusion of all font data and - don't need some other details and - don't work properly with our old code we might well decide to kill --bigpdfs.
Instead of --bigpdfs this patch introduces --use-encodings
--use-encodings switches emmentaler glyph generation from "glyphshow"
to
"show"+encodings and might be combined width -dgs-never-embed-fonts.
That sounds good. It also sounds like -dgs-never-embed-fonts should imply --use-encodings, right?
With --use-encodings there is an increase in file size, but it is not
dramatic.
Nevertheless it should not be the default.
I think it really depends on what "is not dramatic" means. How is the impact on really large scores? If the percentages are comparatively small, I think we are better off making the option most amicable to further processing of PDF files the default. Users or scripts that are sure that they do not want any further processing can then use --final-pdf (or whatever) if they know that the size/speed wins have no negative side effects for them. But the default setting should be the one least likely to cause followup problems.
This patch gives a total size of 96MB for all of our documentation
pdfs on my
system if used with ghostscript git master or at least ghostscript
9.20. Also
extractpdfmark must be used.
If you use ghostscript versions below 9.20 or if extractpdfmark is not
present
on your system, the total size of the documentation is about 306 MB.
That's sort-of unpleasant but we can likely declare this temporary constellation "somebody else's problem" as long as our lilydev VM and the gub distributions are recent enough not to be affected.
du -sh build/ gives 2.6GB after a full build with this patch, 2.5GB
without it.
Disk usage during the build probably is higher.
Even if we are using -dgs-never-embed-fonts for the included files? I mean, the numbers are smaller than what I remember but still rather large.
The last stage of building the pdfs does cost a significant amount of
processing
time: generating the 306MB set of pdfs takes about 940 seconds on my
system,
generating the 96MB set of pdf takes an additional 110 seconds.
I assume that the additional time is in Ghostscript/extractpdfmark so that there is little in the way of improving LilyPond itself? https://codereview.appspot.com/325630043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
