Der Unterschied zwischen der Verwendung von `selinput` und `inputenc` ist, dass man mit `inputenc` via Option eine *feste Codierung* vorgibt. Man muss also selbst wissen, in welcher Codierung das Dokument vorliegt und sagt dann beispielsweise: Dieses Dokument ist UTF8-codiert und nichts anderes! Dagegen erklärt man bei `selinput`, welche *Bedeutung einige Sonderzeichen* haben. Daraus ermittelt das Paket dann selbst eine dazu passende Codierung. Das Paket `selinput` hat auf den ersten Blick den Vorteil, dass Anwender, die gar *nicht wissen, in welcher Codierung* sie arbeiten oder was denn eigentlich die unterschiedlichen Codierungen bedeuten und wie die zugehörigen Optionen für `inputenc` heißen, sich mit dieser Frage zunächst nicht wirklich beschäftigen müssen. Dieser Vorteil kann sich jedoch auch in ein Problem verwandeln. Spätestens, wenn mit einer nicht in demselben Editor oder nicht mit denselben Einstellungen erzeugte Literaturdatenbank gearbeitet wird, muss man nämlich zumindest wissen, welche Codierung diese hat. Deshalb wäre es schon sinnvoll, wenn man wüsste, wie man die Codierung erkennt und wie man sie angibt. Einen weiteren Vorteil bietet das Paket allerdings beim *Austausch von Dateien* mit anderen. Wird eine Datei in einen anderen Editor geladen und anschließend mit veränderten Codierungseinstellungen gespeichert, so werden Sonderzeichen meist umcodiert. Der Empfänger muss daher bei Verwendung von `inputenc` ggf. die Optionen ändern. Bei Verwendung von `selinput` entfällt dieser Schritt. Bei einmaliger Übertragung ist das kein Problem, wenn aber die Datei mehrfach hin und her übertragen wird, kann es nervig werden. Noch extremer wird das ganze, wenn die Datei per *Copy&Paste* über WWW-Seiten, im Usenet oder E-Mails ausgetauscht wird. Dabei wird häufig die Codierung bereits beim Copy&Paste oder durch die Übertragung geändert. So liefern einige WWW-Seiten beispielsweise grundsätzlich UTF8 aus, während andere grundsätzlich ISO-Latin-1 (gleichbedeutend mit ISO-8859-1) verwenden. So kann sich die Codierung bereits beim Kopieren vom Editor in den Browser ändern. Genauso kann sich die Codierung beim Kopieren aus dem Browser in den Editor noch einmal ändern. Der Absender weiß also gar nicht, welche Codierung die Datei beim Empfänger haben wird (bei der `ftp`-Übertragung kann man solche Probleme hingegen leicht verhindern, indem man Textdateien ebenfalls im binär-Modus überträgt). Hier hat `selinput` also einen deutlichen Vorteil, da natürlich die *Markerzeichen*, über die `selinput` die Codierung selbst ermittelt, ebenfalls mit gewandelt werden. Der Unterschied zwischen der Angabe *mit `€` oder ohne `€`* macht sich bei `selinput` übrigens beispielsweise bemerkbar, wenn man eine ISO-Latin-9-codierte Datei hat. ISO-Latin-9 (gleichbedeutend mit ISO-8859-15) hat im Unterschied zu ISO-Latin-1 ein Eurozeichen und kann darüber erkannt werden. Ebenso kann die ISO-Latin-1-Erweiterung, die als `ansinew` bekannt ist, dadurch von ISO-Latin-1 unterschieden werden. Bei Texten ohne direkt eingegebenes Eurozeichen, spielt das aber eher keine Rolle. Außerdem bereitet es natürlich Probleme, wenn der Empfänger eine Codierung ohne Eurozeichen verwendet. Damit das direkt eingegebene Eurozeichen ggf. auch tatsächlich in der Ausgabe zu einem Eurozeichen wird, muss allerdings auch ein passender Font in passender Codierung verwendet werden. Hier kann teilweise `\usepackage{textcomp}` helfen. Bei Verwendung von *LuaLaTeX oder XeLaTeX* sollte man übrigens auf `inputenc` (und auch das in Kommentaren erwähnte `fontenc`) verzichten. Da `selinput` intern ebenfalls `inputenc` verwendet, sollte man dann genauso auf dieses Paket verzichten. Stattdessen sollte man dann einen Editor mit UTF8-Codierung UTF-8-Codierung verwenden (und statt `fontenc` das Paket `fontspec` laden). Dadurch verwendet man direkt die native UTF8-Codierung UTF-8-Codierung von LuaTeX bzw. XeTeX, die weit mehr kann als `inputenc`. Für Dokumente, die sowohl *sowohl mit LuaLaTeX oder XeLaTeX als auch mit pdfLaTeX unabhängig von der verwendeten LaTeX-Version* verarbeitet werden können, empfiehlt sich daher etwas wie: \usepackage{ifluatex,ifxetex} \ifluatex \usepackage{fontspec} \else \ifxetex \usepackage{fontspec} \else \usepackage{selinput} \SelectInputMappings{ adieresis={ä}, germandbls={ß}, } \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi \fi oder, da man den Editor ohnehin auf die Codierung UTF-8 einstellen sollte auch direkt: \usepackage{ifluatex,ifxetex} \ifluatex \usepackage{fontspec} \else \ifxetex \usepackage{fontspec} \else \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi \fi Das Pakete `lmodern` habe ich im Beispiel geladen, damit dieselbe Grundschrift wie bei Verwendung von `fontspec` verwendet wird. Natürlich funktioniert das nur so lange bis man maschinenabhängige bzw. von `fontspec` abhängige Besonderheiten verwendet. Spätestens dann muss man sich für einen Weg entscheiden! Dann lohnt es sich ggf. auch über Kommentare (beispielsweise `arara`-Anweisungen) auch direkt im Kopf des Dokuments klar zu stellen, welches LaTeX zu verwenden ist! ist! Theoretisch könnte man auf das Laden von `fontspec` auch verzichten. Da auch ohne dieses XeLaTeX und LuaLaTeX in der Voreinstellung die Schrift Latin Modern verwenden. Hat man eine aktuelle LaTeX-Installation mit *LaTeX ab Version 2018/04/01*, so ist auch für PDFLaTeX die voreingestellte Codierung UTF-8. Verwendet man also für die Eingabe diese Codierung, so vereinfacht sich obiger Code zur Berücksichtigung unterschiedlicher Engines zu: \usepackage{ifluatex,ifxetex} \ifluatex \usepackage{fontspec} \else \ifxetex \usepackage{fontspec} \else \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi \fi oder etwas trickreicher: \usepackage{ifluatex,ifxetex} \ifcase 0\ifluatex 1\else\ifxetex 1\fi\fi\relax \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \else \usepackage{fontspec} \fi oder noch ein wenig trickreicher: \ifcsname IeC\endcsname % aktuelles LaTeX mit 8-Bit-Engine (z. B. pdflatex) \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi wobei letzteres Interna von LaTeX nutzt, so dass ich davon eher abraten würde. Bevor jetzt jemand auf die ganze schlaue Idee kommt, so etwas zu machen: % Nicht sinnvoll!!! Nicht nachmachen!!!! \ifcsname UseRawInputEncoding\endcsname\else \usepackage[utf8]{inputenc}% veraltetes LaTeX benötigt inputenc \fi \ifcsname IeC\endcsname % weder XeLaTeX noch LuaLaTeX \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi Das ist nicht sinnvoll. Will man auf alte LaTeX-Versionen Rücksicht nehmen, verwendet man lieber die als erstes gezeigte Lösung, die auch bei neuerem LaTeX weiterhin funktioniert.

Der Unterschied zwischen der Verwendung von `selinput` und `inputenc` ist, dass man mit `inputenc` via Option eine *feste Codierung* vorgibt. Man muss also selbst wissen, in welcher Codierung das Dokument vorliegt und sagt dann beispielsweise: Dieses Dokument ist UTF8-codiert und nichts anderes! Dagegen erklärt man bei `selinput`, welche *Bedeutung einige Sonderzeichen* haben. Daraus ermittelt das Paket dann selbst eine dazu passende Codierung. Das Paket `selinput` hat auf den ersten Blick den Vorteil, dass Anwender, die gar *nicht wissen, in welcher Codierung* sie arbeiten oder was denn eigentlich die unterschiedlichen Codierungen bedeuten und wie die zugehörigen Optionen für `inputenc` heißen, sich mit dieser Frage zunächst nicht wirklich beschäftigen müssen. Dieser Vorteil kann sich jedoch auch in ein Problem verwandeln. Spätestens, wenn mit einer nicht in demselben Editor oder nicht mit denselben Einstellungen erzeugte Literaturdatenbank gearbeitet wird, muss man nämlich zumindest wissen, welche Codierung diese hat. Deshalb wäre es schon sinnvoll, wenn man wüsste, wie man die Codierung erkennt und wie man sie angibt. Einen weiteren Vorteil bietet das Paket allerdings beim *Austausch von Dateien* mit anderen. Wird eine Datei in einen anderen Editor geladen und anschließend mit veränderten Codierungseinstellungen gespeichert, so werden Sonderzeichen meist umcodiert. Der Empfänger muss daher bei Verwendung von `inputenc` ggf. die Optionen ändern. Bei Verwendung von `selinput` entfällt dieser Schritt. Bei einmaliger Übertragung ist das kein Problem, wenn aber die Datei mehrfach hin und her übertragen wird, kann es nervig werden. Noch extremer wird das ganze, wenn die Datei per *Copy&Paste* über WWW-Seiten, im Usenet oder E-Mails ausgetauscht wird. Dabei wird häufig die Codierung bereits beim Copy&Paste oder durch die Übertragung geändert. So liefern einige WWW-Seiten beispielsweise grundsätzlich UTF8 aus, während andere grundsätzlich ISO-Latin-1 (gleichbedeutend mit ISO-8859-1) verwenden. So kann sich die Codierung bereits beim Kopieren vom Editor in den Browser ändern. Genauso kann sich die Codierung beim Kopieren aus dem Browser in den Editor noch einmal ändern. Der Absender weiß also gar nicht, welche Codierung die Datei beim Empfänger haben wird (bei der `ftp`-Übertragung kann man solche Probleme hingegen leicht verhindern, indem man Textdateien ebenfalls im binär-Modus überträgt). Hier hat `selinput` also einen deutlichen Vorteil, da natürlich die *Markerzeichen*, über die `selinput` die Codierung selbst ermittelt, ebenfalls mit gewandelt werden. Der Unterschied zwischen der Angabe *mit `€` oder ohne `€`* macht sich bei `selinput` übrigens beispielsweise bemerkbar, wenn man eine ISO-Latin-9-codierte Datei hat. ISO-Latin-9 (gleichbedeutend mit ISO-8859-15) hat im Unterschied zu ISO-Latin-1 ein Eurozeichen und kann darüber erkannt werden. Ebenso kann die Mikrosoft-Erweiterung, ISO-Latin-1-Erweiterung, die als `ansinew` bekannt ist, dadurch von ISO-Latin-1 unterschieden werden. Bei Texten ohne direkt eingegebenes Eurozeichen, spielt das aber eher keine Rolle. Außerdem bereitet es natürlich Probleme, wenn der Empfänger eine Codierung ohne Eurozeichen verwendet. Damit das direkt eingegebene Eurozeichen dann ggf. auch tatsächlich in der Ausgabe zu einem Eurozeichen wird, muss allerdings auch ein passender Font in passender Codierung verwendet werden. Hier kann teilweise `\usepackage{textcomp}` helfen. Bei Verwendung von *LuaLaTeX oder XeLaTeX* sollte man übrigens auf `inputenc` (und auch das in Kommentaren erwähnte `fontenc`) verzichten. Da `selinput` intern ebenfalls `inputenc` verwendet, sollte man dann genauso auf dieses Paket verzichten. Stattdessen sollte man dann einen Editor mit UTF8-Codierung verwenden (und statt `fontenc` das Paket `fontspec` laden). Dadurch verwendet man direkt die native UTF8-Codierung von LuaTeX bzw. XeTeX, die weit mehr kann als `inputenc`. Für Dokumente, die sowohl mit LuaLaTeX oder XeLaTeX als auch mit pdfLaTeX verarbeitet werden können, empfiehlt sich daher etwas wie: \usepackage{ifluatex,ifxetex} \ifluatex \usepackage{fontspec} \else \ifxetex \usepackage{fontspec} \else \usepackage{selinput} \SelectInputMappings{ adieresis={ä}, germandbls={ß}, } \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi \fi Das Pakete `lmodern` habe ich im Beispiel geladen, damit dieselbe Grundschrift wie bei Verwendung von `fontspec` verwendet wird. Natürlich funktioniert das nur so lange bis man maschinenabhängige bzw. von `fontspec` abhängige Besonderheiten verwendet. Spätestens dann muss man sich für einen Weg entscheiden! Dann lohnt es sich ggf. auch über Kommentare (beispielsweise `arara`-Anweisungen) auch direkt im Kopf des Dokuments klar zu stellen, welches LaTeX zu verwenden ist!

Der Unterschied zwischen der Verwendung von `selinput` und `inputenc` ist, dass man mit `inputenc` via Option eine feste Codierung *feste Codierung* vorgibt. Man muss also selbst wissen, in welcher Codierung das Dokument vorliegt und sagt dann beispielsweise: Dieses Dokument ist UTF8-codiert und nichts anderes! Dagegen erklärt man bei `selinput`, welche Bedeutung *Bedeutung einige Sonderzeichen Sonderzeichen* haben. Daraus ermittelt das Paket dann selbst eine dazu passende Codierung. Das Paket `selinput` hat auf den ersten Blick den Vorteil, dass Anwender, die gar nicht *nicht wissen, in welcher Codierung Codierung* sie arbeiten oder was denn eigentlich die unterschiedlichen Codierungen bedeuten und wie die zugehörigen Optionen für `inputenc` heißen, sich mit dieser Frage zunächst nicht wirklich beschäftigen müssen. Dieser Vorteil kann sich jedoch auch in ein Problem verwandeln. Spätestens, wenn mit einer nicht in demselben Editor oder nicht mit denselben Einstellungen erzeugte Literaturdatenbank gearbeitet wird, muss man nämlich zumindest wissen, welche Codierung diese hat. Deshalb wäre es schon sinnvoll, wenn man wüsste, wie man die Codierung erkennt und wie man sie angibt. Einen weiteren Vorteil bietet das Paket allerdings beim Austausch *Austausch von Dateien Dateien* mit anderen. Wird eine Datei in einen anderen Editor geladen und anschließend mit veränderten Codierungseinstellungen gespeichert, so werden Sonderzeichen meist umcodiert. Der Empfänger muss daher bei Verwendung von `inputenc` ggf. die Optionen ändern. Bei Verwendung von `selinput` entfällt dieser Schritt. Bei einmaliger Übertragung ist das kein Problem, wenn aber die Datei mehrfach hin und her übertragen wird, kann es nervig werden. Noch extremer wird das ganze, wenn die Datei per Copy&Paste *Copy&Paste* über WWW-Seiten, im Usenet oder E-Mails ausgetauscht wird. Dabei wird häufig die Codierung bereits beim Copy&Paste oder durch die Übertragung geändert. So liefern einige WWW-Seiten beispielsweise grundsätzlich UTF8 aus, während andere grundsätzlich ISO-Latin-1 (gleichbedeutend mit ISO-8859-1) verwenden. So kann sich die Codierung bereits beim Kopieren vom Editor in den Browser ändern. Genauso kann sich die Codierung beim Kopieren aus dem Browser in den Editor noch einmal ändern. Der Absender weiß also gar nicht, welche Codierung die Datei beim Empfänger haben wird (bei der `ftp`-Übertragung kann man solche Probleme hingegen leicht verhindern, indem man Textdateien ebenfalls im binär-Modus überträgt). Hier hat `selinput` also einen deutlichen Vorteil, da natürlich die *Markerzeichen*, über die `selinput` die Codierung selbst ermittelt, ebenfalls mit gewandelt werden. Der Unterschied zwischen der Angabe mit *mit `€` oder ohne `€` `€`* macht sich bei `selinput` übrigens beispielsweise bemerkbar, wenn man eine ISO-Latin-9-codierte Datei hat. ISO-Latin-9 (gleichbedeutend mit ISO-8859-15) hat im Unterschied zu ISO-Latin-1 ein Eurozeichen und kann darüber erkannt werden. Ebenso kann die Mikrosoft-Erweiterung, die als `ansinew` bekannt ist, dadurch von ISO-Latin-1 unterschieden werden. Bei Texten ohne direkt eingegebenes Eurozeichen, spielt das aber eher keine Rolle. Außerdem bereitet es natürlich Probleme, wenn der Empfänger eine Codierung ohne Eurozeichen verwendet. Damit das direkt eingegebene Eurozeichen dann auch tatsächlich in der Ausgabe zu einem Eurozeichen wird, muss allerdings auch ein passender Font in passender Codierung verwendet werden. Hier kann teilweise `\usepackage{textcomp}` helfen. Bei Verwendung von LuaLaTeX *LuaLaTeX oder XeLaTeX XeLaTeX* sollte man übrigens auf `inputenc` (und auch das in Kommentaren erwähnte `fontenc`) verzichten. Da `selinput` intern ebenfalls `inputenc` verwendet, sollte man dann genauso auf dieses Paket verzichten. Stattdessen sollte man dann einen Editor mit UTF8-Codierung verwenden (und statt `fontenc` das Paket `fontspec` laden). Dadurch verwendet man direkt die native UTF8-Codierung von LuaTeX bzw. XeTeX, die weit mehr kann als `inputenc`. Für Dokumente, die sowohl mit LuaLaTeX oder XeLaTeX als auch mit pdfLaTeX verarbeitet werden können, empfiehlt sich daher etwas wie: \usepackage{ifluatex,ifxetex} \ifluatex \usepackage{fontspec} \else \ifxetex \usepackage{fontspec} \else \usepackage{selinput} \SelectInputMappings{ adieresis={ä}, germandbls={ß}, } \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi \fi Das Pakete `lmodern` habe ich im Beispiel geladen, damit dieselbe Grundschrift wie bei Verwendung von `fontspec` verwendet wird. Natürlich funktioniert das nur so lange bis man maschinenabhängige bzw. von `fontspec` abhängige Besonderheiten verwendet. Spätestens dann muss man sich für einen Weg entscheiden! Dann lohnt es sich ggf. auch über Kommentare (beispielsweise `arara`-Anweisungen) auch direkt im Kopf des Dokuments klar zu stellen, welches LaTeX zu verwenden ist!

Der Unterschied zwischen der Verwendung von `selinput` und `inputenc` ist, dass man mit `inputenc` via Option eine feste Codierung vorgibt. Man muss also selbst wissen, in welcher Codierung das Dokument vorliegt und sagt dann beispielsweise: Dieses Dokument ist UTF8-codiert und nichts anderes! Dagegen erklärt man bei `selinput`, welche Bedeutung einige Sonderzeichen haben. Daraus ermittelt das Paket dann selbst eine dazu passende Codierung. Das Paket `selinput` hat auf den ersten Blick den Vorteil, dass Anwender, die gar nicht wissen, in welcher Codierung sie arbeiten oder was denn eigentlich die unterschiedlichen Codierungen bedeuten und wie die zugehörigen Optionen für `inputenc` heißen, sich mit dieser Frage zunächst nicht wirklich beschäftigen müssen. Dieser Vorteil kann sich jedoch auch in ein Problem verwandeln. Spätestens, wenn mit einer nicht in demselben Editor oder nicht mit denselben Einstellungen erzeugte Literaturdatenbank gearbeitet wird, muss man nämlich zumindest wissen, welche Codierung diese hat. Deshalb wäre es schon sinnvoll, wenn man wüsste, wie man die Codierung erkennt und wie man sie angibt. Einen weiteren Vorteil bietet das Paket allerdings beim Austausch von Dateien mit anderen. Wird eine Datei in einen anderen Editor geladen und anschließend mit veränderten Codierungseinstellungen gespeichert, so werden Sonderzeichen meist umcodiert. Der Empfänger muss daher bei Verwendung von `inputenc` ggf. die Optionen ändern. Bei Verwendung von `selinput` entfällt dieser Schritt. Bei einmaliger Übertragung ist das kein Problem, wenn aber die Datei mehrfach hin und her übertragen wird, kann es nervig werden. Noch extremer wird das ganze, wenn die Datei per Copy&Paste über WWW-Seiten WWW-Seiten, im Usenet oder E-Mails ausgetauscht wird. Dabei wird häufig die Codierung bereits beim Copy&Paste oder durch die Übertragung geändert. So liefern einige WWW-Seiten beispielsweise grundsätzlich UTF8 aus, während andere grundsätzlich ISO-Latin-1 (gleichbedeutend mit ISO-8859-1) verwenden. So kann sich die Codierung bereits beim Kopieren vom Editor in den Browser ändern. Genauso kann sich die Codierung beim Kopieren aus dem Browser in den Editor noch einmal ändern. Der Absender weiß also gar nicht, welche Codierung die Datei beim Empfänger haben wird (bei der `ftp`-Übertragung kann man solche Probleme hingegen leicht verhindern, indem man Textdateien ebenfalls im binär-Modus überträgt). Hier hat `selinput` also einen deutlichen Vorteil, da natürlich die *Markerzeichen*, über die `selinput` die Codierung selbst ermittelt, ebenfalls mit gewandelt werden. Der Unterschied zwischen der Angabe mit `€` oder ohne `€` macht sich bei `selinput` übrigens beispielsweise bemerkbar, wenn man eine ISO-Latin-9-codierte Datei hat. ISO-Latin-9 (gleichbedeutend mit ISO-8859-15) hat im Unterschied zu ISO-Latin-1 ein Eurozeichen und kann darüber erkannt werden. Ebenso kann die Mikrosoft-Erweiterung, die als `ansinew` bekannt ist, dadurch von ISO-Latin-1 unterschieden werden. Bei Texten ohne direkt eingegebenes Eurozeichen, spielt das aber eher keine Rolle. Außerdem bereitet es natürlich Probleme, wenn der Empfänger eine Codierung ohne Eurozeichen verwendet. Damit das direkt eingegebene Eurozeichen dann auch tatsächlich in der Ausgabe zu einem Eurozeichen wird, muss allerdings auch ein passender Font in passender Codierung verwendet werden. Hier kann teilweise `\usepackage{textcomp}` helfen. Bei Verwendung von LuaLaTeX oder XeLaTeX sollte man übrigens auf `inputenc` (und auch das in Kommentaren erwähnte `fontenc`) verzichten. Da `selinput` intern ebenfalls `inputenc` verwendet, sollte man dann genauso auf dieses Paket verzichten. Stattdessen sollte man dann einen Editor mit UTF8-Codierung verwenden (und statt `fontenc` das Paket `fontspec` laden). Dadurch verwendet man direkt die native UTF8-Codierung von LuaTeX bzw. XeTeX, die weit mehr kann als `inputenc`. Für Dokumente, die sowohl mit LuaLaTeX oder XeLaTeX als auch mit pdfLaTeX verarbeitet werden können, empfiehlt sich daher etwas wie: \usepackage{ifluatex,ifxetex} \ifluatex \usepackage{fontspec} \else \ifxetex \usepackage{fontspec} \else \usepackage{selinput} \SelectInputMappings{ adieresis={ä}, germandbls={ß}, } \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi \fi Das Pakete `lmodern` habe ich im Beispiel geladen, damit dieselbe Grundschrift wie bei Verwendung von `fontspec` verwendet wird. Natürlich funktioniert das nur so lange bis man maschinenabhängige bzw. von `fontspec` abhängige Besonderheiten verwendet. Spätestens dann muss man sich für einen Weg entscheiden! Dann lohnt es sich ggf. auch über Kommentare (beispielsweise `arara`-Anweisungen) auch direkt im Kopf des Dokuments klar zu stellen, welches LaTeX zu verwenden ist!

Der Unterschied zwischen der Verwendung von `selinput` und `inputenc` ist, dass man mit `inputenc` via Option eine feste Codierung vorgibt. Man muss also selbst wissen, in welcher Codierung das Dokument vorliegt und sagt dann beispielsweise: Dieses Dokument ist UTF8-codiert und nichts anderes! Dagegen erklärt man bei `selinput`, welche Bedeutung einige Sonderzeichen haben. Daraus ermittelt das Paket dann selbst eine dazu passende Codierung. Das Paket `selinput` hat auf den ersten Blick den Vorteil, dass Anwender, die gar nicht wissen, in welcher Codierung sie arbeiten oder was denn eigentlich die unterschiedlichen Codierungen bedeuten und wie die zugehörigen Optionen für `inputenc` heißen, sich mit dieser Frage zunächst nicht wirklich beschäftigen müssen. Dieser Vorteil kann sich jedoch auch in ein Problem verwandeln. Spätestens, wenn mit einer nicht in demselben Editor oder nicht mit denselben Einstellungen erzeugte Literaturdatenbank gearbeitet wird, muss man nämlich zumindest wissen, welche Codierung diese hat. Deshalb wäre es schon sinnvoll, wenn man wüsste, wie man die Codierung erkennt und wie man sie angibt. Einen weiteren Vorteil bietet das Paket allerdings beim Austausch von Dateien mit anderen. Wird eine Datei in einen anderen Editor geladen und anschließend mit veränderten Codierungseinstellungen gespeichert, so werden Sonderzeichen meist umcodiert. Der Empfänger muss daher bei Verwendung von `inputenc` ggf. die Optionen ändern. Bei Verwendung von `selinput` entfällt dieser Schritt. Bei einmaliger Übertragung ist das kein Problem, wenn aber die Datei mehrfach hin und her übertragen wird, kann es nervig werden. Noch extremer wird das ganze, wenn die Datei per Copy&Paste über WWW-Seiten im Usenet oder E-Mails ausgetauscht wird. Dabei wird häufig die Codierung bereits beim Copy&Paste oder durch die Übertragung geändert. So liefern einige WWW-Seiten beispielsweise grundsätzlich UTF8 aus, während andere grundsätzlich ISO-Latin-1 (gleichbedeutend mit ISO-8859-1) verwenden. So kann sich die Codierung bereits beim Kopieren vom Editor in den Browser ändern. Genauso kann sich die Codierung beim Kopieren aus dem Browser in den Editor noch einmal ändern. Der Absender weiß also gar nicht, welche Codierung die Datei beim Empfänger haben wird (bei der `ftp`-Übertragung kann man solche Probleme hingegen leicht verhindern, indem man Textdateien ebenfalls im binär-Modus überträgt). Hier hat `selinput` also einen deutlichen Vorteil, da natürlich die *Markerzeichen*, über die `selinput` die Codierung selbst ermittelt, ebenfalls mit gewandelt werden. Der Unterschied zwischen der Angabe mit `€` oder ohne `€` macht sich bei `selinput` übrigens beispielsweise bemerkbar, wenn man eine ISO-Latin-9-codierte Datei hat. ISO-Latin-9 (gleichbedeutend mit ISO-8859-15) hat im Unterschied zu ISO-Latin-1 ein Eurozeichen und kann darüber erkannt werden. Ebenso kann die Mikrosoft-Erweiterung, die als `ansinew` bekannt ist, dadurch von ISO-Latin-1 unterschieden werden. Bei Texten ohne direkt eingegebenes Eurozeichen, spielt das aber eher keine Rolle. Außerdem bereitet es natürlich Probleme, wenn der Empfänger eine Codierung ohne Eurozeichen verwendet. Damit das direkt eingegebene Eurozeichen dann auch tatsächlich in der Ausgabe zu einem Eurozeichen wird, muss allerdings auch ein passender Font in passender Codierung verwendet werden. Hier kann teilweise `\usepackage{textcomp}` helfen. Bei Verwendung von LuaLaTeX oder XeLaTeX sollte man übrigens auf `inputenc` (und auch das in Kommentaren erwähnte `fontenc`) verzichten. Da `selinput` intern ebenfalls `inputenc` verwendet, sollte man dann genauso auf dieses Paket verzichten. Stattdessen sollte man dann einen Editor mit UTF8-Codierung verwenden (und statt `fontenc` das Paket `fontspec` laden). Dadurch verwendet man direkt die native UTF8-Codierung von LuaTeX bzw. XeTeX, die weit mehr kann als `inputenc`. Für Dokumente, die sowohl mit LuaLaTeX oder XeLaTeX als auch mit pdfLaTeX verarbeitet werden können, empfiehlt sich daher etwas wie: \usepackage{ifluatex,ifxetex} \ifluatex \usepackage{fontspec} \else \ifxetex \usepackage{fontspec} \else \usepackage{selinput} \SelectInputMappings{ adieresis={ä}, germandbls={ß}, } \usepackage[T1]{fontenc} \usepackage{textcomp}% optional \usepackage{lmodern} \fi \fi Das Pakete `lmodern` habe ich im Beispiel geladen, damit dieselbe Grundschrift wie bei Verwendung von `fontspec` verwendet wird. Natürlich funktioniert das nur so lange bis man maschinenabhängige bzw. von `fontspec` abhängige Besonderheiten verwendet. Spätestens dann muss man sich für einen Weg entscheiden! Dann lohnt es sich ggf. auch über Kommentare (beispielsweise `arara`-Anweisungen) auch direkt im Kopf des Dokuments klar zu stellen, welches LaTeX zu verwenden ist!