Seite 1 von 3

Und plötzlich waren die Umlaute weg

Verfasst: Mo 8. Aug 2016, 18:54
von Skysegeljack
Hallo,

heute ist mir etwas ziemlich seltsames passiert, was mich gerade ziemlich ratlos macht. Und zwar bin ich gerade an einer größeren Arbeit dran und dachte mir, dass es u.U. sinnvoll ist das bestehende Projekt in meinen Dropboxordner zu kopieren, um dort eine automatische Synchronisierung durchführen zu lassen (ich vergesse es im Eifer des Gefechts nach getaner Arbeit regelmäßig Sicherheitskopien zu erstellen). Dementsprechend arbeite ich auch an dem Projekt im Dropbox-Ordner und bisher gab es auch keine Probleme.

Heute fing ich an ein neues Kapitel zu schreiben und bekam promt den Befehl:

"command \textcurrency unavailable in encoding OT1. ..."

und er stört sich ganz klar an einem verwendeten "ä". Seltsamerweise stört er sich nicht an einem "ü", stellt dieses jedoch aber nicht korrekt dar.

Viel seltsamer ist es aber, dass dieses Problem in vorhergehenden und nachfolgenden Kapiteln nicht auftritt.

Und um die Verwirrung komplett zu machen: Füge ich denselben Text in mein ursprüngliches Projekt (in dem Nicht-Dropbox-Ordner), so kompiliert er das gesamte Projekt ohne Probleme.

Zu erwähnen ist, dass ich mit TeXStudio arbeite und sich alle Kapitel in einem Ordner "chapters" befinden. Diese binde ich dann mit einem \include-Befehl in das aktive Dokument ein. Es ist beinahe so, als würde er beim kompilieren vergessen, dass die globale .sty-Vereinbarung für dieses Kapitel gilt (widerspricht aber der Tatsache, dass selbst definierte commands ausgeführt werden).

Hat jemand diese Problem vielleicht schon einmal gesehen, oder eine Idee zur Behebung?

Vielen Dank schon einmal.

Viele Grüße

Verfasst: Mo 8. Aug 2016, 19:22
von Johannes_B
Kopiere die Datei eines anderen Kapitels und ändere ihren Inhalt.

Verfasst: Mo 8. Aug 2016, 19:34
von Skysegeljack
Super, danke! Das hat funktioniert.

Gibt es auch einen vernünftigen Grunde, warum das Sprachpaket an einer bestimmten Stelle nicht mehr beachtet wird?

Verfasst: Mo 8. Aug 2016, 19:35
von u_fischer
Das Problem haben wir schon hunderte Male gesehen. Google doch einfach mal nach "command \textcurrency unavailable in encoding OT1".

Verfasst: Mo 8. Aug 2016, 20:54
von Skysegeljack
Danke für den starken Hinweis. Meinst du nicht, dass ich das gemacht habe, BEVOR ich die Frage hier stelle?

Mir werden da Reihenweise Lösungsvorschläge angeboten \usepackage[latin1]{inputenc} durch \usepackage[utf8]{inputenc} zu ersetzen.

Verfasst: Mo 8. Aug 2016, 21:04
von Johannes_B
Und da liegt ja auch der Hund begraben. Alle Dateien haben die gleiche Kodierung, die neuen haben aber eine andere.
Kopierst du eine Datei, ist die Kodierung gleich. Du könntest auch einfach deinen Editor anpassen, dann sind neue Dateien gleich richtig kodiert.

http://texwelt.de/wissen/fragen/2656/wi ... nem-editor

Verfasst: Di 9. Aug 2016, 11:06
von u_fischer
Skysegeljack hat geschrieben:Danke für den starken Hinweis. Meinst du nicht, dass ich das gemacht habe, BEVOR ich die Frage hier stelle?
Deine Frage macht nicht den Eindruck.

Warum fragst du "Hat jemand diese Problem vielleicht schon einmal gesehen", wenn dir klar sein muss, dass es ein Allerweltsproblem ist?

Und wenn du schon auf das Thema "inputenc-Option" gestoßen bist, warum erwähnst du weder welche Option dein Dokument benützt, noch was passiert, wenn du sie änderst? Und wenn du so viele Diskussionen darüber schon durchforstet hast, ist dir da nicht aufgefallen, dass meistens nach Minimalbeispielen und genauer Fehlermeldung gefragt wird?

Verfasst: Di 9. Aug 2016, 12:12
von Skysegeljack
Johannes_B:
Danke für die Antwort. Was genau meinst du damit die Einstellung im Editor zu ändern? Bzw. ändern wozu? Mein Editor ist auf auf UTF-8-Kodierung eingestellt und das Ändern zu \usepackage[utf8]{inputenc} produziert eine viel größere Anzahl an Fehlern.


u_fischer:

Vielleicht frage ich genau aus dem Grund, da mir dies nicht klar ist, was eine direkte Folge daraus ist, dass die genannten Vorschläge nicht zu einer Verbesserung führt und sich für mich kein kausaler Zusammenhang zeigte. Vielleicht frage ich aber auch nur nach Hilfe, weil ich trotz Recherche nicht weiter komme. Aber ich habe natürlich nicht gewusst, welche Fragen man hier stellen darf und welche nicht. Das tut mir sehr Leid.

Zu deiner Bemerkung über Minimalbeispiel und Fehlermeldung:
Fehlermeldung steht doch ausführlich hingeschrieben, oder habe ich da auch Murks gemacht? Und es ist doch offensichtlich nicht einfach, ein Minimalbeispiel anzugeben, wenn man den auftretenden Fehler nicht eingrenzen kann. Ich habe keine fertigen Lösungen verlangt, es ging mir in erster Linie nur um Tips und Stichworte zur Fehlerbehebung.

Verfasst: Di 9. Aug 2016, 12:18
von Stefan Kottwitz
Willkommen im Forum, und unter Leuten, die dieselbe Frage vllt. 100mal beantwortet haben und dabei 98mal nach Details nachfragen mussten. ;-)

Wenn man auf eine leicht genervte Antwort auch gereizt reagiert, schaukelt es sich schnell hoch. Nichts persönlich nehmen im Internet, die nächste Frage vllt. besser stellen wenn möglich, und keine Skrupel haben, weitere Fragen zu stellen, es ist schließlich ein Diskussionsforum. Wenn die Frage schlecht gestellt ist, kriegt man das schon gesagt (offenbar :-) ) da muss man halt damit rechnen und man kann Infos nachliefern.

Eingangs hast Du es schon gut beschrieben. Was tatsächlich 99,99%ig alles klärt und es rückfragefrei lösen lässt, ist das Erstellen und Posten eines Minimalbeispiels. Nur als Tipp für später. In diesem Fall ist es ja nicht so einfach, da es eher um Zeichencodierung auf Betriebssystemebene geht und nicht um den Code an sich. Bei Code-Fragen ist ein Minimalbeispiel unschlagbar.

Im übrigen würde ich das Projekt wohl neu in einem anderen Ordner anlegen, Datei für Datei im Editor öffnen und als UTF-8 speichern und mit utf8 als inputenc-Option weiterarbeiten. Editor-Option und inputenc-Option und tatsächliche Codierung sollten übereinstimmen, sonst gibt es wieder Probleme.

Stefan

Verfasst: Di 9. Aug 2016, 12:42
von u_fischer
Skysegeljack hat geschrieben:Und es ist doch offensichtlich nicht einfach, ein Minimalbeispiel anzugeben, wenn man den auftretenden Fehler nicht eingrenzen kann.
Nun, das es einfach ist, eine vernünftige Problembeschreibung zu liefern, behauptet ja auch keiner. Aber da sie nötig ist, um ein Problem effektiv zu lösen, solltest du lernen, wie man das macht. Es interessiert niemanden, warum du dropbox benützt, aber "die globale .sty-Vereinbarung" ist viel zu vage.

Mein Editor ist auf auf UTF-8-Kodierung eingestellt
Deswegen ist wohl das neue Kapitel in utf8 kodiert

und das Ändern zu \usepackage[utf8]{inputenc} produziert eine viel größere Anzahl an Fehlern.
Weil die alten Kapitel in latin1 kodiert sind.

Kodierung ist eine Eigenschaft der Datei. Mit der inputenc-Option sagst, du latex welche Kodierung du benützt. Wenn du da nicht die Wahrheit sagst -- weil z.B. ein Teil deiner Dateien anders kodiert sind -- dann gibt es Fehler.

Du kannst sowas machen
\inputencoding{utf8}
\include{<Kapitel das Probleme-macht, weil es utf8-kodiert ist>}
\inputencoding{latin1}
Aber auf Dauer ist es besser, wenn alle deine Dateien dieselbe Kodierung benützen.