[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: Lukas-Fabian Moser
Subject: Re: [PoC] EXPERIMENTAL binaries of LilyPond 2.22.1
Date: Fri, 14 May 2021 20:35:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

but frankly I'm surprised that plain gcc's char type and printf seem
to be able to deal with multi-byte characters. But this probably has
to do with the fact that this was my first #include "stdio.h" since
(I think) 1998, and the world has moved on...
I don't think "char *" and printf care, they just pass on the binary
data as-is. The glyph rendering is what has to deal with the encoding
in the end...

Ah, sorry. My statement was an artifact of a preliminary version where I messed up hex-char output and got 8-digit hex numbers because the unicode bytes were being interpreted as signed numbers. Now I see what you mean (and am less surprised about "modern C magic").

(Just to be sure: Are you sure you let Frescobaldi compile the actual
file and not Frescobaldi's temporary copy?)
Quite: I created the files outside of Frescobaldi and only opened and
compiled them from there. As far as I understand, Frescobaldi compiles
a temporary copy if I have unsaved modifications? At least then I get a
path in/tmp/, but the filename still has the special characters...
Your're right. (I had thought Frescobaldi also garbles the filename, but I was wrong.)

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.

Thanks for your help!

reply via email to

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