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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
