Re: 2.23.11 build failure on cygwin #2

> We just released LilyPond 2.23.12 with these changes. Could you verify > that it works correctly now on Cygwin? It works on Cygwin. Thank you. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: 2.23.11 build failure on cygwin #2

> second issue building on Cygwin > > The Cygwin headers are very picky and the "-std=c++14" cause some not > standard calls to fail compilation due to the reduced scope. > > The solution is to remove the "-std=c++14" or to replace with > "-std=gnu++14" This fix also contained in the following m

Re: 2.23.11 build failure on cygwin #1

> Le 13/08/2022 à 22:30, Marco Atzeri a écrit : >> Dear Developers, >> >> I am the Cygwin package maintainer for Lilypond and Guile >> latest 2.22.2 builds without issue. >> >> On the first tentative to build/package 2.23.x for Cygwin I hit two >> different problems so I will report them separately

Re: Mistranslation in Japanese documentation?

>> On 4 May 2022, at 20:43, Jean Abou Samra wrote: >> >> Le 03/05/2022 à 10:12, TamuraJun via bug-lilypond a écrit : >>> Hello, >>> >>> There seems to be a little mistranslation in Japanese documentation. >>> >>> In https://lilypond.org/doc/v2.23/Documentation/notation/bars#bar-numbers >>>

Re: Mistranslation in Japanese documentation?

alogs have been covered. > I haven’t made much progress since December but hope to continue it once my > “day job" gets less hectic. > > Best regards, > > Jun > >> 2022/05/05 15:44、Masamichi Hosoda のメール: >> >> Hi, >> >> Thank you for poin

Re: Mistranslation in Japanese documentation?

Hi, Thank you for pointing out the mistranslation. I speak Japanese and have experience submitting merge requests. If you are interested in contributing to LilyPond, you are welcome to submit a merge request, even if it takes some time. If not, I can submit a merge request. > Hi, Jean, > > Thank

Re: Garbage copied from PDF when using certain fonts

>> In my experiment, Cairo without LilyPond does not generate garbled >> characters. It seems to be a LilyPond issue instead of a Cairo >> issue. Here's a python-cairo sample that works fine. [...] > > I can conform that this small script generates a PDF where > copy-and-paste works as expected

Re: Garbage copied from PDF when using certain fonts

The problem does not appear if the cairo backend is used, see https://gitlab.com/lilypond/lilypond/-/merge_requests/853. >>> >>> This is good news! >> >> When copying and pasting from a PDF generated using cairo backend, >> some characters turned into similar but different characters.

Re: Garbage copied from PDF when using certain fonts

>>> When using certain fonts (in my case, Noto CJK, both pan-CJK and >>> subset versions), the output looks right but when copied from the >>> generated PDF file, everything becomes garbage. [...] >> >> The problem does not appear if the cairo backend is used, see >> https://gitlab.com/lilypond/li

Re: Garbage copied from PDF when using certain fonts

>> When using certain fonts (in my case, Noto CJK, both pan-CJK and >> subset versions), the output looks right but when copied from the >> generated PDF file, everything becomes garbage. [...] > > Confirmed. > >> It seems to be all about CID. Maybe related to Issue #6058? > > Yes and no. The

Re: Compilation error, due to changes in pango

> The question is now what exactly causes this: > > error: invalid conversion from 'gpointer' {aka 'void*'} > to 'FT_Face' {aka 'FT_FaceRec_*'} > > during the lilypond compilation? Is this really caused by pango? Or > is this a glib issue? Could you investigate? Pango 1.44 seems to

Re: PDF docs for 2.19.82 broken/missing fonts

Thank you for your logs. If I understand correctly, the time when the intermediate PDF (missing fonts) exist is extremely short. e.g. `input/regression/lilypond-book/suffix-tely.pdf` in lilypond-doc.log L1186 : texi2pdf (intermeidate PDF suffix-tely.pdf is generated) L1187 : extr

Re: PDF docs for 2.19.82 broken/missing fonts

> - Original Message - > From: "Knut Petersen" > >> Yes. notation.pdf looks as if extractpdfmark/gs was not used. But the >> part of the build log Phil published clearly proves that >> extractpdfmark and ghostscript were used. > >> @Phil: If you have a look at the notation.pdf in the bu

Re: PDF docs for 2.19.82 broken/missing fonts

> > Masamichi-san? Any idea? > > Knut Petersen writes: > >> This problems seems to be related to >> https://codereview.appspot.com/314130043/ >> >> The file http://lilypond.org/doc/v2.19/Documentation/notation.pdf seems to >> be  the intermediate version of notation.pdf. >> pdfinfo shows: >>

Re: GUI show messy unreadable code

> Thanks for your patch,it work.Simplified Chinese menu is display normally. Thank you for your report. I've send pull request for LilyPad. https://github.com/gperciva/lilypad/pull/11 After it is merged, I'll create LilyPad source tarball and pull reqest for GUB. ___

Re: GUI show messy unreadable code

>> Yes, it means Simplified Chinese.Thanks for your help!But Ver.2.19.65-1 is >> broken either. > > I prepared Simplified Chinese environment > (Japanese Windows 10 + Simplified Chinese Language Pack). > It reproduced in the environment. > > I've created Issue 5177. > https://sourceforge.net/p/te

Re: GUI show messy unreadable code

> Yes, it means Simplified Chinese.Thanks for your help!But Ver.2.19.65-1 is > broken either. I prepared Simplified Chinese environment (Japanese Windows 10 + Simplified Chinese Language Pack). It reproduced in the environment. I've created Issue 5177. https://sourceforge.net/p/testlilyissues/iss

Re: GUI show messy unreadable code

> OS Language 中文(简体，中国) > OS Installer Language 中文(简体，中国) If I understand correctly, it means Simplified Chinese. Correct? Most people in bug-lilypond@gnu.org cannot understand CJK letters. Anyway, old LilyPad (LilyPond editor for Windows) has an issue that is CJK strings are broken. https://so

Re: bugs in web.pdf

> If I understand correctly, there are two different problems. > > The former one is that XeTeX does not support `/Rotate`. > It occurs in both your environment and the GUB environment. > [...snip...] > > But, the former one seems to be difficult to solve. I've created the patch to solve the fo

Re: bugs in web.pdf

> No, it's not packaged for Fedora. > Should I install it from source? > https://github.com/trueroad/extractpdfmark No. I've found out the difference between your environment and the GUB environment. Thank you. If I understand correctly, there are two different problems. The former one is that X

Re: bugs in web.pdf

>> What's interesting is that my locally compiled web.pdf (with Xetex >> version 2017.03.30:1237) displays page 10 almost correctly, in that >> the page stays A4 vertical but the image is rotated 90° >> counter-clockwise. See attached the extracted page. >> web.pdf on lilypond.org was built with a

Re: bugs in web.pdf

>> - PDF page 10 is in landscape (while the document is a regular A4 of >> - course) >> > > This is the actual bug. I've investigated... > If you replace v2.19 with previous versions you can see that previous > builds used PdfTex instead of Xetex and the image was compressed to > fit on the verti

Re: Problem with make website

> After a period of processing, I got this error: > > BSTINPUTS=/home/graham/lilypond/lilypond-git//Documentation/web \ > python /home/graham/lilypond/trusted-scripts/bib2texi.py -s web \ > -s /home/graham/lilypond/lilypond-git//Documentation/lily-bib \ > -o out-website/others-did.itexi \ > -q \ >

Re: Coloring broken in Lily 2.19.51? (PNG alpha-transparency coloring is broken)

>> If master is ok, but not the released version, it's more likely a >> GUB-problem as David suspected. >> Maybe Masimichi-San can could say more, cc-ed. > > Between LilyPond 2.19.50 and 2.19.51, > Ghostscript bundled with the binary distributed on lilypond.org > has been updated. > > 2.19.50 has

Re: Coloring broken in Lily 2.19.51? (PNG alpha-transparency coloring is broken)

> If master is ok, but not the released version, it's more likely a > GUB-problem as David suspected. > Maybe Masimichi-San can could say more, cc-ed. Between LilyPond 2.19.50 and 2.19.51, Ghostscript bundled with the binary distributed on lilypond.org has been updated. 2.19.50 has Ghostscript 9.

Re: Lilypond taking forever to typeset

>>> I wonder if fc-cache became more "nosy", trying to extract more data >>> from fonts than it did in the past or if it's just my perception (or >>> perhaps my computer became slower :). >> >> Probably the former. Perhaps it helps if you try the latest >> fontconfig release, 2.12.0 – I think I sa

Re: Lilypond taking forever to typeset

>> Also it might be interesting where it happens. Perhaps run it under a >> debugger, give it a C-c during its long delay and then take a look at >> the resulting backtrace to see where LilyPond is when the delay happens? > > The main problem is: I need an idea of where to start looking for the >

Re: Lilypond taking forever to typeset

> I've noticed this one-time startup delay as well on Windows (7 and 8) and > found that it got triggered anytime I changed the contents of the system > font folder (C:\Windows\Fonts), whether adding or deleting a file. At the > next time of compiling a LilyPond file, a new font-cache database woul

Re: Header fonts

> That's a rather bad problem. We usually have a two-week schedule of > developer releases. When you find a really bad regression like that, it > makes sense to indicate its urgency and decide between > > a) revert the patch causing the problem, and then create a new patch > reintroducing the ch

Re: Header fonts

> Fonts for the header fields are not set correctly for the second and > subsequent books in a file. > > Pre-built version 2.19.45, 64-bit Linux. It will be fixed by Issue 4918. https://sourceforge.net/p/testlilyissues/issues/4918/ ___ bug-lilypond mai

Re: Ghostscript crashes on Japanese characters on Ubuntu 16.04

[...snip...] > After deleting the the noto font (rm -r > /usr/share/fonts/opentype/noto/), everything works fine. > > The font noto was not part of ubuntu Desktop 14.04 64 Bit, I've checked > that. > > I have no idea, what might be wrong with this font, ghostscript or > lilypond. However, deletin

Re: Install confirmation test file misleading

>> Sorry, I should be more precise. >> It appears that the process of dragging the test file over the LP icon >> is >> not working for me. Despite the shortcut path being correct. The >> install is >> fine. >> >> > > Which version of Windows? This drag-n-drop feature was originally > documented by

Re: PNG output cannot be created with Mac OS X version of Lilipond 2.18.2-1

I not familiar with OSX. Maybe the gs that is contained in lilypond-2.18.2 for OSX has an issue. https://lists.gnu.org/archive/html/bug-lilypond/2015-11/msg00045.html If I understand correctly, development version has been fixed the issue. Would you try lilypond-2.19.35? > Hi Andrew, > > I’ve r

Re: lilypond-book: "external" fonts and --pdf option problem

>> Thank you for finding this. I'm wondering if there is a more generic way to >> identify third-party fonts rather than hard-coding it like this? Perhaps by >> checking if the font has the LILY, LILC, and LILF subtables? I'm just >> brain-storming... > > How about following patch? > > In the cas

Re: lilypond-book: "external" fonts and --pdf option problem

> Thank you for finding this. I'm wondering if there is a more generic way to > identify third-party fonts rather than hard-coding it like this? Perhaps by > checking if the font has the LILY, LILC, and LILF subtables? I'm just > brain-storming... How about following patch? In the case of text fo

Re: lilypond-book: "external" fonts and --pdf option problem

Hi If I understand correctly, the cause is lilypond's `-dgs-load-fonts' option with non-emmentaler music font. I've reproduced the issue with the following smaller example. ``` $ cat foobar.ly { c'' } \paper { #(define fonts (set-global-fonts #:music "improviso" )) } $ lilypond -d

Re: Cannot locate libffi.so.6 on openSUSE Leap 42.1

>> The downloadable version of lilypond 2.19.32 will not run on openSUSE Leap >> 42.1 as it is unable to find libffi.so.6, which is not installed on this OS. >> >> The lilypond distribution includes this shared library in its usr/lib64 >> directory. But the installer script only creates a lilypo

Re: Cannot locate libffi.so.6 on openSUSE Leap 42.1

> The downloadable version of lilypond 2.19.32 will not run on openSUSE Leap > 42.1 as it is unable to find libffi.so.6, which is not installed on this OS. > > The lilypond distribution includes this shared library in its usr/lib64 > directory. But the installer script only creates a lilypond wr

Re: strange result for escaping "\" with other font-name

Second, your 2.19.26's fontconfig configure files do not seem to have substitute settings. >>> >>> It's not clear to me why this happens. Is it a LilyPond-problem or >>> something at my part? >>> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX

Re: strange result for escaping "\" with other font-name

>> Second, your 2.19.26's fontconfig configure files >> do not seem to have substitute settings. > > It's not clear to me why this happens. Is it a LilyPond-problem or > something at my part? > With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX > T

Re: strange result for escaping "\" with other font-name

Second, your 2.19.26's fontconfig configure files do not seem to have substitute settings. >>> >>> It's not clear to me why this happens. Is it a LilyPond-problem or >>> something at my part? >>> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX >>> Trying with a b

Re: strange result for escaping "\" with other font-name

>> Second, your 2.19.26's fontconfig configure files >> do not seem to have substitute settings. > > It's not clear to me why this happens. Is it a LilyPond-problem or > something at my part? > With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX > Trying with a build from mast

Re: strange result for escaping "\" with other font-name

Second, your 2.19.26's fontconfig configure files do not seem to have substitute settings. >>> >>> It's not clear to me why this happens. Is it a LilyPond-problem or >>> something at my part? >>> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX >>> Trying with a build from master, lilyDev (3

Re: strange result for escaping "\" with other font-name

>> >>> >> > trying to escape "\" in a string leads to strange results, for some >> >>> >> > font-names. >> >>> >> > Example below was ok with 2.18.2 >> >>> >> > >> >>> >> > \version "2.19.26" >> >>> >> > >> >>> >> > \markup \override #'(font-name . "Times New Roman") "\\<==what?" >> >>> >> >> >>> >

Re: strange result for escaping "\" with other font-name

>>> trying to escape "\" in a string leads to strange results, for some >>> font-names. >>> Example below was ok with 2.18.2 >>> >>> \version "2.19.26" >>> >>> \markup \override #'(font-name . "Times New Roman") "\\<==what?" >> The displayed font is definitely not `T

Re: strange result for escaping "\" with other font-name

>> trying to escape "\" in a string leads to strange results, for some >> font-names. >> Example below was ok with 2.18.2 >> >> \version "2.19.26" >> >> \markup \override #'(font-name . "Times New Roman") "\\<==what?" > The displayed font is definitely not `Times New

Re: strange result for escaping "\" with other font-name

>>> >> > trying to escape "\" in a string leads to strange results, for some >>> >> > font-names. >>> >> > Example below was ok with 2.18.2 >>> >> > >>> >> > \version "2.19.26" >>> >> > >>> >> > \markup \override #'(font-name . "Times New Roman") "\\<==what?" >>> >> >>> >> The displayed font is def

Re: strange result for escaping "\" with other font-name

On 2015年9月4日 17:51:16 JST, Thomas Morley wrote: >2015-09-04 7:57 GMT+02:00 Werner LEMBERG : > >> > trying to escape "\" in a string leads to strange results, for some >> > font-names. >> > Example below was ok with 2.18.2 >> > >> > \version "2.19.26" >> > >> > \markup \override #'(font-name . "Tim

Re: lilypond does not compile: fontforge version not detected

> hi, > > this patch fixes the issue. fontforge is now detected and configure > script finishes without issue. > > thanks. > > Dne 22.8.2015 v 14:25 Masamichi HOSODA napsal(a): >>> i attempted to install lilypond- gentoo ebuild but it fails because it >

Re: lilypond does not compile: fontforge version not detected

10:14 CEST 19-Aug-2015 > libfontforge 20150819 > > > it apparently catches git hash instead of the date version. Would you try the attached patch? It is necessary `./autogen.sh' before `./configure'. >From a0f236e881b4b52088cc51bcd52049c44e42387c Mon Sep 17 00:00:00

Re: Good news for Fedora 22 users (fwd)

> Hi, > > I just updated fontconfig from 2.11.93 to version-2.11.94 (now in > updates-testing) on Fedora 22 > > $ sudo dnf update --enablerepo=*testing update fontconfig* > > And a quick test shows Lilypond started working again :-) Thank you for your information. I'm glad to hear it. LilyPond

Re: lilypond 2.19.20 on fedora gs bug

> The Fedora 22 package fails for everyone, the www.lilypond.org version > works. > > I tried this minimal example: > > % f22test.ly > \version "2.19.21" > {c'} > > And then did > > $ lilypond --ps --verbose f22.ly &> f22test1.txt > $ ps2pdf14 f22test.ps f22test.pdf &> f22test2.txt > > results

Re: lilypond 2.19.20 on fedora gs bug

> % can't compile anything due to gs error > % warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 > -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH > -r1200 -sDEVICE=pdfwrite -sOutputFile=./n.pdf -c.setpdfwrite -fn.ps)' failed > (256) > % gs command itself gives Error: /unde

Re: my favorite bug :-)

>>> The bug would be fixed if lilypond would make ghostscript use a >>> complete path to the intermediate lines.ps file for the ps to pdf >>> conversion. >> Does anyone know how to convert from any path (relative and absolute >> path) >> to absolute path in scheme (guile) ? > > Maybe the functions

Re: my favorite bug :-)

>>> There is a big difference: If you compile a .c file, the .o files >>> stays by default; the compiler doesn't remove it. >> >> Uh, wrong? >> >> cd /tmp;echo "main(){return 0;}" >gega.c;gcc -o gega gega.c;ls gega* >> gega gega.c > > I've meant using option `-c' of the compiler. BTW, if you s

Re: my favorite bug :-)

>> The bug would be fixed if lilypond would make ghostscript use a >> complete path to the intermediate lines.ps file for the ps to pdf >> conversion. > > Does anyone know how to convert from any path (relative and absolute path) > to absolute path in scheme (guile) ? When the following command i

Re: my favorite bug :-)

> The bug would be fixed if lilypond would make ghostscript use a > complete path to the intermediate lines.ps file for the ps to pdf > conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? _

Re: my favorite bug :-) (fwd)

> Did you know it is not possible/allowed to name a lilypond file > "align.ly" or "lines.ly"? On my Fedora system I can find all the names > that suffer from this bug by typing > > #ls /usr/share/ghostscript/9.15/lib/*.ps > > all these filenames (minus .ps) can not be used as lilypond inputfiles

Re: Ghostscript problem in 2.19.18

>> How do you install lilypond-2.19.18-1.linux-x86.sh? > > I execute the script as user to install it to ~/lilypond (with the > wrappers in ~/bin). > Then (and that's maybe where the problem starts) I move the ~/lilypond > folder to the location on /shared and create a symlink at ~/lilypond. > Thi

Re: Ghostscript problem in 2.19.18

> OK. > > Compiling a file with lilypond-2.19.18-1.linux-x86.sh ends with > > Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 > -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH > -r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite > -fdocument.ps'... > > >

Re: Ghostscript problem in 2.19.18

> gs: Interpreter revision (905) does not match gs_init.ps revision > (915). lilypond-2.19.18-1.linux-x86.sh includes gs-9.15. However, lilypond seems to be invoking the external gs-9.05 instead of included gs-9.15. My ubuntu 64 bit environment have been installed gs-9.10. However, lilypond invok

Re: Ghostscript problem in 2.19.18

> I have just installed lilypond-2.19.18-1.linux-x86.sh on another > machine running Debian 7 stable with latest updates. And the error is > identical. Maybe (this is a big maybe) I'll have a chance to test it > on another (different) 32bit Linux installation later today, but > that's not sure at a

Re: Ghostscript problem in 2.19.18

> This is on Debian with the linux-386 binary and applies to _any_ file, > even > { c } > . > > Compiling with the 2.19.17 binary works. > Compiling with the 2.19.18 binary fails. > Compiling with a custom build from current master works. > > As there are no relevant commits between the 2.19.18 t

Re: [PATCH] Fix unset PATH crash

> On 2015-03-01 02:07 AM, Masamichi HOSODA wrote: >> On Windows, lilypond crashes when the environment variable PATH is not >> set. >> >> ``` >> C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin>set PATH= >> >> C:\tmp\lilypond-2.19.16-0.mingw\$

[PATCH] Fix unset PATH crash

this issue is a possible crash. A patch file is attached. >From 68e233c11b3eeaad0ee442a4b3a47e206ebc70e0 Mon Sep 17 00:00:00 2001 From: Masamichi Hosoda Date: Sun, 1 Mar 2015 17:44:54 +0900 Subject: [PATCH] Fix unset PATH crash When the environment variable PATH is not set, getenv ("PATH"

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

>> I've received your log file. >> >> The log file includes following messages. >> >> ``` >> configure: error: in >> `/home/gub/NewGub/gub/target/linux-x86/build/cross/gcc-core-4.9.2/i686-linux/libgcc': >> configure: error: cannot compute suffix of object files: cannot >> compile >> See `config.log

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

> Thanks for your continuing help. I get this (the logfile is again > coming directly to you): > > bin/gub tools::gawk > calculating dependencies > *** Stage: download (gawk, tools) > downloading http://ftp.gnu.org/pub/gnu/gawk/gawk-3.1.6.tar.gz -> > /home/gub/NewGub/gub/downloads/gawk/ > ...

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

> Zipped, it's a 500k file, so I'm sending it to Masamichi privately. I've received it. Thank you. Maybe, there is no gawk in your system. I've installed gawk to ubuntu by the following command. $ sudo apt-get install gawk Would you try the following commands? $ bin/gub tools::gawk $ bin/gub l

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

> I'm now getting an error shown in > target/linux-x86/log/cross/gcc-core.log: > > config.status: creating Makefile > config.status: creating testsuite/Makefile > config.status: creating config.h > config.status: executing default commands > Command barfed: cd > /home/gub/NewGub/gub/target/linux-x

Re: time-signature-single-digit.ly andtime-signature-single-digit.ly don't have \version

> I've just had a look at your branch on: > https://github.com/trueroad/gub/network > > That's an impressive set of patches over six months of hard work. > > Congratulations! And many thanks for moving this on! Thank you for your congratulation. ___

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

> I've cloned this git repo and swapped to the gcc-4.9.2 branch and run > make bootstrap. This is on Ubuntu 14.04 32 bit running in a virtual > machine. I get an error as follows: > > Output from make: > > building package: tools::p7zip > *** Stage: download (p7zip, tools) > *** Stage: untar (p

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

> I'd not bother then. 2.19.16 is a developer release, so it is not > required that it works for every platform. Before stable releases, we > try our best to get things to work according on the feedback we get for > developer releases. > > The whole point of GUB is that most developers don't nee

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

> No need to wait: as I said, I already pushed the fix myself. Next time, > it would be nice if you provided a patch by calling "git format-patch". > That way, we get your commit message as well and the patch is pretty > sure to apply (using "git am" instead of "git apply") and you have less > tro

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

> Please submit git-formatted patches (including commit message) if > possible. > > I pushed a fix to staging but could not make use of your patch. I'll try it in this weekend. Please wait few days. > Are you actually working on GUB currently? We are obviously having some > problems getting 2.19

time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

Hi In lilypond current master branch, I found that input/regression/time-signature-numbered.ly and input/regression/time-signature-single-digit.ly files don't have ``\version''. http://git.savannah.gnu.org/gitweb/? p=lilypond.git;a=commitdiff;h=8298bc08d2d6398af3b1c988b825ad36d355e7ee Then, GUB'