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

[dak]

Why are we still navigating the bleeding edge?  LilyPond is more than 20
years old.

On 2017/09/25 16:38:16, knupero wrote:
> > > --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 see.  Still using -dgs-never-embed-fonts _without_ --use-encodings
seems like the most unusual combination, so I'd prefer if one had to
explicitly switch encodings _off_ rather than _on_.

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

As long as they were large, that would seem representative.  I was
hoping for less.

> But the code paths are old and proven, we should keep both.

Well, I wasn't suggesting otherwise, at least in the short term.  But
it seemed like putting the glyphshow way behind an explicit option
would have had benefits for making the default PDF files more
versatile.

This is all more murky than I like.

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

Depends on how much.  10-20% would make a difference, I'm just not
sure enough for a complaint.  And we would retain the option
--final-pdf (or whatever) for making them with the old size.

> > > 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 the main excuse.  And it wasn't better before we came up with
the --bigpdf scheme.

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

I think you could still override such a requirement with

GS=/usr/bin/gs ./configure ...

or similar so I am somewhat sympathetic to that.

Sigh.

Why can't anything be easy?


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