Confirmed with 2.19.29 and 2.19.30 on MacOs Yosemite and Windows 8.1. Linux does not have the problem.
$ echo '\version "2.18.0" {a}' | lilypond -dbackend=svg -dsvg-woff -o foo -
Processing -'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output tofoo.svg'...
Success: compilation successfully completed
$ echo '\version "2.18.0" {\time 2/4 a}' | lilypond -dbackend=svg -dsvg-woff -o foo -
Processing -'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output tofoo.svg'.../Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/output-svg.scm:448:16: While evaluating arguments to ly:paper-get-font in expression (ly:paper-get-font paper (quasiquote #)):
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/output-svg.scm:448:16: Unbound variable: paper
Also it affects more than just time signature glyphs:
dynamics:
$ echo '\version "2.18.0" {a\p}' | lilypond -dbackend=svg -dsvg-woff -o foo -
...
Layout output to `foo.svg'.../Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/output-svg.scm:448:16: While evaluating arguments to ly:paper-get-font in expression (ly:paper-get-font paper (quasiquote #)):
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/output-svg.scm:448:16: Unbound variable: paper
Thanks,
Ophir
The respective code was introduced in
commit 15eceefc16218ef60042259bb3878a52101d7d55
Author: Jan Nieuwenhuizen janneke@gnu.org
Date: Tue Jun 1 14:31:20 2010 +0200
and I have a hard time believing that it ever worked. However, I would have expected things to crash on all platforms and with a different error message so I clearly am missing something here.
What does "works under Linux" mean? With our own crosscompiled version and installer? If so, does this use the same GUILE version as the others? May this be some 64bit/32bit difference?
David Asked:
"What does "works under Linux" mean? With our own crosscompiled version and installer?"
Simply that I don't get any warning or error message, just the 'normal' messages that happen when you compile successfully. Under Windows I get identical messages as MacOSX.
I tested this using the installer from the download - so I guess the Guile versions are 'included' with whatever GUB does when it packages the installer files?
James
Both when compiling from source and with the package, I'm getting this error under a Ubuntu VM. This is not limited to OSs.
It never worked, David. When bypassing
fontby usingpango-fontinfont-glyph-name-to-charcode, the charcode is incorrect. (e.g. "one" ->Ȱ (U+0230)).glyph-stringis wholy separate fromfont-metric, but should get not just the font-name but also the metric object. What might be done is to completely mergenamed-glyphandglyph-string, but that's a huge undertaking. This is a serious bug though in my view.Last edit: Étienne Beaulé 2017-09-01
Diff:
Here's an example for
\version "2.18.0" {\time 1/4 a\p}. If the list fromnamed-glyphs(output-ps.scm) is exhaustive, this bug affects all but the following glyphs:Following the example, only the clef and notehead were unaffected.
Ubuntu 16.04 LTS - current master I get the same error if it helps
Yeah, issue [#1118] seems to have been half-done and marked as fixed. A fix for this could be to integrate the font inside the SVG file, like what is done for PDFs, but SVG Fonts are basically deprecated. Sadly I don't have the knowledge to fix this (I'd be interested in a mentor if possible), but as another way to possibly fix this, it would be to replace the font-name by a font-metric. The other backends should still be able to use it (extract the name); but SVG too now.
I'd get more worried if
font-glyph-name-to-charcodereturns the wrong character even with the right font.Related
Issues:
#1118