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

On 2017/09/25 22:17:41, knupero wrote:
On 2017/09/25 17:33:47, dak wrote:

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

So you are absolutely sure that enabling "show" and the use of
encodings does not break anything?

What about other notation fonts?

About three weeks ago Malte Meyn complained on lilypond-user that
"lilypond -b" failed with the Haydn font.

Remember: We used the hardcoded name "Emmentaler" at various places
for --bigpdfs, and --use-encodings still needs and uses that portion
of the old code.

Before remembering something, I need to know it in the first place.
Sounds like something we should get rid off in the long run.

I have not checked that in detail, but I believe that we need to
adapt ps/ and scm/output-ps to support other notation
fonts with --use-encodings.

Ceterum censeo: We really should stay with glyphshow as our default
for lilypond 2.20 (two-two-zero).

Well, hard to argue with that.

Nevertheless, for 2.21+ I would want to move to a different default,
so it makes sense to bikeshed the naming of the option(s) such that we
only need to flip the default at some point of time.  Scripts should
already be able to explicitly decide which side of the default they
want to end up with (and will then do so regardless of whether the
default has been flipped).

Regarding the naming of the option, I'd prefer to have something
oriented around the actual use characteristics rather than the
internal details.

Does that sound like something you can agree with?

- We even might discuss if it is wise to keep a separate svg backend
as it is easy to translate postscript to svg.

I would not want to touch this before we have Cairo in place.  The
PostScript path is inherently slower than any more direct option, so
if retiring SVG as an explicit backend would be on the slate, a
Cairo-based path would seem to make a lot more sense.

- Someone probably will propose to add ghostscript as a git
submodule to the lilypond tree and to add some patches.

I doubt we could reasonably afford the ongoing cost of even a small
fork.  So as long as we can coordinate efforts with upstream, that
seems vastly preferable.

reply via email to

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