Benutzer:RokerHRO/TeX

TeX ist veraltet

TeX ist IMHO schon lange nicht mehr das Gelbe vom Ei, besonders was den Formalsatz angeht. Hier mal ein paar Beispiele, aufgeführt in der Reihenfolge, in der sie mir beim Schreiben eingefallen sind.

Ich muss dazusagen, dass einige der hier aufgeführten Kritikpunkte sich nur auf Wiki-TeX beziehen, da ich nur hier TeX einsetze. Laut Aussagen einiger TeX-Benutzer lassen sich in einer "full-featured" TeX-Umgebung einige der hier angesprochenen Hässlichkeiten mehr oder weniger gut und mit mehr oder weniger großem Aufwand beseitigen/abmildern.

Große Wurzeln

Sie werden bei großen Radikanten senkrecht: :$x={\sqrt {\frac {\frac {1}{x}}{\frac {\alpha }{2}}}}$

Das sieht insbesondere bei Formeln schei**e aus, die auch "normale" Wurzeln enthalten:

$y={\sqrt {{\sqrt {\|x\|}}+{\sqrt {{\frac {1}{x}}+{\sqrt {x}}}}}}$

Verschachtelte Klammern

Sie wachsen nicht, weswegen sie sehr unübersichtlich sind: Fehler beim Parsen (Konvertierungsfehler. Der Server („https://wikimedia.org/api/rest_“) hat berichtet: „Cannot get mml. Server problem.“): {\displaystyle x=\left(\left(a+\log \left(\tan \left(b\right)\right)\right)\cdot \left(c+d\left(x\right)\right)\right)^{\frac {1}{3}}}
Man kann sich manchmal notbehelfen, in dem man die Klammergröße physisch formatiert. Dabei muss man gleich \Big nehmen Fehler beim Parsen (Konvertierungsfehler. Der Server („https://wikimedia.org/api/rest_“) hat berichtet: „Cannot get mml. Server problem.“): {\displaystyle {\Big (}x(t),y(t){\Big )}} , denn \big vergrößert nicht wirklich: ${\big (}x(t),y(t){\big )}$. Sobald aber der Klammerausdruck in einem Exponenten auftritt, bewirkt \big aber eine sichbare Vergrößerung der Klammern:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 2^{\big((4+\xi)\cdot\sin(x)\big)\cdot \varphi}} – Das verstehe, wer will...

Große Klammern

Sie werden, ebenso wie Wurzeln, ab einer gewissen Größe senkrecht:

${\begin{pmatrix}1&1&0\\1&0&1\\0&0&1\\1&-1&1\\1&{\sqrt {2}}&0\\-1&0&-1\\\end{pmatrix}}$

Klammern/Matrizen

Klammern stoßen zusammen. (Formel ist kein Fake, sondern dem Artikel Kronecker-Produkt entnommen und gekürzt)
Fehler beim Parsen (Konvertierungsfehler. Der Server („https://wikimedia.org/api/rest_“) hat berichtet: „Cannot get mml. Server problem.“): {\displaystyle {\begin{pmatrix}1\cdot {\begin{pmatrix}0&5\\5&0\\1&1\end{pmatrix}}&3\cdot {\begin{pmatrix}0&5\\5&0\\1&1\end{pmatrix}}\\1\cdot {\begin{pmatrix}0&5\\5&0\\1&1\end{pmatrix}}&0\cdot {\begin{pmatrix}0&5\\5&0\\1&1\end{pmatrix}}\end{pmatrix}}}

Verstümmelung kleiner Brüche

In Matrizen werden Brüche unnötig verstümmelt. Das sieht bei einfachen Brüchen wie 1/2 ja noch akzeptabel aus, aber bei komplexeren Ausdrücken wird es schnell unlesbar: ${\begin{pmatrix}{\frac {1}{2^{x}}}&0\\0&{\frac {1}{1+{\frac {1}{x^{2}}}}}\\\end{pmatrix}}$

Gleichungen ausrichten

Um mehrere Gleichungen zusammenzufassen und untereinander etwa am Gleichheitszeichen auszurichten, muss man einen Hack benutzen, in dem man sie in eine unsichtbare Matrix schreibt. Das ist physische Formatierung und keine logische, ähnlich wie Tabellen bei HTML als Layout-Hilfsmittel missbraucht wurden, bevor es CSS gab. Außerdem führt diese missbräuchliche Verwendung von Matrizen dazu, dass in derartig ausgerichteten Gleichungen Brüche und Summen und ähnliche Ausdrücke bescheiden und schwer lesbar dargestellt werden: ${\begin{matrix}f(x)&=&\sum _{i}^{x}2^{x}\\\ &=&{\frac {1}{2}}\cdot 2^{x+1}\\\end{matrix}}$

nicht-ASCII-Zeichen oder gar Unicode in Formeln

Sowas ist schlicht nicht vorgesehen und nur durch vielerlei unschöne Hacks erreichbar, wenn überhaupt, etwa das Gradzeichen (nein, ein hochgestellter Operator \circ ist ein Hack, kein Gradzeichen!), deutsche Umlaute inkl. ß (ein β im Formelsatz ist kein ß) oder das Promillezeichen.

Von exotischeren Unicode-Zeichen oder nicht-lateinschriftlichen textuellen Bemerkungen in Formeln will ich gar nicht erst reden.

Leerraum, mal zu viel mal zu wenig

Beispiel Hoch- und Tiefstellungen. Sie werden stur an die umliegende Box gezeichnet, anstatt auf den wahren Umriss des Zeichens einzugehen und so manche Indizes etwas dichter an das Grundzeichen zu rücken (Kerning):

Fehler beim Parsen (Konvertierungsfehler. Der Server („https://wikimedia.org/api/rest_“) hat berichtet: „Cannot get mml. Server problem.“): {\displaystyle A_{2}^{2},I_{2}^{2},\Gamma _{2}^{2},L_{2}^{2},\Delta _{2}^{2}} . Interessanterweise klappt es ein wenig bei $V_{2}^{2},W_{2}^{2},Y_{2}^{2},F_{2}^{2},T_{2}^{2}$.

Auch das "richtige Setzen von Leerraum um Operatoren" ist oft ungenügend, etwa hier:

$S_{n}:=x_{0}+x_{1}+\cdots +x_{n}.$

Das ist nicht schön, aber noch lesbar. Aber bei Produkten wird es ekelig:

$P_{n}:=x_{0}\cdot x_{1}\cdot \cdots \cdot x_{n}.$

Ist es so schwer, die Auslassungspunkte etwas dichter zu setzen und den Leerraum davor und danach etwas größer, so dass sie klar als Auslassungspunkte erkennbar sind? In HTML, mit physisch gesetzten Leerräumen, würde es etwa so aussehen:

P_n := x₀ · x₀ · ⋯ ·x_n.

Ich finde das weitaus lesbarer, je nach Bildschirmfont natürlich. In TeX müsste man dafür aufwändig tricksen, ebenfalls mit physischer Formatierung:

$P_{n}:=x_{0}\cdot x_{1}\cdot \ \cdot \!\cdot \!\cdot \ \cdot x_{n}.$ oder

$P_{n}:=x_{0}\cdot x_{1}\cdot \operatorname {\cdot } \operatorname {\cdot } \operatorname {\cdot } \cdot x_{n}.$

Richtig hübsch finde ich aber beides nicht, weder im Quelltext noch im gerenderten Ergebnis. :-(