> On 2 Jun 2026, at 18:46, Hans Aikema <[email protected]> wrote: > >> On 2 Jun 2026, at 18:43, Hans Åberg <[email protected]> wrote: >> >> >>> On 2 Jun 2026, at 18:37, Hans Aikema <[email protected]> wrote: >>> >>> Your test server sends the file as "content-type: text/x-lilypond”, without >>> a character-encoding, which means it leaves it up to the browser to decide, >>> which will then (on my browser - Firefox on Mac OS) falls back to a very >>> generic encoding…. US-ASCII >>> >>> To render as UTF-8 it should send content-type: >>> text/x-lilypond;charset=utf-8 >> >> They are sent as plain text, so they have no HTML header. > > Content-type is not a HTML header, it’s a HTTP protocol header and it is > present on Silvain’s testserver, but missing the charset indicator part of > it, making the browser render it as “some sort of plain text”, in my case by > rendering it as US-ASCII plain text, causing those reported character > corruptions when displayed in the browser.
I saw it. Possibly Safari substitutes UTF-8 because Mac never had ASCII.
