|
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").
Your're right. (I had thought Frescobaldi also garbles the filename, but I was wrong.)(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...
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! Lukas
[Prev in Thread] | Current Thread | [Next in Thread] |