[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1

From: Jonas Hahnfeld
Subject: Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1
Date: Sat, 15 May 2021 16:21:30 +0200
User-agent: Evolution 3.40.1

Am Samstag, dem 15.05.2021 um 16:05 +0200 schrieb Lukas-Fabian Moser:
> Hi Jonas,
> Am 14.05.21 um 21:59 schrieb Jonas Hahnfeld:
> > Am Freitag, dem 14.05.2021 um 20:35 +0200 schrieb Lukas-Fabian Moser:
> > > I just remembered that I have another encoding problem with LilyPond,
> > > namely special characters in \bootOutputSuffix lead to replacement
> > > characters __ in the name of the generated file. Which means I should
> > > investigate the encoding used in my file system after all.
> > Is that with all LilyPond versions, including the "old" Guile 1.8?
> > You may also try a shell script calling "locale" to see what
> > environment you actually get when compiling a score from Frescobaldi...
> That was the crucial idea. Thanks!
> Found it now: If you enable "Run LilyPond with English messages" in 
> Frescobaldi ("LilyPond mit Englischen Meldungen starten") - which I had, 
> although I don't remember why -, it does (cf. 
> frescobaldi_app/job/
>              self.environment['LANG'] = 'C'
>              self.environment['LC_ALL'] = 'C'
> This doesn't disturb Guile1.8-LilyPond:

(for finding the input file, but it does influence the output suffix;
probably because then things get mixed?)

> [...]
> So I guess Frescobaldi's way of forcing LilyPond to display English 
> messages (just force LANG and LC_ALL to C) has unintended side-effects 
> for pathnames that somehow were partly masked before by some conversion 
> magic that no longer happens with Guile2-LilyPond.

Yes, that makes a lot of sense: Guile2 internally knows about encoding,
so we need to "convert" the input filename from the "locale" encoding.
For Guile 1.8, the binary data is just passed on and most things are
fine. We could of course guess that the encoding of filenames is UTF-8,
but IIRC that isn't always true on Windows so we have to expect that
the locale encoding matches what is used to encode the input filenames.

I think Frescobaldi should be able to just set LANG=en_US.UTF-8, right?
Which then assumes that filenames are in fact UTF-8, so maybe breaks
some other cases? Umm...


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]