Überarbeitungsverlauf

Da sich TeX bekanntlich nicht für die Glyphen eines Fonts, sondern nur für deren (rechteckige) Ausdehnung interessiert, ist mir nicht klar, was unter »frei drehbaren Fonts in LaTeX« zu verstehen sein soll. Darüber hinaus scheint der Fragesteller davon auszugehen, dass Satz nur darin besteht, Zeichen hintereinander zu setzen. Da Satz aber weit mehr ist, beispielsweise Kerning, Umbruch ggf. mit Wortabstandanpassung, Trennung etc. würde ein *gedrehter Font* nicht genügen, um in einer anderen Schreibrichtung zu setzen. Die Annahme, man bräuchte nur einen *gedrehten Font*, um einfach in beliebigen Richtungen schreiben zu können, ist damit von vornherein nicht ~~korrekt.~~ korrekt. Daher habe ich auch Schwierigkeiten zu verstehen, was denn eigentlich ein *frei drehbarer Font* sein soll und ob nicht gemeint in Wirklichkeit gemeint ist, ob TeX den Satz in beliebigen Schreibrichtungen oder entlang eines beliebigen Pfades erlaubt. Ich lese aus der Frage außerdem die Annahme, dass die Rotation mit einem der bekannten Pakete, beispielsweise `graphics`, `graphicx`, `lscape`, `pdflscape`, `rotating` und wie sie alle heißen mögen, aus der Tabelle (oder aus welchem Inhalt auch immer) zunächst eine Art *Bildobjekt* rendert und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten (allerdings geraden) Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Insbesondere geht es schnell und einfach. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das ~~möchte.~~ möchte. Nur wird der Satz ganzer Wörter und darauf aufbauend von Wortfolgen, Sätzen und Absätzen dann extrem aufwändig. Das beginnt bereits mit dem Kerning innerhalb der Wörter. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale Auflösung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann dreht ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch explizit skaliert wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das heutzutage sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Außerdem bietet TeX selbst keinen Mechanismus, um *einen Font zu drehen*. Beides wäre jedoch notwendig, um unter Beibehaltung von Kerning etc. Text korrekt entlang eines Pfades etwa um 90° gedreht zu setzen. Es gibt zwar Fonts beispielsweise mit auf dem Kopf stehenden Glyphen. Es bleibt aber dabei, dass TeX keine Mechanismen für den Satz in beliebigen Schreibrichtungen bietet. Außerdem war die Frage ja nicht ob Font mit gedrehten Zeichen existieren, sondern ob es ~~frei rotierbare~~ *frei drehbare Fonts für ~~TeX~~ LaTeX gibt. Da TeX keinen Mechanismus zur ~~Rotation~~ Drehung von Fonts (was immer das heißen soll) und zur beliebigen Änderung der Schreibrichtung bietet, kann das mit einem ~~»Nein.«~~ »Nein« beantwortet werden. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge erreichen. Aber auch das betrifft dann zunächst nur den Weg, auf dem das PDF erzeugt wird. Darauf, wie gut das Ausgabeprogramm, das ja letztlich die Fonts rendert, das dann umsetzt, hat der Weg wenig Einfluss und ist unabhängig vom Ausgabeprogramm nicht wirklich vorhersehbar. Außerdem ist der Aufwand, so etwas umzusetzen dann in luaTeX vermutlich bedeutend aufwändiger als einen fertig gesetzten Text zu rotieren. Immerhin gibt es bei luaTeX und XeTeX die Möglichkeit, Fonts in anderen Formaten als bei TeX, das sich ausschließlich für TFM-Metriken interessiert, zu verarbeiten. Damit können theoretisch auch OTF-Features verwendet werden, die nachträglich Einfluss auf die Ausrichtung und Form von Glyphen im Font nehmen. Derzeitige Font-Loader bieten das aber AFAIK so wenig wie der Typesetter (also den Teil von TeX, der aus Buchstaben Wörter, Absätze, Zeilen etc. macht) bisher beliebige Schreibrichtungen unterstützt. Bei luaTeX könne man natürlich weitgehenden Einfluss auf den Typesetter nehmen und diesen letztlich sogar ersetzen. Der Aufwand dafür dürfte aber um ein Vielfaches höher sein, als fertig gesetzten Text zu drehen. Anekdote am Rande: Vor ca. fünfzehn Jahren, als es noch üblich war, mit DVI zu arbeiten, war übrigens klar erkennbar, dass die Rotation erst vom Ausgabeprogramm vorgenommen wird. Da die meisten DVI-Treiber damals keine PostScript-Specials verarbeitet haben oder nur für das Rendern von Bildern ghostscript aufgerufen haben, wurden im DVI-Viewer gedrehte Objekte ungedreht angezeigt und ragten dann natürlich auch nicht selten in andere Seitenelemente hinein. Erst, wenn man dvips angeworfen und anschließend die PostScript-Datei angeschaut hat, hat man das tatsächliche Ergebnis gesehen. Das hat man aber nicht bei jedem LaTeX-Lauf gemacht, weil die Rechner dafür nicht schnell genug waren. Heute können selbst DVI-Viewer diverse PostScript-Specials interpretieren, kommen aber kaum noch zur Anwendung.

Da sich TeX bekanntlich nicht für die Glyphen eines Fonts, sondern nur für deren (rechteckige) Ausdehnung interessiert, ist mir nicht klar, was unter »frei drehbaren Fonts in LaTeX« zu verstehen sein ~~soll.~~ soll. Darüber hinaus scheint der Fragesteller davon auszugehen, dass Satz nur darin besteht, Zeichen hintereinander zu setzen. Da Satz aber weit mehr ist, beispielsweise Kerning, Umbruch ggf. mit Wortabstandanpassung, Trennung etc. würde ein *gedrehter Font* nicht genügen, um in einer anderen Schreibrichtung zu setzen. Die Annahme, man bräuchte nur einen *gedrehten Font*, um einfach in beliebigen Richtungen schreiben zu können, ist damit von vornherein nicht korrekt. Ich lese aus der Frage außerdem die Annahme, dass die Rotation mit einem der bekannten Pakete, beispielsweise `graphics`, `graphicx`, `lscape`, `pdflscape`, `rotating` und wie sie alle heißen mögen, aus der Tabelle (oder aus welchem Inhalt auch immer) zunächst eine Art *Bildobjekt* rendert und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das möchte. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale Auflösung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann dreht ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch explizit skaliert wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das heutzutage sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Außerdem bietet TeX selbst keinen Mechanismus, um *einen Font zu drehen*. Beides wäre jedoch notwendig, um unter Beibehaltung von Kerning etc. Text korrekt entlang eines Pfades etwa um 90° gedreht zu setzen. Es gibt zwar Fonts beispielsweise mit auf dem Kopf stehenden Glyphen. Es bleibt aber dabei, dass TeX keine Mechanismen für den Satz in beliebigen Schreibrichtungen bietet. Außerdem war die Frage ja nicht ob Font mit gedrehten Zeichen existieren, sondern ob es frei rotierbare Fonts für TeX gibt. Da TeX keinen Mechanismus zur Rotation von Fonts (was immer das heißen soll) und zur beliebigen Änderung der Schreibrichtung bietet, kann das mit einem »Nein.« beantwortet werden. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge erreichen. Aber auch das betrifft dann zunächst nur den Weg, auf dem das PDF erzeugt wird. Darauf, wie gut das Ausgabeprogramm, das ja letztlich die Fonts rendert, das dann umsetzt, hat der Weg wenig Einfluss und ist unabhängig vom Ausgabeprogramm nicht wirklich vorhersehbar. Außerdem ist der Aufwand, so etwas umzusetzen dann in luaTeX vermutlich bedeutend aufwändiger als einen fertig gesetzten Text zu rotieren. Immerhin gibt es bei luaTeX und XeTeX die Möglichkeit, Fonts in anderen Formaten als bei TeX, das sich ausschließlich für TFM-Metriken interessiert, zu verarbeiten. Damit können theoretisch auch OTF-Features verwendet werden, die nachträglich Einfluss auf die Ausrichtung und Form von Glyphen im Font nehmen. Derzeitige Font-Loader bieten das aber so wenig wie der Typesetter bisher beliebige Schreibrichtungen unterstützt. Bei luaTeX könne man natürlich weitgehenden Einfluss auf den Typesetter und diesen letztlich sogar ersetzen. Der Aufwand dafür dürfte aber um ein Vielfaches höher sein, als fertig gesetzten Text zu drehen. Anekdote am Rande: Vor ca. fünfzehn Jahren, als es noch üblich war, mit DVI zu arbeiten, war übrigens klar erkennbar, dass die Rotation erst vom Ausgabeprogramm vorgenommen wird. Da die meisten DVI-Treiber damals keine PostScript-Specials verarbeitet haben oder nur für das Rendern von Bildern ghostscript aufgerufen haben, wurden im DVI-Viewer gedrehte Objekte ungedreht angezeigt und ragten dann natürlich auch nicht selten in andere Seitenelemente hinein. Erst, wenn man dvips angeworfen und anschließend die PostScript-Datei angeschaut hat, hat man das tatsächliche Ergebnis gesehen. Das hat man aber nicht bei jedem LaTeX-Lauf gemacht, weil die Rechner dafür nicht schnell genug waren. Heute können selbst DVI-Viewer diverse PostScript-Specials interpretieren, kommen aber kaum noch zur Anwendung.

Da sich TeX bekanntlich nicht für die Glyphen eines Fonts, sondern nur für deren (rechteckige) Ausdehnung interessiert, ist mir nicht klar, was unter »frei drehbaren Fonts in LaTeX« zu verstehen sein soll. Ich lese aus der Frage außerdem die Annahme, dass die Rotation mit einem der bekannten Pakete, beispielsweise `graphics`, `graphicx`, `lscape`, `pdflscape`, `rotating` und wie sie alle heißen mögen, aus der Tabelle (oder aus welchem Inhalt auch immer) zunächst eine Art *Bildobjekt* rendert und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das möchte. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale Auflösung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann dreht ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch explizit skaliert wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das heutzutage sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Außerdem bietet TeX selbst keinen Mechanismus, um *einen Font zu drehen*. Beides wäre jedoch notwendig, um unter Beibehaltung von Kerning etc. Text korrekt entlang eines Pfades etwa um 90° gedreht zu setzen. Es gibt zwar Fonts beispielsweise mit auf dem Kopf stehenden Glyphen. Es bleibt aber dabei, dass TeX keine Mechanismen für den Satz in beliebigen Schreibrichtungen bietet. Außerdem war die Frage ja nicht ob Font mit gedrehten Zeichen existieren, sondern ob es frei rotierbare Fonts für TeX gibt. Da TeX keinen Mechanismus zur Rotation von Fonts (was immer das heißen soll) und zur beliebigen Änderung der Schreibrichtung bietet, kann das mit einem »Nein.« beantwortet werden. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge erreichen. Aber auch das betrifft dann zunächst nur den Weg, auf dem das PDF erzeugt wird. Darauf, wie gut das ~~Ausgabeprogramm~~ Ausgabeprogramm, das ja letztlich die Fonts rendert, das dann umsetzt, hat der Weg wenig Einfluss und ist unabhängig vom Ausgabeprogramm nicht wirklich ~~vorhersehbar.~~ vorhersehbar. Außerdem ist der Aufwand, so etwas umzusetzen dann in luaTeX vermutlich bedeutend aufwändiger als einen fertig gesetzten Text zu rotieren. Immerhin gibt es bei luaTeX und XeTeX die Möglichkeit, Fonts in anderen Formaten als bei TeX, das sich ausschließlich für TFM-Metriken interessiert, zu verarbeiten. Damit können theoretisch auch OTF-Features verwendet werden, die nachträglich Einfluss auf die Ausrichtung und Form von Glyphen im Font nehmen. Derzeitige Font-Loader bieten das aber so wenig wie der Typesetter bisher beliebige Schreibrichtungen unterstützt. Bei luaTeX könne man natürlich weitgehenden Einfluss auf den Typesetter und diesen letztlich sogar ersetzen. Der Aufwand dafür dürfte aber um ein Vielfaches höher sein, als fertig gesetzten Text zu drehen. Anekdote am Rande: Vor ca. fünfzehn Jahren, als es noch üblich war, mit DVI zu arbeiten, war übrigens klar erkennbar, dass die Rotation erst vom Ausgabeprogramm vorgenommen wird. Da die meisten DVI-Treiber damals keine PostScript-Specials verarbeitet haben oder nur für das Rendern von Bildern ghostscript aufgerufen haben, wurden im DVI-Viewer gedrehte Objekte ungedreht angezeigt und ragten dann natürlich auch nicht selten in andere Seitenelemente hinein. Erst, wenn man dvips angeworfen und anschließend die PostScript-Datei angeschaut hat, hat man das tatsächliche Ergebnis gesehen. Das hat man aber nicht bei jedem LaTeX-Lauf gemacht, weil die Rechner dafür nicht schnell genug waren. Heute können selbst DVI-Viewer diverse PostScript-Specials interpretieren, kommen aber kaum noch zur Anwendung.

Ich lese aus der Frage die Annahme, dass die Rotation mit einem der bekannten Pakete, beispielsweise `graphics`, `graphicx`, `lscape`, `pdflscape`, `rotating` und wie sie alle heißen mögen, aus der Tabelle (oder aus welchem Inhalt auch immer) zunächst eine Art *Bildobjekt* rendert und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das möchte. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale Auflösung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann dreht ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch explizit skaliert wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das heutzutage sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge erreichen. Aber auch das betrifft dann zunächst nur den Weg, auf dem das PDF erzeugt wird. Darauf, wie gut das Ausgabeprogramm das dann umsetzt, hat der Weg wenig Einfluss und ist unabhängig vom Ausgabeprogramm nicht wirklich ~~vorhersehbar.~~vorhersehbar. Anekdote am Rande: Vor ca. fünfzehn Jahren, als es noch üblich war, mit DVI zu arbeiten, war übrigens klar erkennbar, dass die Rotation erst vom Ausgabeprogramm vorgenommen wird. Da die meisten DVI-Treiber damals keine PostScript-Specials verarbeitet haben oder nur für das Rendern von Bildern ghostscript aufgerufen haben, wurden im DVI-Viewer gedrehte Objekte ungedreht angezeigt und ragten dann natürlich auch nicht selten in andere Seitenelemente hinein. Erst, wenn man dvips angeworfen und anschließend die PostScript-Datei angeschaut hat, hat man das tatsächliche Ergebnis gesehen. Das hat man aber nicht bei jedem LaTeX-Lauf gemacht, weil die Rechner dafür nicht schnell genug waren. Heute können selbst DVI-Viewer diverse PostScript-Specials interpretieren, kommen aber kaum noch zur Anwendung.

Ich lese aus der Frage die Annahme, dass die Rotation mit einem der bekannten Pakete, beispielsweise `graphics`, `graphicx`, `lscape`, ~~`pdflscape`~~ `pdflscape`, `rotating` und wie sie alle heißen mögen, aus der Tabelle (oder aus welchem Inhalt auch immer) zunächst eine Art *Bildobjekt* rendert und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das möchte. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale Auflösung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann dreht ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch explizit skaliert wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das heutzutage sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge erreichen. Aber auch das betrifft dann zunächst nur den Weg, auf dem das PDF erzeugt wird. Darauf, wie gut das Ausgabeprogramm das dann umsetzt, hat der Weg wenig Einfluss und ist unabhängig vom Ausgabeprogramm nicht wirklich vorhersehbar.

Ich lese aus der Frage die Annahme, dass die Rotation mit einem der bekannten ~~Pakete~~ Pakete, beispielsweise `graphics`, `graphicx`, `lscape`, `pdflscape` und wie sie alle heißen mögen, aus der Tabelle zunächst eine Art *Bildobjekt* ~~macht~~ rendert und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das möchte. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale Auflösung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann dreht ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch explizit skaliert wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das heutzutage sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge erreichen. Aber auch das betrifft dann zunächst nur den Weg, auf dem das PDF erzeugt wird. Darauf, wie gut das Ausgabeprogramm das dann umsetzt, hat der Weg wenig Einfluss und ist unabhängig vom Ausgabeprogramm nicht wirklich vorhersehbar.

Ich lese aus der Frage die Annahme, dass die Rotation mit einem der bekannten Pakete `graphics`, `graphicx`, `lscape`, `pdflscape` und wie sie alle heißen mögen, aus der Tabelle zunächst eine Art *Bildobjekt* macht und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das möchte. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale Auflösung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann dreht ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch explizit skaliert wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das heutzutage sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge ~~erreichen.~~erreichen. Aber auch das betrifft dann zunächst nur den Weg, auf dem das PDF erzeugt wird. Darauf, wie gut das Ausgabeprogramm das dann umsetzt, hat der Weg wenig Einfluss und ist unabhängig vom Ausgabeprogramm nicht wirklich vorhersehbar.

Ich lese aus der Frage die Annahme, dass die Rotation mit einem der bekannten Pakete `graphics`, `graphicx`, `lscape`, `pdflscape` und wie sie alle heißen mögen, aus der Tabelle zunächst eine Art *Bildobjekt* macht und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das möchte. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale ~~Ausrichtung~~ Auflösung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann ~~dreht,~~ dreht ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch explizit skaliert wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das heutzutage sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge erreichen.

~~Es wäre falsch, anzunehmen,~~ Ich lese aus der Frage die Annahme, dass die Rotation mit einem der bekannten Pakete `graphics`, `graphicx`, `lscape`, `pdflscape` und wie sie alle heißen mögen, aus der Tabelle zunächst eine Art *Bildobjekt* macht und dann dieses dreht. Das ist aber nicht so. Stattdessen werden auf TeX-Seite ganz normale Boxen mit ganz normalem Inhalt gesetzt und lediglich in die PS- (via DVI-) oder PDF-Datei spezielle Anweisungen geschrieben, die angeben, dass dieses Element der Seite zu drehen ist. Die Drehung wird also beim Weg über PostScript vom PostScript-Interpreter und beim Weg über PDF vom PDF-Treiber (meist ein PDF-Viewer oder PDF-Druckertreiber) durchgeführt. Dabei machen diese genau das, was sie immer machen, wenn sie drehen sollen. Letztlich passiert dabei also genau dasselbe, wie wenn man direkt in PostScript oder PDF eine Änderung der Ausrichtung eines Objekts angibt. Man hat also tatsächlich Objekte in anderer Ausrichtung in der Datei. Für Fonts läuft das also auf dasselbe hinaus, wie wenn man gleich in Richtung eines bestimmten Pfades schreibt. Dabei hat die Rotation eines kompletten Textblocks in der Regel sogar Vorteile gegenüber der Rotation einzelner Buchstaben. Aber natürlich kann man auch Zeichen für Zeichen rotieren, wenn man das möchte. Verzerrung entsteht übrigens bei 90°- oder 180°-Drehungen genau dann, wenn entweder die horizontale und vertikale Ausrichtung nicht identisch sind und das Ausgabeprogramm tatsächlich erst rendert und dann dreht, ohne dies zu berücksichtigen, oder wenn zusätzlich zur Rotation noch skaliert ~~wird.~~wird. Bei Drehungen um andere Winkel hängt die Qualität der Drehung vom Ausgabeprogramm ab. Meist funktioniert das sehr gut. Natürlich kann ich nicht ausschließen, dass in bestimmten Fällen dabei Probleme auftreten. Die Ursache müsste man dann am konkreten Fall klären. Ob es dabei einen Nutzen hätte, zuerst die Zeichen eines Fonts zu rotieren, statt den fertigen Text zu rotieren sei dahin gestellt. TeX selbst kennt jedenfalls nur eine Schreibrichtung. Bei luaTeX sieht das etwas anders aus. Vor allem zusammen mit der Metapost-Engine, die dort eingebaut ist, könnte man extreme Dinge erreichen.