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

[dak]

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


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