von Noch so einer » Di 19. Feb 2013, 08:05
Dann würde ich jetzt einfach einmal empfehlen, den Editor grundsätzlich auf UTF-8 einzustellen und latin1, latin9, cp1252 und ansinew durch utf8 zu ersetzen. Falls der Editor das nicht kann (z. B. WinEdt 1–6 oder TXC 1), wäre es Zeit für ein Update. Unter Linux beherrschen AFAIK alle aktuellen Linux-Editoren UTF-8. Auf dem Mac AFAIK fällt mir nur noch ein Dinosaurier ein, der das nicht kann, dem wäre dann aber mit ansinew erst recht nicht geholfen, weil er nach applemac schreit.
Damit ist man dann auch gleich bestens für biblatex+biber, native Eingabe-Codierung bei XeLaTeX und LuaLaTeX in Kombination mit nativer Ausgabe-Codierung mit Hilfe von fontspec gerüstet. Man muss dann allenfalls noch bei externen Listings wissen, in welcher Codierung diese vorliegen, damit man diese (per Option) mit der korrekten Codierung einbinden kann. Für Listings im Dokument selbst, sei auf listingsutf8 hingewiesen.
Zu Zeiten, als man wirklich noch auf 8bit-Codierung im Editor angewiesen war, nervte mich die Windows-Fraktion mit ihrem ansinew übrigens auch. Damals konnte mein Editor das noch nicht. Hätten die sich damals auf latin1 beschränkt, hätten sie selbst die Fehlermeldungen bei den paar zusätzlichen Zeichen bekommen und die selbst per Befehl eingegeben. Glücklicherweise kamen dann die diversen Euro-Pakete und schon hat keiner von denen mehr € direkt eingegeben, sondern meist \euro oder \Euro. Kurz darauf konnte dann mein Editor auch cp1252. Seither ist mir egal, was die Leute verwenden, hauptsache sie machen das dann auch korrekt. Ich bekomme nämlich noch immer viele Dokumente ohne inputenc aber in latin1 oder ansinw, bei denen dann "alles bis auf das ß funktioniert".
Dann würde ich jetzt einfach einmal empfehlen, den Editor grundsätzlich auf UTF-8 einzustellen und latin1, latin9, cp1252 und ansinew durch utf8 zu ersetzen. Falls der Editor das nicht kann (z. B. WinEdt 1–6 oder TXC 1), wäre es Zeit für ein Update. Unter Linux beherrschen AFAIK alle aktuellen Linux-Editoren UTF-8. Auf dem Mac AFAIK fällt mir nur noch ein Dinosaurier ein, der das nicht kann, dem wäre dann aber mit ansinew erst recht nicht geholfen, weil er nach applemac schreit.
Damit ist man dann auch gleich bestens für biblatex+biber, native Eingabe-Codierung bei XeLaTeX und LuaLaTeX in Kombination mit nativer Ausgabe-Codierung mit Hilfe von fontspec gerüstet. Man muss dann allenfalls noch bei externen Listings wissen, in welcher Codierung diese vorliegen, damit man diese (per Option) mit der korrekten Codierung einbinden kann. Für Listings im Dokument selbst, sei auf listingsutf8 hingewiesen.
Zu Zeiten, als man wirklich noch auf 8bit-Codierung im Editor angewiesen war, nervte mich die Windows-Fraktion mit ihrem ansinew übrigens auch. Damals konnte mein Editor das noch nicht. Hätten die sich damals auf latin1 beschränkt, hätten sie selbst die Fehlermeldungen bei den paar zusätzlichen Zeichen bekommen und die selbst per Befehl eingegeben. Glücklicherweise kamen dann die diversen Euro-Pakete und schon hat keiner von denen mehr € direkt eingegeben, sondern meist \euro oder \Euro. Kurz darauf konnte dann mein Editor auch cp1252. Seither ist mir egal, was die Leute verwenden, hauptsache sie machen das dann auch korrekt. Ich bekomme nämlich noch immer viele Dokumente ohne inputenc aber in latin1 oder ansinw, bei denen dann "alles bis auf das ß funktioniert".