spanBar broken in 2.17.13?
with 2.17.13 the snippet http://lsr.dsi.unimi.it/LSR/Item?id=686 doesn't draw bars between staves anymore (2.17.12 still works) - are there any known chages? Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/spanBar-broken-in-2-17-13-tp141458.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
Le 25/02/2013 02:18, Thomas Morley a écrit : 2013/2/24 yvand yvand.sw...@gmail.com: Le 24/02/2013 19:03, james a écrit : the problem here is not in lilypond, nor in the file, exactly. The problem is the character encoding. (You can look up character encoding on wikipedia if you really want to know more about it.) More to the point: the best way to help solve your problem would be to know which program you use to create the lilypond file and then find out how to enable utf-8 by default in the program. I don't understand, Well, we're discussing two problems a) We can't trust in our encoding while communicating via mail or looking up the the archives. That's horrible. b) The problem you reported. James gave you some good advice. the problem only occurs with this character and with this version of lilypond ! (using the title Lettre à Élise) I use gedit to write lilypond files, the files are encoded in utf8. I doubt. To test under nearly the same conditions I installed 2.16.2, wrote (not copied) the example and compiled it. No problem. Are you _really_ sure about your utf8 encoding? How do you test it? -Harm Hi, Thank you for helping me. I tried to write the minimal code from scratch in nano, gedit, geany but the problem is still there! I downgraded lilypond package to 2.12.3 version and it works with the *exactly* the same file! I don't think this is an encoding problem! To avoid encoding problem with mails, I hosted the file here : http://lucd.legtux.org/test.zip Can you test : 1) The PDF is damaged 2) If you compile the lilypond file (with version 2.16.2), the PDF is still damaged gedit and `file --mime-encoding test.ly` say that the file is well encoded en utf8. A friend of me can reproduce the problem, under archlinux. -yvand ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
2013/2/25 yvand yvand.sw...@gmail.com: To avoid encoding problem with mails, I hosted the file here : http://lucd.legtux.org/test.zip Can you test : 1) The PDF is damaged The PDF is damaged. Evince 3.4.0 on debian wheezy 2) If you compile the lilypond file (with version 2.16.2), the PDF is still damaged test.ly is a proper utf-8 encoded file following emacs, the leafpad editor and the 'file' command. I have compiled it successfully with lilypond 2.17.7 and the resulting PDF is not damaged. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: spanBar broken in 2.17.13?
Eluze elu...@gmail.com writes: with 2.17.13 the snippet http://lsr.dsi.unimi.it/LSR/Item?id=686 doesn't draw bars between staves anymore (2.17.12 still works) - are there any known chages? URL:http://code.google.com/p/lilypond/issues/detail?id=3203 This one slipped through regtests (which apparently don't see barlines) and review. To quote our release news: We are happy to announce the release of LilyPond 2.17.13. This release contains the usual number of bugfixes and enhancements, and contains some work in progress. You will have access to the very latest features, but some may be incomplete, and you may encounter bugs and crashes. If you require a stable version of Lilypond, we recommend using the 2.16 version. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
Francisco Vila paconet@gmail.com writes: 2013/2/25 yvand yvand.sw...@gmail.com: To avoid encoding problem with mails, I hosted the file here : http://lucd.legtux.org/test.zip Can you test : 1) The PDF is damaged The PDF is damaged. Evince 3.4.0 on debian wheezy 2) If you compile the lilypond file (with version 2.16.2), the PDF is still damaged test.ly is a proper utf-8 encoded file following emacs, the leafpad editor and the 'file' command. I have compiled it successfully with lilypond 2.17.7 and the resulting PDF is not damaged. I think this mainly depends on the version of Ghostscript that is being used for converting PS to PDF (used internally by LilyPond when generating PDF). The version of LilyPond, in contrast, is mostly irrelevant with respect to the problem. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
outdated German download page says MacOS X 10.7
Hi, Have a look at this discussion https://twitter.com/IngoBartling/status/305981558257512448 Can we get an update for http://www.lilypond.org/macos-x.de.html asap? Thanks, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
David Kastrup d...@gnu.org writes: Jan Nieuwenhuizen jann...@gnu.org writes: Frédéric Bron writes: It is due to a bug in ghostscript. I submitted a bug report 29th of Nov (2012) and it is now corrected. But it will take time until the new version of ghostscript comes to everybody's distribution. Do you have a patch to go with this? We could put the patch into GUB right away. LilyPond degrades its encoding ASCII-Latin1-UTF16LE for PDF metadata. Old versions of GhostScript can't deal with UTF16LE. Recent versions balk at Latin1. We could likely temporarily improve user experience by skipping the Latin1 phase. It's a bit of a gamble. Well, I've put the gamble on. Patch up at URL:http://code.google.com/p/lilypond/issues/detail?id=2985. I guess we'll have less of a chore dealing with user protests when using that. I don't think checking for this problem with autoconf would be a good idea, either: Ghostscript is just too likely to be upgraded independently of LilyPond. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Error when compiling a large file
Miguel Jesus wrote ArnoldTheresius wrote Miguel Jesus wrote I finally got the file to compile. I had to set the LILYPOND_GC_YIELD to 100. Anyone knows why it worked that way and not the default one? Anyway, it took 700 seconds to compile, which is a lot more that it took you. As you said, I only saw 1 CPU being used. Can lilypond use more than 1 CPU to make things faster? ... ___ bug-lilypond mailing list bug-lilypond@ https://lists.gnu.org/mailman/listinfo/bug-lilypond Well, I did try to compile it on Win7/64 with several different settings to LILYPOND_GC_YIELD (100, 70, 50, 35, 25, 18, 13, 9, 7, 1). All trials faild at my setup. The commited memory usage for the 32bit Lilypond process displayed in the taks manager was approx. 1.3 GB in all processes at the time they failed, which is much away from the 4 GB 32bit applications can reach under 64bit-Windows (3 GB under 32bit-Windows). I wonder, if there is a software limit for the heap in guile. ArnoldTheresius Actually, the memory usage for my file when it crashed was also 1.3 GB and there are more people reporting that value. Could that be a coincidence? I checked the windows execution flags, namely of lilypond.exe and lilypond-windows.exe. They are NOT LARGEADDRESSAWARE, thus limited to 2 GB of RAM on windows. Assuming the source code is large-address-aware, I modified this flag by using editbin from my Visual C installation. During the successfull compilation I noticed approx. 2.4 GB of commited RAM usage in the task manager. ArnoldTheresius -- View this message in context: http://lilypond.1069038.n5.nabble.com/Error-when-compiling-a-large-file-tp141107p141474.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
2013/2/25 David Kastrup d...@gnu.org: I think this mainly depends on the version of Ghostscript that is being used for converting PS to PDF (used internally by LilyPond when generating PDF). The version of LilyPond, in contrast, is mostly irrelevant with respect to the problem. OK; so if Ghostscript is embedded in lilypond, and besides I have Ghostscript installed, how could I check the embedded GS version? -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
Francisco Vila paconet@gmail.com writes: 2013/2/25 David Kastrup d...@gnu.org: I think this mainly depends on the version of Ghostscript that is being used for converting PS to PDF (used internally by LilyPond when generating PDF). The version of LilyPond, in contrast, is mostly irrelevant with respect to the problem. OK; so if Ghostscript is embedded in lilypond, and besides I have Ghostscript installed, how could I check the embedded GS version? I think that the Ghostscript version will appear in the PDF Metadata. So looking at the problematic PDF file should deliver that information. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
On Mon, 25 Feb 2013, David Kastrup wrote: Francisco Vila paconet@gmail.com writes: 2013/2/25 David Kastrup d...@gnu.org: I think this mainly depends on the version of Ghostscript that is being used for converting PS to PDF (used internally by LilyPond when generating PDF). The version of LilyPond, in contrast, is mostly irrelevant with respect to the problem. OK; so if Ghostscript is embedded in lilypond, and besides I have Ghostscript installed, how could I check the embedded GS version? Would the problem be solved - for the time being - if ghostscript would be called with parameters that would produce a PDF version 1.3 document like my experiments seem to indicate? (I called lilypond with --ps first, and then used ps2pdf13 to produce a pdf) -- MT ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
Martin Tarenskeen m.tarensk...@zonnet.nl writes: On Mon, 25 Feb 2013, David Kastrup wrote: Francisco Vila paconet@gmail.com writes: 2013/2/25 David Kastrup d...@gnu.org: I think this mainly depends on the version of Ghostscript that is being used for converting PS to PDF (used internally by LilyPond when generating PDF). The version of LilyPond, in contrast, is mostly irrelevant with respect to the problem. OK; so if Ghostscript is embedded in lilypond, and besides I have Ghostscript installed, how could I check the embedded GS version? Would the problem be solved - for the time being - if ghostscript would be called with parameters that would produce a PDF version 1.3 document like my experiments seem to indicate? (I called lilypond with --ps first, and then used ps2pdf13 to produce a pdf) I am not sure that is equivalent. The PostScript intended to be converted into PDF likely contains additional information (like the PDF Metadata). I am not sure that the PostScript produced via just --ps will actually be the same. If you bothered following the thread you'd have noticed that there is already a patch up at URL:http://code.google.com/p/lilypond/issues/detail?id=2985. I don't think that we need to do more than that. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Frescobaldi suddenly running slowly
I had no idea that there was such a list! Thank you! I assume that the list frescoba...@googlegroups.com? -- View this message in context: http://lilypond.1069038.n5.nabble.com/Frescobaldi-suddenly-running-slowly-tp141443p141486.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: à in title makes damaged pdf
It is due to a bug in ghostscript. I submitted a bug report 29th of Nov (2012) and it is now corrected. But it will take time until the new version of ghostscript comes to everybody's distribution. Do you have a patch to go with this? We could put the patch into GUB right away. Do you mean GUB recompiles ghostscript? If so, here is the patch made from the squash of ghostscript commits 3a4439baee68c440da7164daf55de04a4d48609a and a3d00daf5f9abb1209cb750a95e23bc6951c1c63. Frédéric 0001-pdfwrite-convert-non-UTF-16BE-doc-info-to-UTF-8-assu.patch Description: Binary data ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Error when compiling a large file
ArnoldTheresius arnold.we...@siemens.com wrote in message news:1361795191267-141474.p...@n5.nabble.com... Miguel Jesus wrote ArnoldTheresius wrote Miguel Jesus wrote I finally got the file to compile. I had to set the LILYPOND_GC_YIELD to 100. Anyone knows why it worked that way and not the default one? Anyway, it took 700 seconds to compile, which is a lot more that it took you. As you said, I only saw 1 CPU being used. Can lilypond use more than 1 CPU to make things faster? ... ___ bug-lilypond mailing list bug-lilypond@ https://lists.gnu.org/mailman/listinfo/bug-lilypond Well, I did try to compile it on Win7/64 with several different settings to LILYPOND_GC_YIELD (100, 70, 50, 35, 25, 18, 13, 9, 7, 1). All trials faild at my setup. The commited memory usage for the 32bit Lilypond process displayed in the taks manager was approx. 1.3 GB in all processes at the time they failed, which is much away from the 4 GB 32bit applications can reach under 64bit-Windows (3 GB under 32bit-Windows). I wonder, if there is a software limit for the heap in guile. ArnoldTheresius Actually, the memory usage for my file when it crashed was also 1.3 GB and there are more people reporting that value. Could that be a coincidence? I checked the windows execution flags, namely of lilypond.exe and lilypond-windows.exe. They are NOT LARGEADDRESSAWARE, thus limited to 2 GB of RAM on windows. Assuming the source code is large-address-aware, I modified this flag by using editbin from my Visual C installation. During the successfull compilation I noticed approx. 2.4 GB of commited RAM usage in the task manager. ArnoldTheresius That would obviously mean a change to the Windows-version compiler on GUB. I assume it's gcc but haven't checked. Any thoughts on how to proceed with this? -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
