info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Ein Häkchen rechts an sqrt
5 views
Skip to first unread message
Joerg Fischer
Dec 18, 2022, 3:22:37 AM12/18/22
to
Hallo Welt,
zur besseren Abgrenzung einer Wurzel wünsche ich mir am rechten Ende ein
kleines Häkchen. Gurgel brachte mich zu
https://de.comp.text.tex.narkive.com/AT0lr6bz/wurzel-haken und das
funktioniert auch soweit, aber nur für Quadratwurzeln. Bei \sqrt[x]{y}
entsteht ohne eine Fehlermeldung eine kaputte Ausgabe im PDF.
Ehrlich gesagt, meine Kenntnisse über LaTeX sind bei solchem Code
überfordert. Ich hab ohne zu verstehen was passiert einfach mit c&p
eingefügt. Was passt an dem Code nicht? Gibt es eine andere Lösung für
das Problem? Ein Stups in die richtige Richtung wäre nett. ;-.)
Ich übersetze mit xelatex auf einem Ubuntu 22.04 und den
Standardpaketen von texlive.
Minimalbeispiel:
\documentclass{scrreprt}
\usepackage[babelshorthands]{polyglossia}
\def\hksqrt{\mathpalette\DHLhksqrt}
\def\DHLhksqrt#1#2{\setbox0=\hbox{$#1\sqrt{#2\,}$}\dimen0=\ht0
\advance\dimen0-0.2\ht0
%0.2 ist das Maß für die Hakenlänge, relativ zum Inhalt der Wurzel
\setbox2=\hbox{\vrule height\ht0 depth -\dimen0}%
{\box0\lower0.4pt\box2}}
\begin{document}
Funktioniert: \( \sqrt{5+2+4}+4+5 \)
Funktioniert: \( \sqrt[3]{5+2+4}+4+5 \)
Funktioniert: \( \hksqrt{5+2+4}+4+5 \)
Funktioniert nicht: \( \hksqrt[3]{5+2+4}+4+5 \)
\end{document}
VG Jörg
zur besseren Abgrenzung einer Wurzel wünsche ich mir am rechten Ende ein
kleines Häkchen. Gurgel brachte mich zu
https://de.comp.text.tex.narkive.com/AT0lr6bz/wurzel-haken und das
funktioniert auch soweit, aber nur für Quadratwurzeln. Bei \sqrt[x]{y}
entsteht ohne eine Fehlermeldung eine kaputte Ausgabe im PDF.
Ehrlich gesagt, meine Kenntnisse über LaTeX sind bei solchem Code
überfordert. Ich hab ohne zu verstehen was passiert einfach mit c&p
eingefügt. Was passt an dem Code nicht? Gibt es eine andere Lösung für
das Problem? Ein Stups in die richtige Richtung wäre nett. ;-.)
Ich übersetze mit xelatex auf einem Ubuntu 22.04 und den
Standardpaketen von texlive.
Minimalbeispiel:
\documentclass{scrreprt}
\usepackage[babelshorthands]{polyglossia}
\def\hksqrt{\mathpalette\DHLhksqrt}
\def\DHLhksqrt#1#2{\setbox0=\hbox{$#1\sqrt{#2\,}$}\dimen0=\ht0
\advance\dimen0-0.2\ht0
%0.2 ist das Maß für die Hakenlänge, relativ zum Inhalt der Wurzel
\setbox2=\hbox{\vrule height\ht0 depth -\dimen0}%
{\box0\lower0.4pt\box2}}
\begin{document}
Funktioniert: \( \sqrt{5+2+4}+4+5 \)
Funktioniert: \( \sqrt[3]{5+2+4}+4+5 \)
Funktioniert: \( \hksqrt{5+2+4}+4+5 \)
Funktioniert nicht: \( \hksqrt[3]{5+2+4}+4+5 \)
\end{document}
VG Jörg
Engelbert Buxbaum
Dec 18, 2022, 9:14:27 AM12/18/22
to
Joerg Fischer schrieb am Sonntag, 18. Dezember 2022 um 09:22:37 UTC+1:
> zur besseren Abgrenzung einer Wurzel wünsche ich mir am rechten Ende ein
> kleines Häkchen.
%% "closed" sqrt sign, https://tex.stackexchange.com/questions/29834/closed-square-root-symbol
> zur besseren Abgrenzung einer Wurzel wünsche ich mir am rechten Ende ein
> kleines Häkchen.
\makeatletter
\let\oldr@@t\r@@t
\def\r@@t#1#2{%
\setbox0=\hbox{$\oldr@@t#1{#2\,}$}\dimen0=\ht0
\advance\dimen0-0.2\ht0
\setbox2=\hbox{\vrule height\ht0 depth -\dimen0}%
{\box0\lower0.4pt\box2}}
\LetLtxMacro{\oldsqrt}{\sqrt}
{\box0\lower0.4pt\box2}}
\renewcommand*{\sqrt}[2][\ ]{\oldsqrt[#1]{#2}}
\makeatother
\begin{equation}
x = \sqrt[3]{(1+2+3)}
\end{equation}
funktioniert schon ganz gut, aber die [3] müßte etwas höher und weiter links stehen. Kann jemand das verbessern?
Joerg Fischer
Dec 21, 2022, 3:08:04 AM12/21/22
to
Engelbert Buxbaum <engelber...@gmail.com> wrote:
> \makeatletter
> \let\oldr@@t\r@@t
> \def\r@@t#1#2{%
> \setbox0=\hbox{$\oldr@@t#1{#2\,}$}\dimen0=\ht0
> \advance\dimen0-0.2\ht0
> \setbox2=\hbox{\vrule height\ht0 depth -\dimen0}%
> {\box0\lower0.4pt\box2}}
> \LetLtxMacro{\oldsqrt}{\sqrt}
> \renewcommand*{\sqrt}[2][\ ]{\oldsqrt[#1]{#2}}
> \makeatother
Hübsch.
> \makeatletter
> \let\oldr@@t\r@@t
> \def\r@@t#1#2{%
> \setbox0=\hbox{$\oldr@@t#1{#2\,}$}\dimen0=\ht0
> \advance\dimen0-0.2\ht0
> \setbox2=\hbox{\vrule height\ht0 depth -\dimen0}%
> {\box0\lower0.4pt\box2}}
> \LetLtxMacro{\oldsqrt}{\sqrt}
> \renewcommand*{\sqrt}[2][\ ]{\oldsqrt[#1]{#2}}
> \makeatother
> funktioniert schon ganz gut, aber die [3] müßte etwas höher und
> weiter links stehen.
> Kann jemand das verbessern?
Theoretisch würde \sqrt[\uproot{4}\frac{3}{5}]{5+2+4} helfen, aber
jetzt rutscht der Haken mit dem uproot mit...
Tschau, Jörg
Ulrich D i e z
Dec 26, 2022, 10:16:26 AM12/26/22
to
Am 18.12.22 um 09:22 schrieb Joerg Fischer:
> zur besseren Abgrenzung einer Wurzel wünsche ich mir am rechten Ende ein
> kleines Häkchen.
Immer dieses Abgrenzen... ;-)
> Gurgel brachte mich zu
> https://de.comp.text.tex.narkive.com/AT0lr6bz/wurzel-haken und das
> funktioniert auch soweit, aber nur für Quadratwurzeln. Bei \sqrt[x]{y}
> entsteht ohne eine Fehlermeldung eine kaputte Ausgabe im PDF.
> Ehrlich gesagt, meine Kenntnisse über LaTeX sind bei solchem Code
> überfordert. Ich hab ohne zu verstehen was passiert einfach mit c&p
> eingefügt. Was passt an dem Code nicht?
Der ergurgelte Code für \hksqrt berücksichtigt im Gegensatz zu
\sqrt keine optionalen Argumente und hält ggfs stillschweigend
das Zeichen [ für das, was unter der Wurzel stehen soll.
> Gibt es eine andere Lösung für
> das Problem? Ein Stups in die richtige Richtung wäre nett. ;-.)
Beim Ausmessen der Box aus der man die (vertikale) Höhe des
Strichleins erhält, das optionale Argument nicht mitmessen,
sodass es nicht zur Höhe der Box beiträgt:
\documentclass{scrreprt}
%\usepackage{xparse}
%\usepackage[babelshorthands]{polyglossia}
\usepackage{amsmath}
\newbox\scratchbox
\NewDocumentCommand\hksqrt{om}{%
\IfNoValueTF{#1}{%
\mathpalette\DHLhksqrt{{}{{#2\,}}}%
}{%
\mathpalette\DHLhksqrt{{[{#1}]}{{#2\,}}}%
}%
}
\newcommand*\DHLhksqrt[2]{\DHLhksqrtmeasure{#1}#2}%
\newcommand*\DHLhksqrtmeasure[3]{%
% #1 = \displaystyle/\textstyle/\scriptstyle/\scriptscriptstyle;
% wird von \mathpalette in den Argumenten von \mathchoice gesetzt
% #2 = Leer oder optionales Argument von \hksqrt
% #3 = Pflichtargument von \hksqrt
\setbox\scratchbox=\hbox{$#1\sqrt#3$}%
\hbox{$#1\sqrt#2#3$%
\kern-.4pt
\vrule height\dimexpr\ht\scratchbox-.5pt\relax
depth -\dimexpr0.8\ht\scratchbox-.5pt\relax
width .4pt %
}%
}%
\begin{document}
Test 1: \( \sqrt{5+2+4}+4+5 \)
Test 2: \( \sqrt[3]{5+2+4}+4+5 \)
Test 3: \( \hksqrt{5+2+4}+4+5 \)
Test 4: \( \hksqrt[3]{5+2+4}+4+5 \)
Test 5: \[ \sqrt{5+2+4}+4+5 \]
Test 6: \[ \sqrt[3]{5+2+4}+4+5 \]
Test 7: \[ \hksqrt{5+2+4}+4+5 \]
Test 8: \[ \hksqrt[3]{5+2+4}+4+5 \]
Test 9:
\begin{equation}
x = \hksqrt[\uproot{4}\frac{3}{5}]{5+2+4}+4+5
\end{equation}
Test 10:
\begin{equation}
x = \sqrt[\uproot{4}\frac{3}{5}]{5+2+4}+4+5
\end{equation}
\end{document}
Mit freundlichem Gruß
Ulrich
> zur besseren Abgrenzung einer Wurzel wünsche ich mir am rechten Ende ein
> kleines Häkchen.
> Gurgel brachte mich zu
> https://de.comp.text.tex.narkive.com/AT0lr6bz/wurzel-haken und das
> funktioniert auch soweit, aber nur für Quadratwurzeln. Bei \sqrt[x]{y}
> entsteht ohne eine Fehlermeldung eine kaputte Ausgabe im PDF.
> Ehrlich gesagt, meine Kenntnisse über LaTeX sind bei solchem Code
> überfordert. Ich hab ohne zu verstehen was passiert einfach mit c&p
> eingefügt. Was passt an dem Code nicht?
\sqrt keine optionalen Argumente und hält ggfs stillschweigend
das Zeichen [ für das, was unter der Wurzel stehen soll.
> Gibt es eine andere Lösung für
> das Problem? Ein Stups in die richtige Richtung wäre nett. ;-.)
Strichleins erhält, das optionale Argument nicht mitmessen,
sodass es nicht zur Höhe der Box beiträgt:
\documentclass{scrreprt}
%\usepackage{xparse}
%\usepackage[babelshorthands]{polyglossia}
\usepackage{amsmath}
\newbox\scratchbox
\NewDocumentCommand\hksqrt{om}{%
\IfNoValueTF{#1}{%
\mathpalette\DHLhksqrt{{}{{#2\,}}}%
}{%
\mathpalette\DHLhksqrt{{[{#1}]}{{#2\,}}}%
}%
}
\newcommand*\DHLhksqrt[2]{\DHLhksqrtmeasure{#1}#2}%
\newcommand*\DHLhksqrtmeasure[3]{%
% #1 = \displaystyle/\textstyle/\scriptstyle/\scriptscriptstyle;
% wird von \mathpalette in den Argumenten von \mathchoice gesetzt
% #2 = Leer oder optionales Argument von \hksqrt
% #3 = Pflichtargument von \hksqrt
\setbox\scratchbox=\hbox{$#1\sqrt#3$}%
\hbox{$#1\sqrt#2#3$%
\kern-.4pt
\vrule height\dimexpr\ht\scratchbox-.5pt\relax
depth -\dimexpr0.8\ht\scratchbox-.5pt\relax
width .4pt %
}%
}%
\begin{document}
Test 1: \( \sqrt{5+2+4}+4+5 \)
Test 2: \( \sqrt[3]{5+2+4}+4+5 \)
Test 3: \( \hksqrt{5+2+4}+4+5 \)
Test 4: \( \hksqrt[3]{5+2+4}+4+5 \)
Test 5: \[ \sqrt{5+2+4}+4+5 \]
Test 6: \[ \sqrt[3]{5+2+4}+4+5 \]
Test 7: \[ \hksqrt{5+2+4}+4+5 \]
Test 8: \[ \hksqrt[3]{5+2+4}+4+5 \]
Test 9:
\begin{equation}
x = \hksqrt[\uproot{4}\frac{3}{5}]{5+2+4}+4+5
\end{equation}
Test 10:
\begin{equation}
x = \sqrt[\uproot{4}\frac{3}{5}]{5+2+4}+4+5
\end{equation}
\end{document}
Mit freundlichem Gruß
Ulrich
Joerg Fischer
Dec 31, 2022, 5:08:03 AM12/31/22
to
Ulrich D i e z <ud.usenetco...@web.de> wrote:
> \NewDocumentCommand\hksqrt{om}{%
Cool. Das funktioniert prima. Danke! Wieviel LaTeX-Erfahrung braucht
man bis man auf sowas kommt? Also ich kenne durchaus einige
Programmiersprachen und benutze LaTeX auch nicht erst seit vorgestern,
aber das ist schon... heftiger Code...
Tschau, Jörg
> \NewDocumentCommand\hksqrt{om}{%
Cool. Das funktioniert prima. Danke! Wieviel LaTeX-Erfahrung braucht
man bis man auf sowas kommt? Also ich kenne durchaus einige
Programmiersprachen und benutze LaTeX auch nicht erst seit vorgestern,
aber das ist schon... heftiger Code...
Tschau, Jörg
Ulrich D i e z
Dec 31, 2022, 10:20:18 AM12/31/22
to
Joerg Fischer schrieb:
> Ulrich D i e z <ud.usenetco...@web.de> wrote:
>
>> \NewDocumentCommand\hksqrt{om}{%
>
> Cool. Das funktioniert prima.
Es ist auch nur ein Workaround, der nicht genau nachvollzieht, was
(La)TeX beim Setzen von Wurzelzeichen genau tut.
> Danke! Wieviel LaTeX-Erfahrung braucht
> man bis man auf sowas kommt?
Ich weiß nicht, wie man LaTeX-Erfahrung quantifizieren soll. ;-)
> Also ich kenne durchaus einige Programmiersprachen
> und benutze LaTeX auch nicht erst seit vorgestern,
Zum Glück hast du nicht gesagt, dass (La)TeX eine Programmiersprache
sei. ;-)
Solche Statements haben nämlich schon lustigste Debatten nach sich
gezogen.
TeX ist zwar angeblich "Turing complete", aber es gibt Leute, die
sagen, TeX/LaTeX sei keine Programmiersprache, sondern eine
Textsatzsprache.
Auch Knuth bezeichnet TeX im TeXbook nie explizit als Programmiersprache,
sondern allgemein als "Sprache", und im Preface des TeXbook ist in
Zusammenhang mit dem Vorgänger des derzeitigen TeX, TeX78, von "attempt
at a document formatting language" die Rede.
In einem Double-Dangerous-Bend-Absatz in Chapter 20: Definitions (also
called Macros) wird aber darauf aufmerksam gemacht, dass man TeX als
primitive Programmiersprache verwenden kann:
| Appendices B, D, and E contain numerous examples of how to make macros
| do useful things. Let’s close this chapter by presenting a few examples that
| show how TeX can actually be used as a primitive programming language, if you want
| to achieve special effects, and if you don’t care very much about computer costs.
Außerdem wird in Chapter 24: Summary of Vertical Mode ein Zusammenhang zu
"Computersprachen" hergestellt:
| We shall define TeX’s parts of speech by using a modified form of the gram-
| matical notation that was introduced about 1960 by John Backus and Peter Naur for
| the definition of computer languages.
Es wird aber nirgendwo explizit gesagt, dass TeX eine Programmiersprache sei.
Da man beim Lesen des TeXbook extrem griffelspitzig sein muss, weil
viel Information sehr komprimiert dargestellt wird, nehme ich an, dass
absichtlich vermieden wurde, TeX als Programmiersprache zu bezeichnen.
> aber das ist schon... heftiger Code...
Als ich in TeX/LaTeX einstieg, kam mir vieles auch "heftig" vor, was aber
hauptsächlich daran lag, dass ich anfangs darin verhaftet war, mein Wissen
über prozedur-, funktions- und objektorientierte Programmiersprachen wie
Pascal, C, C++, Java etc auf (La)TeX übertragen zu wolllen - in der Annahme,
mir dadurch ersparen zu können, mir die Grundlagen darüber, wie TeX
funktioniert, unter Verwendung der von Donald E. Knuth in seinem TeXbook
erklärten Konzepte und in Zusammenhang mit diesen Konzepten eingeführten
Begriffe anzueignen.
Da TeX
- keine solche Programmiersprache sondern eine Textsatzsprache ist,
- das geschriebene TeX-Programm zur Laufzeit des Compilers ausführt
und die dabei entstehenden Resultate verwendet, um eine Ausgabedatei
(dvi oder pdf) mit gesetztem Text und/oder Hilfsdateien und/oder
Meldungen an der Konsole zu erzeugen, anstatt das geschriebene
Programm in Maschinencode zu übersetzen, der durch Aufruf der
ausführbaren Datei auf der Maschine ausgeführt wird,
- verschiedene Ebenen/"Verdauungsstadien" des Verarbeitens von TeX-
Eingabedateien hat, die man beim Programmieren in TeX berücksichtigen
muss -- zB ist das Stadium, in dem Makros definiert werden und andere
Assignments stattfinden - diese Dinge finden im "Magen" von TeX statt,
ein anderes als das Stadium, in dem Expansion stattfindet
(Expansion, d.h., Ersetzen von Makros und anderen expandierbaren
Token und deren Argumenten durch Token, die den Ersetzungstext
bilden, findet in der "Speiseröhre" von TeX statt),
- ein "Verdauungsstadium" hat, im TeXbook in der Analogie zu einem
lebenden Organismus mit Verdauungstrakt "gullet"="Speiseröhre" genannt,
in welchem alle Expansion erledigt wird, wobei Konzepte wie Token,
Primitive, Makro und Makroargument und Expansion eine Rolle spielen,
sodass man sich beim Programmieren überlegen kann,
- ob man für dieses Stadium/die Speiseröhre programmiert, also so
programmiert, das der programmierte "Mechanismus" schon in der
"Speiseröhre" von TeX vollständig abläuft, und dafür zB Makros
definiert, die sich zB rekursiv gegenseitig aufrufen und dabei
ihre Argumente als "Variablen" benutzen, wobei die als Argumente
übergebenen Zusammenstellungen an Token die Werte der Variablen im
betreffenden Expansionssschritt darstellen,
- oder auch den "Magen" miteinbezieht, also zB einen "Mechanismus"
programmiert, der auch Assignments ausführt, zB Hilfsmakros
umdefiniert, Boxen für Box-Register setzt, deren Maßangaben man
dann mittels \dp/\ht/\wd erhalten kann, Token-Registern einen
Inhalt zuweist, etc
, man sich bei TeX also weit mehr mit der Frage befassen muss, in
welches (Verdauungs-)Stadium des Verarbeitens der .tex-Eigabedatei man
mit seiner Programmiererei eingreifen will, als man das bei herkömmlichen
Programmiersprachen muss; auch bei LuaTeX mit seinen Möglichkeiten,
mittels in der Programmiersprache Lua gschriebenen Routinen in die
Abläufe von TeX einzugreifen, spielt die Frage, in welches
(Verdauungs-)Stadium des Verarbeitens der .tex-Eigabedatei durch TeX
man eingreifen möchte, eine große Rolle
, kann man die Übertragung von aus anderen Programmiersprachen geläufigen
Konzepten meiner Meinung nach nur dann erfolgreich bewerkstelligen, wenn
man die Unterschiede zwischen diesen Programmiersprachen und TeX kennt, was
wiederum heißt, dass man mit den Grundkonzepten der Funktionsweise von
TeX und damit auch mit den von Knuth in diesem Zusammenhang eingeführten
Begriffen vertraut sein muss.
Als ich dazu überging, beim Programmieren in TeX nicht mehr ausgehend
von dem denken zu wollen, was ich über das Programmieren in anderen
Sprachen wusste, sondern ausgehend von den im TeXbook für TeX erklärten
Konzepten und Begriffen, fing es an, mir viel leichter zu fallen.
Die Profis in den Newsgroups comp.text.tex und de.comp.text.tex
und auf der Plattform TeX-LaTeX-StackExchange haben mir sehr geholfen
und helfen mir sehr, zu verstehen, wie in TeX die Dinge
ineinandergreifen.
Mit freundlichem Gruß
Ulrich
> Ulrich D i e z <ud.usenetco...@web.de> wrote:
>
>> \NewDocumentCommand\hksqrt{om}{%
>
> Cool. Das funktioniert prima.
(La)TeX beim Setzen von Wurzelzeichen genau tut.
> Danke! Wieviel LaTeX-Erfahrung braucht
> man bis man auf sowas kommt?
> Also ich kenne durchaus einige Programmiersprachen
> und benutze LaTeX auch nicht erst seit vorgestern,
sei. ;-)
Solche Statements haben nämlich schon lustigste Debatten nach sich
gezogen.
TeX ist zwar angeblich "Turing complete", aber es gibt Leute, die
sagen, TeX/LaTeX sei keine Programmiersprache, sondern eine
Textsatzsprache.
Auch Knuth bezeichnet TeX im TeXbook nie explizit als Programmiersprache,
sondern allgemein als "Sprache", und im Preface des TeXbook ist in
Zusammenhang mit dem Vorgänger des derzeitigen TeX, TeX78, von "attempt
at a document formatting language" die Rede.
In einem Double-Dangerous-Bend-Absatz in Chapter 20: Definitions (also
called Macros) wird aber darauf aufmerksam gemacht, dass man TeX als
primitive Programmiersprache verwenden kann:
| Appendices B, D, and E contain numerous examples of how to make macros
| do useful things. Let’s close this chapter by presenting a few examples that
| show how TeX can actually be used as a primitive programming language, if you want
| to achieve special effects, and if you don’t care very much about computer costs.
Außerdem wird in Chapter 24: Summary of Vertical Mode ein Zusammenhang zu
"Computersprachen" hergestellt:
| We shall define TeX’s parts of speech by using a modified form of the gram-
| matical notation that was introduced about 1960 by John Backus and Peter Naur for
| the definition of computer languages.
Es wird aber nirgendwo explizit gesagt, dass TeX eine Programmiersprache sei.
Da man beim Lesen des TeXbook extrem griffelspitzig sein muss, weil
viel Information sehr komprimiert dargestellt wird, nehme ich an, dass
absichtlich vermieden wurde, TeX als Programmiersprache zu bezeichnen.
> aber das ist schon... heftiger Code...
hauptsächlich daran lag, dass ich anfangs darin verhaftet war, mein Wissen
über prozedur-, funktions- und objektorientierte Programmiersprachen wie
Pascal, C, C++, Java etc auf (La)TeX übertragen zu wolllen - in der Annahme,
mir dadurch ersparen zu können, mir die Grundlagen darüber, wie TeX
funktioniert, unter Verwendung der von Donald E. Knuth in seinem TeXbook
erklärten Konzepte und in Zusammenhang mit diesen Konzepten eingeführten
Begriffe anzueignen.
Da TeX
- keine solche Programmiersprache sondern eine Textsatzsprache ist,
- das geschriebene TeX-Programm zur Laufzeit des Compilers ausführt
und die dabei entstehenden Resultate verwendet, um eine Ausgabedatei
(dvi oder pdf) mit gesetztem Text und/oder Hilfsdateien und/oder
Meldungen an der Konsole zu erzeugen, anstatt das geschriebene
Programm in Maschinencode zu übersetzen, der durch Aufruf der
ausführbaren Datei auf der Maschine ausgeführt wird,
- verschiedene Ebenen/"Verdauungsstadien" des Verarbeitens von TeX-
Eingabedateien hat, die man beim Programmieren in TeX berücksichtigen
muss -- zB ist das Stadium, in dem Makros definiert werden und andere
Assignments stattfinden - diese Dinge finden im "Magen" von TeX statt,
ein anderes als das Stadium, in dem Expansion stattfindet
(Expansion, d.h., Ersetzen von Makros und anderen expandierbaren
Token und deren Argumenten durch Token, die den Ersetzungstext
bilden, findet in der "Speiseröhre" von TeX statt),
- ein "Verdauungsstadium" hat, im TeXbook in der Analogie zu einem
lebenden Organismus mit Verdauungstrakt "gullet"="Speiseröhre" genannt,
in welchem alle Expansion erledigt wird, wobei Konzepte wie Token,
Primitive, Makro und Makroargument und Expansion eine Rolle spielen,
sodass man sich beim Programmieren überlegen kann,
- ob man für dieses Stadium/die Speiseröhre programmiert, also so
programmiert, das der programmierte "Mechanismus" schon in der
"Speiseröhre" von TeX vollständig abläuft, und dafür zB Makros
definiert, die sich zB rekursiv gegenseitig aufrufen und dabei
ihre Argumente als "Variablen" benutzen, wobei die als Argumente
übergebenen Zusammenstellungen an Token die Werte der Variablen im
betreffenden Expansionssschritt darstellen,
- oder auch den "Magen" miteinbezieht, also zB einen "Mechanismus"
programmiert, der auch Assignments ausführt, zB Hilfsmakros
umdefiniert, Boxen für Box-Register setzt, deren Maßangaben man
dann mittels \dp/\ht/\wd erhalten kann, Token-Registern einen
Inhalt zuweist, etc
, man sich bei TeX also weit mehr mit der Frage befassen muss, in
welches (Verdauungs-)Stadium des Verarbeitens der .tex-Eigabedatei man
mit seiner Programmiererei eingreifen will, als man das bei herkömmlichen
Programmiersprachen muss; auch bei LuaTeX mit seinen Möglichkeiten,
mittels in der Programmiersprache Lua gschriebenen Routinen in die
Abläufe von TeX einzugreifen, spielt die Frage, in welches
(Verdauungs-)Stadium des Verarbeitens der .tex-Eigabedatei durch TeX
man eingreifen möchte, eine große Rolle
, kann man die Übertragung von aus anderen Programmiersprachen geläufigen
Konzepten meiner Meinung nach nur dann erfolgreich bewerkstelligen, wenn
man die Unterschiede zwischen diesen Programmiersprachen und TeX kennt, was
wiederum heißt, dass man mit den Grundkonzepten der Funktionsweise von
TeX und damit auch mit den von Knuth in diesem Zusammenhang eingeführten
Begriffen vertraut sein muss.
Als ich dazu überging, beim Programmieren in TeX nicht mehr ausgehend
von dem denken zu wollen, was ich über das Programmieren in anderen
Sprachen wusste, sondern ausgehend von den im TeXbook für TeX erklärten
Konzepten und Begriffen, fing es an, mir viel leichter zu fallen.
Die Profis in den Newsgroups comp.text.tex und de.comp.text.tex
und auf der Plattform TeX-LaTeX-StackExchange haben mir sehr geholfen
und helfen mir sehr, zu verstehen, wie in TeX die Dinge
ineinandergreifen.
Mit freundlichem Gruß
Ulrich
Joerg Fischer
Jan 1, 2023, 4:08:04 AM1/1/23
to
Ulrich D i e z <ud.usenetco...@web.de> wrote:
> Ich weiß nicht, wie man LaTeX-Erfahrung quantifizieren soll. ;-)
Ich auch nicht. :-) Ich bin halt nur "Anwender".
> Ich weiß nicht, wie man LaTeX-Erfahrung quantifizieren soll. ;-)
> Zum Glück hast du nicht gesagt, dass (La)TeX eine Programmiersprache
> sei. ;-)
> Als ich in TeX/LaTeX einstieg, kam mir vieles auch "heftig" vor, was aber
> hauptsächlich daran lag, dass ich anfangs darin verhaftet war, mein Wissen
> über prozedur-, funktions- und objektorientierte Programmiersprachen wie
> Pascal, C, C++, Java etc auf (La)TeX übertragen zu wolllen - in der Annahme,
stellen so, das ich, wenn ich eine LaTeX-Frage habe, die Frage Google
vorwerfe und meist eine Lösung bekomme. Die Antwort verstehe ich dann
zwar nicht, aber sie funktioniert. :-)
> Meldungen an der Konsole zu erzeugen, anstatt das geschriebene
> Programm in Maschinencode zu übersetzen, der durch Aufruf der
> ausführbaren Datei auf der Maschine ausgeführt wird,
"herkömmlichen Sprachen" kann ich auch.
> - ob man für dieses Stadium/die Speiseröhre programmiert, also so
> programmiert, das der programmierte "Mechanismus" schon in der
Companion (in deutsch), aber der ist ja auch mehr ein
"Anwenderhandbuch". Mein englisch ist so gut bzw. so schlecht das ich
Texte halbwegs lesen kann, aber ich muss mich anstrengen und wenn ich
schon den Text nur mit Mühe verstehe wird es schwierig so komplizierte
Inhalte zu erfassen.
> Die Profis in den Newsgroups comp.text.tex und de.comp.text.tex
> und auf der Plattform TeX-LaTeX-StackExchange haben mir sehr geholfen
hat mir schon oft geholfen.
VG, Jörg
0 new messages