[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by addr

From: knupero
Subject: Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by address@hidden)
Date: Mon, 25 Sep 2017 09:38:16 -0700

> --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
--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
"somebody else's problem" as long as our lilydev VM and the gub
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]