Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by address@hidden)

[knupero]

> > --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?

No. There are legitimate uses for both standalone -dgs-never-embed-fonts
and --use-encodings.

> 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.

All scores tested here (only a few) increased about 10% to 20% in size.
But the code paths are old and proven, we should keep both.

> 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.

I believe that the ordinary user of lilypond does one score at a time
without further processing. And Fred Foobar probably would complain if
his old scores grow bigger with 2.20.

> > 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.

At least they are not broken ;-)

> 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.

Nobody who builds lilypond documentation should use a ghostscript old
than 9.20. As pointed out by Masamichi, GoToR links are not processed
correctly by all older versions of ghostscript. Of course, as not all
pdf readers process them correctly, a lot of people would not see that
problem. Some examples: okular does not process them at all, evince
handles them correctly (but fails on link types not used by our
documentation), and mupdf handles them incorrectly (but correctly
implements other links that are broken by evince bugs).

If I would know that 9.20+ is available on every system supported by
lilypond I would advocate to make that version a build requirement.

> 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.

Yes. Even with -dgs-never-embed-fonts.

> I assume that the additional time is in Ghostscript/extractpdfmark so
that there
> is little in the way of improving LilyPond itself?

I think you are right with that assumption.

https://codereview.appspot.com/325630043/