Hi Antonio,
first of all, thanks a lot for working on this!
Regrettable during a working week I have very little time to work on a
serious issue like this one.
That said:
2016-11-14 13:13 GMT+01:00 Antonio Ospite <a...@ao2.it>:
> Hi everyone,
>
> On Mon, 14 Nov 2016 01:15:52 +0100
> David Kastrup <d...@gnu.org> wrote:
>
>> Thomas Morley <thomasmorle...@gmail.com> writes:
>>
>> > Short update:
>> > I managed to get guile 2.0.13 and guile-2.0-dev for 2.0.13 (grabed it
>> > from Zesty Zapus which will be Ubuntu 17.04)
>> > Successful make with all of Antonios patches (didn't try make doc so far).
>> >
>
> In the latest version of my notes I forgot to mention that I am using
> 2.0.13 from Debian unstable. It was in the first draft.
>
>> > Though, _every_ compilation of a .ly will cause a gs-error.
>> >
>> > Even for { c1 } I get:
>> >
>> > lilypond-git atest-40.ly
>> > GNU LilyPond 2.19.51
>> > Processing `atest-40.ly'
>> > Parsing...
>> > Interpreting music...
>> > Preprocessing graphical objects...
>> > Finding the ideal number of pages...
>> > Fitting music on 1 page...
>> > Drawing systems...
>> > Layout output to `/tmp/lilypond-6s1XBB'...
>> > Converting to `atest-40.pdf'...
>> > warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595,28
>> > -dDEVICEHEIGHTPOINTS=841,89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
>> > -r1200 -sDEVICE=pdfwrite -sOutputFile=atest-40.pdf -c.setpdfwrite
>> > -f/tmp/lilypond-6s1XBB)' failed (256)
>> >
>> > fatal error: failed files: "atest-40.ly"
>> >
>> > Will try to continue tomorrow, too late today.
>>
>> That one is going to be another (re)encoding error, this time when
>> writing PostScript. It may or may not be a different problem than the
>> ones I experienced: Masamichi-san fairly recently made some changes to
>> font handling that also were concerned with byte transparency.
To exclude recent changes by Masamichi-san I checked out
commit ff3e029f198c72d88c1c2fd2db3ce12cce86e725
Author: Phil Holmes <m...@philholmes.net>
Date: Mon Nov 7 14:11:25 2016 +0000
Release: bump VERSION.
and started freshly from there
>
> Thomas what is your locale?
~$ env|grep LANG
LANG=en_US.UTF-8
GDM_LANG=en
LANGUAGE=en
~$ env|grep LC_NUMERIC
LC_NUMERIC=de_DE.UTF-8
>
> If run lilypond with my default locale (LANG=it_IT.utf8) I get this
> error too; as I wrote somewhere, running the "gs" command on its own
> showed that in my case this was due to the EPS file containing commas
> as decimal separator instead of periods.
>
> Running lilypond like this worked around the issue for me:
>
> $ LANG=C lilypond-git atest-40.ly
>
> Does this work for you too?
> BTW setting only LC_NUMERIC instead of LANG could be enough.
I need to do both to make it work:
~/lilypondH/Test/forum$ LANG=C LC_NUMERIC=C lilypond-git atest-40.ly
GNU LilyPond 2.19.51
Processing `atest-40.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-cw8exx'...`scm_take_str' is
deprecated. Use scm_take_locale_stringn instead.
Converting to `atest-40.pdf'...
Deleting `/tmp/lilypond-cw8exx'...
Success: compilation successfully completed
(I remember you wrote about scm_take_str already)
Though, more serious:
You already wrote about stuff like
bääh = { c1 }
\new Staff \bääh
not working and suggested "A workaround is to only use ASCII
characters in macro names"
I know several users who would need to fix/rewrite most of their code
if we would go for this. But it would be considerable if really,
really nothing else is possible, imho
But this one is the current showstopper:
{ c1^\markup "büüh" }
See attached png.
Making LilyPond unusable for everyone.
Can you confirm the image?
Cheers,
Harm
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
