lilypond-devel
[Top][All Lists]
Advanced

[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: dak
Subject: Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by address@hidden)
Date: Sun, 24 Sep 2017 04:03:26 -0700

On 2017/09/24 10:05:43, trueroad wrote:
On 2017/09/24 00:25:17, knupero wrote:
> > If I understand correctly, `--bigpdfs` / `-b` has two effects.
> > One is to embed full set (non-subset) font.
> > The other is to define and use some encodings for Emmentaler.
>
> It also changes the way emmentaler glyphs are printed. With
--bigpdfs we use
the
> "show" postscript operator, without it we still use "glyphshow". And
the three
> emmentaler fonts for every size in the intermediate versions of our
pdfs are
not
> 3 copies of the full emmentaler-xx font but are three different
fonts made of
> emmentaler-xx glyphs. Those subsets must not be further subsetted.

I wrote "to define and *use* the some encodings".
If I understand correctly, "glyphshow" doesn't use any encodings but
"show" uses
the encoding.
What I wrote as "use" means using "show" instead of "glyphshow".

> No, it is senseless to split -b into separate options.

Again, when both `-dgs-never-embed-fonts` and `--bigpdfs`/`-b` are
used at the
same time, the intermediate PDFs become larger.
The disk size that `make doc` eats becomes increased.

If spliting -b, `-dgs-never-embed-fonts -duse-notation-font-encodings`
doesn't
embed full set TrueType fonts.
It embeds subset for TrueType fonts, as with only using
`-dgs-never-embed-fonts`.
The intermediate PDFs don't become larger.
The disk size that `make doc` eats doesn't become increased.
Nevertheless, the encodings for notation font is defined and "show" is
used.
In my humble opinion, this is better than `-dgs-never-embed-fonts -b`.

Of course, if we do not have to worry about the increase in disk size
required,
splitting -b is senseless as you wrote.

In my opinion, -b/--bigpdf should be simple to use for
lilypond-book-like applications.  lilypond-book should likely call
lilypond using options leading to good results by default.  For
generating our own documentation, I find 3-4GB of disk space excessive:
using special additional options might be suitable if that helps.  If
the additional options work at least as well under all conceivable
circumstances, they should likely be the default.

-dxxx are options appealing more to specialists (well, there are things
like -dpreview not particularly specialist, but when in doubt, people
are more likely to see/consider "normal" options).

I'm not into the whole font mess enough to make a really qualified
suggestion here.

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



reply via email to

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