Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did
Le 08/11/2022 à 06:59, Jeff Olson a écrit : Excellent! Thank you three times for your examples and patient explanations! So part of the trick is discovering which lilypond font-name to specify in order to embed the desired font in lilypond's postscript. My target is /Helvetica-Bold in postscript, and the wikipedia article on Ghostscript indicates that "Nimbus Sans L" is the proper substitute for Helvetica. So I followed your pattern and used font-name "Nimbus Sans L", but (surprise 1) the generated postscript font was /TeXGyreHeros-Regular. The Hello World output looked like Helvetica but was not bold, so I specified \bold "abcxyz", but (surprise 2) that didn't change abcxyz to bold and still used font /TeXGyreHeros-Regular. So font-name "Nimbus Sans L" does not appear to have a bold type? Similar thing (surprise 3) with font-name "Nimbus Sans": adding \bold had no effect on abcxyz and the postscript font was still /NimbusSans-Regular. Here's the code I used: \markup \override #'(font-name . "Nimbus Sans") \abs-fontsize #20 \bold "abcxyz" Not knowing how to guess the right font-name, I removed the override and just did \sans \bold: \markup \abs-fontsize #20 \sans \bold "ABCDEFG#b in ly \sans \bold" That of course produced output in sans bold and the postscript font it embedded was /NimbusSans-Bold. I guess surprise 4 is that lilypond knows about postscript font /NimbusSans-Bold but won't generate it when \bold is specified with font-name "Nimbus Sans". As a check, removing the \bold and doing just \sans does indeed revert to /NimbusSans-Regular (no surprise). So I can get my postscript to run with /NimbusSans-Bold instead of /Helvetica-Bold. I just have to let lilypond pick the specific font family for abcxyz based on the generic family. It works, but I'd feel more confident if I knew the right font-name to cause /NimbusSans-Bold to be loaded. Am I still doing something wrong? (wouldn't be a surprise) Surprise (1) is because, as far as I can see, LilyPond does not ship with the variant "Nimbus Sans L". In the output of "lilypond -dshow-available-fonts", only "Nimbus Mono PS (Regular/Italic/Bold/BoldItalic)" and "Nimbus Sans (Regular/Italic/Bold/BoldItalic)". Surprises (2)-(4) happen because font-name is meant to be a sledgehammer that overrides all font selection logic. In particular, it makes \bold and \italic have no effect. You have to use font-style instead. By the way, what are you using PostScript code for more precisely? It is not possible for you to switch to regular markup? (If it's lots of paths, for example, that could be partly automated.) Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did
On 11/7/2022 12:02 AM, Jean Abou Samra wrote:
\version "2.23.80"
\markup {
\postscript "
/NimbusSans-Regular findfont
4 scalefont setfont
(Hello, World!) show
"
}
\markup
\override #'(font-name . "Nimbus Sans")
\translate #'(100 . 0)
"abcxyz"
...
N.B. The way I found "NimbusSans-Regular" was by running
LilyPond with --ps and looking at the generated PostScript
code (search for BeginResource in it).
Excellent! Thank you three times for your examples and patient
explanations!
So part of the trick is discovering which lilypond font-name to specify
in order to embed the desired font in lilypond's postscript.
My target is /Helvetica-Bold in postscript, and the wikipedia article on
Ghostscript indicates that "Nimbus Sans L" is the proper substitute for
Helvetica. So I followed your pattern and used font-name "Nimbus Sans
L", but (surprise 1) the generated postscript font was
/TeXGyreHeros-Regular. The Hello World output looked like Helvetica
but was not bold, so I specified \bold "abcxyz", but (surprise 2) that
didn't change abcxyz to bold and still used font /TeXGyreHeros-Regular.
So font-name "Nimbus Sans L" does not appear to have a bold type?
Similar thing (surprise 3) with font-name "Nimbus Sans": adding \bold
had no effect on abcxyz and the postscript font was still
/NimbusSans-Regular. Here's the code I used:
\markup
\override #'(font-name . "Nimbus Sans")
\abs-fontsize #20
\bold
"abcxyz"
Not knowing how to guess the right font-name, I removed the override and
just did \sans \bold:
\markup
\abs-fontsize #20
\sans \bold
"ABCDEFG#b in ly \sans \bold"
That of course produced output in sans bold and the postscript font it
embedded was /NimbusSans-Bold. I guess surprise 4 is that lilypond
knows about postscript font /NimbusSans-Bold but won't generate it when
\bold is specified with font-name "Nimbus Sans".
As a check, removing the \bold and doing just \sans does indeed revert
to /NimbusSans-Regular (no surprise).
So I can get my postscript to run with /NimbusSans-Bold instead of
/Helvetica-Bold. I just have to let lilypond pick the specific font
family for abcxyz based on the generic family. It works, but I'd feel
more confident if I knew the right font-name to cause /NimbusSans-Bold
to be loaded.
Am I still doing something wrong? (wouldn't be a surprise)
Jeff
Re: Lilypond 2.22.1 fails with GitHub Actions
Le 08/11/2022 à 01:12, Vít Novotný a écrit : On Mon, Nov 07, 2022 at 09:20:24PM +0100, Jean Abou Samra wrote: Le 07/11/2022 à 20:59, Vít Novotný a écrit : Furthermore, the error message indicates that this issue might related to Ghostscript rather than Lilypond. It does not. The message is warning: g_spawn_sync failed (0): gs: Failed to close file descriptor for child process (Operation not permitted) fatal error: cannot rename `document-tmp-2786319.384671.pdf' to `document.pdf' The warning (g_spawn_sync blabla) is emitted by LilyPond due to an error in GhostScript. The second line, the fatal error, is also emitted by LilyPond and has absolutely nothing to do with GhostScript. If Ghostscript is supposed to create `document-tmp-2786319.384671.pdf` and fails, then Lilypond's `rename()` will naturally also fail, because `document-tmp-2786319.384671.pdf` does not exist. Therefore, even though the final error message originates from Lilypond, the primary source of the issue would be Ghostscript. Ah yes, that's right judging from the --verbose log output I got at some point: Invoking `gs -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH -dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-2672114'... warning: g_spawn_sync failed (0): gs: Failed to close file descriptor for child process (Operation not permitted) The invocation of GhostScript normally starts like this: GPL Ghostscript 9.56.1 (2022-04-04) Copyright (C) 2022 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. So it sounds like GhostScript doesn't even start. In any case, the GitHub people gave an answer, which is to use --security-opt seccomp=unconfined for the Docker container, in order to disable sandboxing. https://github.com/orgs/community/discussions/38510#discussioncomment-4081353 Therefore it is likely that the seccomp sandbox somehow disables something with subprocesses or the exact way LilyPond does them for GhostScript. It would be neat if Lilypond could check the exit code of Ghostscript and fail earlier, but that seems difficult to do if you are sticking to ANSI C with its `system()` call that is quite oblivious to exit codes and the like. As you can see from the error message, this call is using g_spawn_sync from GLib. Emitting a warning and not an error looks intentional to me. LilyPond tries to follow through in error conditions as much as it can. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Lilypond 2.22.1 fails with GitHub Actions
On Mon, Nov 07, 2022 at 09:20:24PM +0100, Jean Abou Samra wrote: > Le 07/11/2022 à 20:59, Vít Novotný a écrit : > > Furthermore, the error message indicates that this issue might related > > to Ghostscript rather than Lilypond. > > It does not. The message is > > warning: g_spawn_sync failed (0): gs: Failed to close file descriptor for > child process (Operation not permitted) > fatal error: cannot rename `document-tmp-2786319.384671.pdf' to > `document.pdf' > > The warning (g_spawn_sync blabla) is emitted by LilyPond > due to an error in GhostScript. The second line, the fatal > error, is also emitted by LilyPond and has absolutely nothing > to do with GhostScript. If Ghostscript is supposed to create `document-tmp-2786319.384671.pdf` and fails, then Lilypond's `rename()` will naturally also fail, because `document-tmp-2786319.384671.pdf` does not exist. Therefore, even though the final error message originates from Lilypond, the primary source of the issue would be Ghostscript. It would be neat if Lilypond could check the exit code of Ghostscript and fail earlier, but that seems difficult to do if you are sticking to ANSI C with its `system()` call that is quite oblivious to exit codes and the like. Best, Vit signature.asc Description: PGP signature
Change clef too close to the chord after it
Hi everyone.
I'm stuck on trying to move a change clef grob horizontally. I have a
piece where the change clef is too close to the chord that comes after
it. I've attached a small source file that demonstrates the problem.
If the markup is removed in the source file, the problem goes away.
I realize this may be an X Y problem so I'm open to all solutions.
--
Knute Snortum
\version "2.23.80"
rightHand = { \repeat unfold 16 { c'16 } }
leftHand = \relative {
% Remove the markup and all is well
\clef bass g,8\noBeam^\markup \large \italic "leggierissimo"
\clef treble 8 q2.
}
\paper {
ragged-right = ##f
}
<<
\new Staff \rightHand
\new Staff \leftHand
>>
Re: Unexpected file name in EPS output
Am 07.11.2022 um 23:04 schrieb Federico Bruni: Ooops, the EPS backend creates the whole file plus one file per page. $ lilypond --eps myfile.ly Would one not expect this since eps creates single pages? -- GPG Fingerabdruck: C76F A02E D525 7409 BEGIN:VCARD VERSION:4.0 N:Dr. Kleine;Bernhard;;; EMAIL;PREF=1:bernhard.kle...@gmx.net TEL;VALUE=TEXT:0049 160 998831 ADR:;;Steinbühlweg 1;Lenzkirch;;D-79853; NOTE:Ich mache auf mein Buch "670 Falterarten im Hochschwarzwald" aufwerksa m (aktuell vergriffen). END:VCARD
Re: Unexpected file name in EPS output
Il giorno dom 6 nov 2022 alle 21:17:38 +0100, Federico Bruni
ha scritto:
$ diff myfile-1.eps myfile.eps
I don't know why two files are created, but it seems they are
identical.
Ooops, the EPS backend creates the whole file plus one file per page.
$ cat myfile.ly
\version "2.22.2"
\relative c'' {
c d e c
\pageBreak
b c b e
}
$ lilypond --eps myfile.ly
GNU LilyPond 2.23.80 (running Guile 2.2)
Processing `myfile.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 or 2 pages...
Drawing systems...
Layout output to `myfile.eps'...
Layout output to `myfile-1.eps'...
Layout output to `myfile-2.eps'...
Success: compilation successfully completed
Re: Lilypond 2.22.1 fails with GitHub Actions
I'm going to ask about this at GitHub support for actions. https://github.com/orgs/community/discussions/38510 OpenPGP_signature Description: OpenPGP digital signature
Re: Lilypond 2.22.1 fails with GitHub Actions
Le 07/11/2022 à 21:20, Jean Abou Samra a écrit : Le 07/11/2022 à 20:59, Vít Novotný a écrit : This indicates that there is some issue with GitHub Actions. N.B. Also, it works with the official LilyPond binaries, as I demonstrated on the GitLab issue. It fails wih the Ubuntu package. I tried with Fedora 37 instead of Ubuntu. It fails in the same way: https://github.com/Jean-Abou-Samra/lilypond-github-actions-example/actions/runs/3414021720/jobs/5681426420 Official binaries still work, the distro package still fails. I'm going to ask about this at GitHub support for actions. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Lilypond 2.22.1 fails with GitHub Actions
Le 07/11/2022 à 20:59, Vít Novotný a écrit :
This indicates that there is some issue with GitHub Actions.
N.B. Also, it works with the official LilyPond binaries, as I
demonstrated on the GitLab issue. It fails wih the Ubuntu package.
Furthermore, the error message indicates that this issue might related
to Ghostscript rather than Lilypond.
It does not. The message is
warning: g_spawn_sync failed (0): gs: Failed to close file descriptor
for child process (Operation not permitted)
fatal error: cannot rename `document-tmp-2786319.384671.pdf' to
`document.pdf'
The warning (g_spawn_sync blabla) is emitted by LilyPond
due to an error in GhostScript. The second line, the fatal
error, is also emitted by LilyPond and has absolutely nothing
to do with GhostScript. The part of the code that produces
this message in LilyPond is
if (!rename_file (oldname_s.c_str (), newname_s.c_str ()))
{
error (_f ("cannot rename `%s' to `%s'", oldname_s.c_str (),
newname_s.c_str ()));
}
where rename_file is defined as
bool
rename_file (const char *oldname, const char *newname)
{
#if !defined (__MINGW32__)
return rename (oldname, newname) == 0;
#else
[...]
}
i.e., other than in our Windows cross-builds via MinGW, it just
use the plain old C rename function. There is little that can
go wrong here, so this really must be a problem with permissions
in the environment, I don't see how LilyPond can possibly do
anything wrong here ...
Best,
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Lilypond 2.22.1 fails with GitHub Actions
Continuous integration can be used to prepare complex documents
including sheet music. GitHub Actions is a proprietary continuous
integration service that provides free plans for public projects.
However, Lilypond seems to fail with GitHub Actions.
At https://github.com/witiko/lilypond-github-actions-example, I have
created a minimal working example of GitHub Actions failing to compile
an example Lilypond score. Here are the files from my example:
### document.ly
\score {
\relative c' {
\time 4/4
\clef treble
c4 d8 e f8 g a b | c4 b8 a g8 f e d |
c8 g' e g c,8 g' e g | c,4 e c r \bar "|."
}
}
### .github/workflows/main.yml
name: Typeset document
on:
push:
pull_request:
workflow_dispatch:
env:
DEBIAN_FRONTEND: noninteractive
jobs:
typeset-document:
name: Typeset document
runs-on: ubuntu-latest
container:
image: ubuntu:latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Install Lilypond
run: |
set -e
apt-get -qy update
apt-get -qy install --no-install-recommends lilypond
- name: Typeset score
run: lilypond document.ly
GitHub Actions produces the following error [1] in the last step
of `.github/workflows/main.yml` (the `lilypond document.ly` command):
Processing `document.ly'
Parsing...
document.ly:1: warning: no \version statement found, please add
\version "2.22.1"
for future compatibility
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `document.pdf'...
warning: g_spawn_sync failed (0): gs: Failed to close file
descriptor for child process
(Operation not permitted)
fatal error: cannot rename `document-tmp-2786319.384671.pdf' to
`document.pdf'
Do you have any idea what could cause this? Running the following
command locally compiles the example score just fine:
$ docker run --rm -it -v "$PWD":/mnt -w /mnt ubuntu:latest
# apt-get -qy update
# apt-get -qy install --no-install-recommends lilypond
# lilypond document.ly
This indicates that there is some issue with GitHub Actions.
Furthermore, removing `container: {image: ubuntu:latest}` from the file
`.github/workflows/main.yml` also makes GitHub Actions succeed in
compiling the score. [2] This indicates that the issue is specifically
with the way GitHub Actions runs Docker containers.
An extended discussion of this issue is available in the issue tracker
of an upstream project (LyLuatex) [3], where I first reported the issue
before discovering that we can reproduce the issue with just Lilypond.
Some discussion also took place in the GitLab repository of Lilypond [4],
but mostly I was told to ask here rather than at GitLab.
I understand that due to the proprietary nature of GitHub Actions, the
amount of digging is inherently limited. I am interested in whether this
is a known issue with a known workaround. Furthermore, the error message
indicates that this issue might related to Ghostscript rather than
Lilypond. Therefore, I will also appreciate any pointers, which would
allow me to make the example that demonstrates the failure tinier before
I run out of time and interest and report the issue to the GitHub people.
[1]:
https://github.com/witiko/lilypond-github-actions-example/actions/runs/3411927906
[2]:
https://github.com/witiko/lilypond-github-actions-example/actions/runs/3411907379
[3]: https://github.com/jperon/lyluatex/issues/295
[4]: https://gitlab.com/lilypond/lilypond/-/issues/6460
Best,
Vit
signature.asc
Description: PGP signature
Re: Unexpected file name in EPS output
On Sun 06 Nov 2022 at 23:01:44 (+0100), Carlo Stemberger wrote: > Il giorno dom 6 nov 2022 alle ore 22:17 Knute Snortum > ha scritto: > > > On Sun, Nov 6, 2022 at 12:21 PM Federico Bruni wrote: > > > > > > Il giorno dom 6 nov 2022 alle 18:54:00 +0100, Carlo Stemberger > > > > Where did you see "lilypond -dbackend=eps myfile.ly"? > > Here: > > http://lilypond.org/doc/v2.22/Documentation/usage/other-programs.it.html As I pointed out earlier, https://lists.gnu.org/archive/html/lilypond-user/2022-07/msg00131.html the backends documentation is inconsistent, and unfortunately even more so in 2.23.x, including RC 2.23.80. Cheers, David.
Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did
> On 6 Nov 2022, at 06:12, Jeff Olson wrote:
>
> This MWE works in 2.22.1 but fails in 2.23.14 (running via Frescobaldi 3.1.1
> on up-to-date Windows 10):
> \version "2.22.1"
> \markup {
> \postscript #"
> /Helvetica-Bold findfont
> 4 scalefont setfont
> (Hello, World!) show
> "
> }
> In 2.22 you successfully get "Hello, World!" at top of page.
This example works in LilyPond 2.23.80 (MacPorts), on MacOS 13.0.
Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did
On 07/11/2022 07:02, Jean Abou Samra wrote: Le 07/11/2022 à 05:39, Jeff Olson a écrit : Jean, please help me understand what this implies. The above lilypond-devel thread basically ends with Harm's statement that It is no longer possible to specify fonts like above. https://lists.gnu.org/archive/html/lilypond-devel/2022-04/msg00018.html The font specification he says is "no longer possible" is exactly like my case: \postscript "/Arial-Bold findfont", so he suggests not using \postscript. And the thread he references ends with Jonas' reply about how lilypond's ghostscript is different than others: Not quite, our Ghostscript is stripped down to not include unnecessary stuff and that is not prepared for users doing stuff with \postscript. Do the above responses mean there's no way to use fonts within lilypond's \postscript feature anymore? Could it be sufficient to install the full Ghostscript and set the environment variable GS_FONTPATH to point to that Ghostscript version's font directory? (e.g. export GS_FONTPATH=/usr/share/fonts). The LilyPond Ghostscript will then search that directory. -- Timothy Lanfear, Bristol, UK.
Re: Moving a Dynamic
Hi Craig, > How do you move a dynamic down if it is colliding with a multi voiced drum > set staff bottom voice? Best if you provide a MWE (see https://lilypond.org/tiny-examples.html)! Cheers, Kieren.
Moving a Dynamic
Hi All, This is probably an easy solution, but I cannot find it. How do you move a dynamic down if it is colliding with a multi voiced drum set staff bottom voice? Craig
