Hallo allerseits,
ich habe folgendes Problem:
\version "2.19.83"
\header { title = "Wächter"}
\book
{
\bookOutputName "Wächter"
\score {
{c d e f}
}
}
Dieses Beispiel stellt den Umlaut im Titel korrekt dar, die ausgegeben .pdf-Datei erhält aber trozdem den Namen "Wächter.pdf".
Die .ly-Datei liegt in UTF-8 vor, das wäre ja sonst der erste Lösungsweg, der vorgeschlagen wird, es ist aber bereits der Fall.
Die .log-Datei ist trotzdem weiterhin ANSI-kodiert, vielleicht ist das Teil des Problems ... ???
Wie kann ich das beheben?
Hallo,
ich kann Dein Problem nicht nachstellen.
Zum testen habe ich Deinen Code in mein aktuelles test-file (atest-93.ly) kopiert und kompiliert.
Zitat von: terminal
$ lilypond atest-93.ly
GNU LilyPond 2.19.83
Processing `atest-93.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-jHU2sb'...
Converting to `Wächter.pdf'...
Deleting `/tmp/lilypond-jHU2sb'...
Success: compilation successfully completed
Alles wie es soll.
Ich bin auf Ubuntu-18.04 64-bit
Gruß,
Harm
Hallo,
danke für die Antwort.
Ich bin auf Windows 10.
Zitat
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `./tmp-lilypond-tZ5Ntz'...
Converting to `Wächter.pdf'...
Deleting `./tmp-lilypond-tZ5Ntz'...
Success: compilation successfully completed
So sieht meine .log-Datei aus. Wenn ich die Datei einmal auf UTF-8 umstelle, dann bekomme ich zwar dasselbe Log wie du, aber wenn die Datei komplett neu erzeugt werden muss, ist die Kodierung wieder ANSI.
Und obwohl im Log klar steht:
ZitatConverting to `Wächter.pdf'...
Ist der Dateiname am Ende wieder "Wächter.pdf", was wohl daran liegt, dass intern weiter mit ANSI gearbeitet wird.
Es scheint wohl ein Windows-Problem zu sein ...
Unter Windows hatte ich immer Probleme, wenn sich ein Umlaut im Dateinamen befand.
Dieses Problem lässt sich relativ einfach vermeiden ;)
Zitat von: Manuela am Freitag, 8. November 2019, 05:16
Dieses Problem lässt sich relativ einfach vermeiden ;)
Natürlich ist mir klar, dass ich den Umlaut auch einfach weglassen könnte. :D
Aber mich hätte schon interessiert, warum Windows-Lilypond hartnäckig darauf besteht, in ANSI zu arbeiten und ob jemand eine Möglichkeit kennt, das zu beheben.
Das Problem zu umgehen ist zwar auch eine Lösung, aber keine besonders elegante.
Zumindest in Frescobaldi gibt es ja die Möglichkeit, Lilypond mit zusätzlichen Kommandozeilen-Befehlen zu starten, vielleicht ließe sich darüber etwas beeinflussen?
Hallo,
Windows mit seiner internen UTF16-Implementierung »steht auf Kriegsfuß« mit der auf UNIX-Systemem verbreiteten und im LILYPOND verwendeten UTF8-Implementierung.
Das beste ist bis heute, die Finger von den Umlauten zu lassen, wenn es um Dateinamen geht.
Das zeigt sich vor allem beim Dateinamen: Dein Beispiel ist die UTF-8-Codierung des Dateinamens, aber als Windows-Western-Zeichensatz (oder vieleicht noch als den alten DOS-Zeichensatz) interpretiert.
Unter Win7 erlebe ich es sogar große Einschränkungen bei der Prozessforschrittsanzeige bei Kommandozeilenausführung im DOS-Fenster, während es unter dem alten Windows-NT genügte, im DOS-Fenster den Zeichensatz 65001 (= UTF8) einzustellen.
Um dieses Problem in der Windows-Version von LILYPOND zu beheben, müßte in
allen Modulen eine Kompatibilitätsschicht eingebaut werden. Nur ein paar Beispiele:
- Kommandozeilen-Übergabe: UTF16-Commandline abfragen, nach UTF8 übersetzen
- Dateiaktionen (öffnen, umbenennen, Informationsabfragen) im C-Teil von LILYPOND: UTF8-Dateiname in UTF16-Dateiname umwandeln und die entsprechende »w«-Funktion verwenden
- stdout und stderr-Ausgaben im C-Teil von Lilypond: Ermittlen ob in eine Datei umgeleitet. Wenn nicht die eingestellte Codpage ermitteln und die Zeichen entsprechend kovertieren.
- Submodule, vor allem GUILE: Auch hier die ganze Kompatibilitässchicht wie für den C-Teil von Lilypond hinzufügen, am besten natürlich in den Hauptentwicklungszweig von GUILE!
Persönlich glaube ich, mit dieser Aufgabe könnte man einen Entwickler leicht einen Monat Vollzeit beschäftigen.
Arnold
Hallo Arnold,
ich bedanke mich für diese sehr ausführliche Antwort.
Jetzt ist es mir zumindest möglich, das Problem zu verstehen und ich werde die Datei in Zukunft einfach im Explorer umbennen.
Vielen Dank!
Hallo Ursus,
noch ein Nachtrag zu deiner Frage mit der BAT-Datei - wird wohl wieder etwas aufführlicher.
Ich benutze Lilypond unter Windows in der Kommandozeile.
Da Win7 im DOS-Prompt nochmal eine andere Codepage benutzt als in der graphischen Benutzerumgebung, verzichte ich ganz auf Zeichen außerhalb des 7-Bit-ASCII-Bereichs für Dateinamen.
Auch auf Leerzeichen im Dateinamen verzichte ich, damit keine Anführungszeichen in den Pfaden innerhalb der BAT-Datei zu setzen sind. Sogar mein Lilypond-Installationspfad enthält (ganz bewußt) keine Leerzeichen.
Ich benutze eine BAT-Datei um Lilypond zu starten (mit immer nur einer einzigen LY-Datei), aber auch um noch etwas drumherum einzustellen:
- Es wird ein Benutzerbibliotheksverzeichnis zusätzlich (als »-I«-Option) an lilypond übergeben.
- Des öfteren benötige ich besondere zusätzliche Kommandzeilenoptionen für die Übersetzung einer LY-Datei. Dazu wird die angegebene LY-Datei vor dem Start von Lilypond nach einer Zeile wie »%CMDLINEOPTS= --ps --pdf« durchsucht, und dann eben » --ps --pdf« auch noch als zusätzliche Option beim Lilypond-Aufruf hinzugefügt.
- Ein kleines, compiliertes C-Programm durchsucht die angegebene LY-Datei vor und nach dem Aufruf von Lilypond nach Zeilen, welche mit »%PREPROCESS:« bzw. »%POSTPROCESS:« beginnen, und führt dann die dort angegebenen Befehlszeilen aus, z. Bsp. MIDI-Datei in WAV- und MP3-Datei übersetzen, oder aus der PS-Datei ein Booklet-PDF erstellen (d.h. DIN-A4-Seiten auf DIN-A3-Seiten verteilen, damit diese nach dem Doppelseitendruck gefaltet und geheftet werden können)
- In deinem Fall wäre mit dieser Methode denkbar, daß als POST-ACTION eine Kopie der erstellten PDF-Datei in einen anderen Dateinamen durchgeführt wird. Aber, wegen der Zeichensatzproblematik, besser nicht als Kommandozeilenaufruf [»system()« in C], sondern nur als »internes Kommando«
Wenn Du einen C-Compiler zur Verfügung hast (der freie BCC32 würde meines wissens auch genügen) und Dir die Erweiterung zutraust, könnte ich die Quellcodes heraussuchen und Dir zukommen lassen. (kann aber etwas dauern!)
Arnold
Hallo Arnold,
ich bedanke mich erneut für deine Hilfe und deinen Vorschlag, aber in diesem Fall wäre es glaube ich einfacher, wenn ich einfach eines meiner bestehenden AutoHotkey-Scripte erweitere, dass nach erfolgter Kompilierung die Ausgabedatei umbenennt.
Das sollte keiner großartige Änderung bedürfen.
Trotzdem bedanke ich mich für die Hilfe.