Umlaute in Latex direkt verwenden?

Umlaute wie äöü oder ÄÖÜ müssen in Latex ja immer als \"a, \"u usw. geschrieben werden.

Dies stört mich aber beim Schreibfluss.
Gibt es daher mit einer entsprechenden Erweiterung eine Möglichkeit
diese Unicode Zeichen direkt im Latex Code zu verwenden, ohne das man das ständig so umschreiben muss?

PS: Natürlich könnte ich auch ein Script schreiben (eventuell gibt es auch schon eines), dass mir diese Umlaute einfach durch die Latextypischen Umschreibungen ersetzt, aber das zerhakt dann auch den Text, wenn man diesen später wieder bearbeiten will.
Daher wäre mir die Möglichkeit einer direkten Eingabe von Unicodezeichen wesentlich lieber.

Kann man Latex das irgendwie beibringen?

Mechanics

Schau dir mal inputenc an.

dot

Ich würde die csquotes Package empfehlen.

\usepackage{csquotes}

oder

\usepackage{inputenc}

funktioniert beides nicht.
Wie bindet man das ein?

\usepackage[utf8]{inputenc}

Dann versteht pdflatex UTF-8.

Auch zu empfehlen:

\usepackage[T1]{fontenc}

Dann schreibt pdflatex ein ö als Unicode "ö" und nicht als "¨o" (dann kann man es im PDF-Reader normal markieren und kopieren).

Wichtig ist die Reihenfolge! Erst fontenc, dann inputenc!

\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

Falls du nicht die Standardschriftart verwendest (lmodern z.B. unterstützt mehr Zeichen als der Default, sieht aber sonst gleich aus), dann die Schriftart vorher laden:

\usepackage{lmodern}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

Wenn dir lmodern zu langweilig ist, kannst du das auch durch eine schönere Schriftart ersetzen, aber erst Schriftart, dann Output-Encoding, dann Input-Encoding.

csquotes hat damit nichts zu tun, das ist, wenn du die deutschen Anführungszeichen haben willst. Dazu:

\usepackage[ngerman]{babel}
\usepackage[babel,german=quotes]{csquotes}

% dann:
\enquote{Zitat}

Hat den Vorteil, dass du die Anführungszeichen zentral ändern kannst.

csquotes schrieb:

\usepackage[utf8]{inputenc}
Dann versteht pdflatex UTF-8.

Super, Danke!

Auch zu empfehlen:
\usepackage[T1]{fontenc}
Dann schreibt pdflatex ein ö als Unicode "ö" und nicht als "¨o" (dann kann man es im PDF-Reader normal markieren und kopieren).

Wichtig ist die Reihenfolge! Erst fontenc, dann inputenc!
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

Hm, wenn ich das so mache, dann kann ich den Text gar nicht mehr Copy&Pasten.
D.h. wenn ich das PDF Dokument z.B. mit Okular öffne und dann den Text in die Zwischenlage zu kopieren versuche, dann erhalte ich beim Einfügen in einen einfachen Editor nur noch garbage.
Interessant ist auch, dass dvipdf sehr lange braucht.

Ohne die Zeile \usepackage[T1]{fontenc} erhalte ich allerdings noch einen brauchbaren Output, auch wenn dann die Umlaute wie du sagst teilweise so aussehen "U, "A usw..

Falls du nicht die Standardschriftart verwendest (lmodern z.B. unterstützt mehr Zeichen als der Default, sieht aber sonst gleich aus), dann die Schriftart vorher laden:
\usepackage{lmodern}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
Wenn dir lmodern zu langweilig ist, kannst du das auch durch eine schönere Schriftart ersetzen, aber erst Schriftart, dann Output-Encoding, dann Input-Encoding.

Damit, mit lmodern funktioniert es perfekt. Auch das Copy&Pasten funktioniert reibungslos und dvipdf ist auch wieder flink wie ein Wiesel.
Man braucht also alle drei Zeilen.

csquotes hat damit nichts zu tun, das ist, wenn du die deutschen Anführungszeichen haben willst. Dazu:
\usepackage[ngerman]{babel}
\usepackage[babel,german=quotes]{csquotes}

% dann:
\enquote{Zitat}
Hat den Vorteil, dass du die Anführungszeichen zentral ändern kannst.

Hm, das funktioniert bei mir wiederum gar nicht.

rüdiger

Interessant ist auch, dass dvipdf sehr lange braucht.

Warum nimmst du überhaupt dvipdf anstelle gleich pdflatex (oder xetex/luatex die schon automatisch unicode können)? Der Zwischenweg über dvi ist nicht zu empfehlen.

ich würde das mit äöü bleiben lassen und bei \"a und "a bleiben. Diese Einstellung mag dadurch beeinflußt sein, daß ich schon Manuskripte in den Händen hatte, an denen verschiedene Personen wohl mit mehreren verschiedenen Editoren oder einer Textverarbeitung herumgeschraubt hatten, sodaß die Umlaute je nach Passage nach ä aussahen oder als wäre alle paar Wörter die Katze über das kezboard gelaufen.

@rüdiger

Danke für den Tipp.
Ich kenn das halt immer noch nur über den Umweg über dvi.

@Großbuchstaben

Ja, die Probleme kenne ich, die gibt's ja auch beim Programmieren. Insbesondere wenn Unicode BOM nicht erlaubt ist und die Leute mit schlechten Editoren arbeiten.

Aber jedesmal "U anstatt Ü zu schreiben stört wirklich den Schreibfluss, dadurch
werde ich sicherlich sehr langsam, weil ich es eben gewohnt bin, die Umlaute normal einzutippen. Außerdem wird es für mich dann auch wesentlich schwieriger Fehler zu erkennen.

Notfalls schreibe ich ein Script, dass die Umlaute am Ende, wenn alles fertig ist, gegen "U, "A usw. austauscht, aber bis dahin möchte ich diese wichtigen Unicodezeichen auf alle Fälle nutzen können.

Noch etwas, normalerweise schreibe ich die Umlaute z.B. beim Coden als oe, oa usw. aus, aber bei Latex will man halt sicherlich ein besseres Endprodukt als Wörter mit oe, oa usw.. deswegen geht das auch nicht.

Beim Programmieren, wo ich das nutze, stört mich das nicht so, weil es ja eh nur wenige Wörter sind, die so geschrieben werden müssen.
Aber bei richtigem Text werden das halt sehr schnell sehr viele.

Ich hatte noch nie Probleme mit Unicode in LaTeX und in Source Code schreibe ich die sowieso nicht.

http://www.utf8everywhere.org/

OT:

csquotes schrieb:

http://www.utf8everywhere.org/

Wenn man sich das so durchliest, dann kommt man zu der Feststellung, dass es D richtig gemacht hat.

Denn D kennt UTF-8 Strings und auch chars out of the box.

D_lang schrieb:

OT:

csquotes schrieb:

http://www.utf8everywhere.org/

Wenn man sich das so durchliest, dann kommt man zu der Feststellung, dass es D richtig gemacht hat.

Denn D kennt UTF-8 Strings und auch chars out of the box.

Ich bin mit D zwar nicht in allen Belangen einverstanden, aber Unicode ist in D ganz gut umgesetzt.

Dinge wie Graphemcount sind zwar immer noch nicht möglich, aber das was D standardmässig kann, ist mMn besser als in C++.

(Btw: C++ macht es auch "richtig", da es mit std::string trivial ist, Programme zu schreiben, die unicode-aware sind)

Und weisst du was: pdftex (die Engine hinter LaTeX) selber versteht auch nix von Unicode! Alles was es liest ist eine Liste von uint8_t. Aber es ist möglich, mit Macros diese Liste zu bearbeiten. Wenn nichtmal pdftex Unicode-Support braucht, wozu braucht man das dann überhaupt?

csquotes schrieb:

(Btw: C++ macht es auch "richtig", da es mit std::string trivial ist, Programme zu schreiben, die unicode-aware sind)

Ja, UTF-8 ist ultrafein für >95 % der Fälle, in denen ich Unicode-Strings speichern und verarbeiten muss. Unter Unix und Plan9 funktioniert das einfach. UTF-8 in, UTF-8 out, ohne dass mich die Bedeutung der Strings groß interessieren muss. Muss ich doch mal direkt mit Codepoints arbeiten, dekodiere ich den String eben fix.

Mein Problem jetzt ist der Punkt, wo das bestehende Programm vielleicht auch mal unter Windows laufen soll. Ist es überhaupt möglich ein Standard-C oder C++-Programm zu schreiben, das unter Windows Unicode handhaben kann?

Ich scheitere schon beim simpelsten Beispiel. Das Programm soll einen Dateinamen aus argv lesen und die entsprechende Datei öffnen. Unter Unix kein Problem, aber wie geht das unter Windows?

Die Verwendung eines Startupskripts o.ä. das bestimmte Environmentsvariablen setzt oder sowas wäre akzeptabel.

dot

COMBINING DIAERESIS schrieb:

Mein Problem jetzt ist der Punkt, wo das bestehende Programm vielleicht auch mal unter Windows laufen soll. Ist es überhaupt möglich ein Standard-C oder C++-Programm zu schreiben, das unter Windows Unicode handhaben kann?

Naja, unter Windows halt einfach std::wstring nehmen!?

COMBINING DIAERESIS schrieb:

Ich scheitere schon beim simpelsten Beispiel. Das Programm soll einen Dateinamen aus argv lesen und die entsprechende Datei öffnen. Unter Unix kein Problem, aber wie geht das unter Windows?

http://msdn.microsoft.com/en-us/library/bky3b5dh.aspx

dot schrieb:

Naja, unter Windows halt einfach std::wstring nehmen!?

Damit ist es ja nicht getan. Dein Hinweis auf "wmain" bringt mich schonmal zu einem Non-Standard-Programm, das nirgends anders kompiliert. Deshalb fragte ich ja nach Standard C...

Aber selbst wenn man darüber hinweg sieht: fopen & Co. wollen keinen wchar_t*, sondern einen char*. Mir ist bewusst, dass es ein äquivalentes _wfopen gibt, aber ich denke du siehst, worauf das hinaus läuft: letztendlich würde mein ganzes Programm unportabel und Windows-spezifisch oder zumindest grob ifdef-zerhackt. Darüberhinaus ist das so sowieso völlig unpraktikabel: sobald es über das genannte Trivialbeispiel hinaus geht, muss ich ja irgendwann mit der Außenwelt kommunizieren und die akzeptiert kein UTF-16LE. Ne ne, so wird das nichts.

Das einzig machbare scheint mir zu sein, sämtliche I/O-Funktionalität zu abstrahieren und in der Windows-Implementierung davon möglichst früh nach UTF-8 zu wandeln. Die Aussicht darauf stinknormale Aufrufe der C-Standardlibrary wrappen zu müssen begeistert mich aber auch nicht unbedingt, von einer bestehenden Codebasis mal ganz abgesehen.

Bei derartigem Zusatzaufwand wird's dann lieber ganz sein gelassen. Schade.

Was mir da grad einfällt: es scheint in Windows ja durchaus eine UTF8-Locale zu geben ('Codepage 65001'). Allerdings wurde diese in irgendeiner Art und Weise eingeschränkt. Grund waren Kompatiblitätsbedenken: es existieren möglicherweise kaputte Anwendungen, die davon ausgehen, dass Multibyte-Encodings einer Windows-Codepage niemals mehr als zwei Bytes für einen Codepoint verwenden. UTF-8 geht teilweise darüber hinaus (bis zu 4 Bytes), was diese Anwendungen zum Durchdrehen bringen könnte.

Ich nehme an, an den Beschränkungen hat sich immer noch nichts geändert? Was war nochmal gleich das Problem, das einen von der Nutzung abhält?

Kann den Artikel nicht mehr finden. Meine ich hätte das auf Michael Kaplans Blog gelesen, aber alle Links dahin sind tot.

Da war das früher mal:
http://blogs.msdn.com/b/michkap/