goLaTeX - Mein LaTeX-Forum

Mein LaTeX-Forum


Login  | Registrieren
Forum
      Option
[Erweitert]
  • Diese Seite weiterempfehlen
     


Gehe zu:  
Neues Thema eröffnen Neue Antwort erstellen

Grafik im Term einer Definitionsliste?

 

fs
Forum-Anfänger
Forum-Anfänger

Beiträge: 35
Anmeldedatum: 02.01.18
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 02.02.2018, 19:29     Titel: Grafik im Term einer Definitionsliste?
  Antworten mit Zitat      
Hallo,

ist es möglich, im Term einer Definitionsliste eine Grafik zu platzieren?

Also

\begin{description}
\item[<GRAFIK>] ...
...
\end{description}

Grüße
Frank
_________________

Dipl.-Inform. Frank Seitz
IT Consultant / {Web, Database, Linux} Developer + Admin
Tel: +49-176-78243503, Hauptstr. 32-34, D-25462 Rellingen

Blog: http://fseitz.de/blog

Zuletzt bearbeitet von fs am 03.02.2018, 09:59, insgesamt 2-mal bearbeitet
Private Nachricht senden Benutzer-Profile anzeigen

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 02.02.2018, 21:27     Titel:
  Antworten mit Zitat      
Ich bin versucht: »Ja.« zu antworten. Aber machen wir es anders: Was ist dabei das Problem? Bitte zeige ein InfoMinimalbeispiel und beachte dabei auch: Wie kann ich Code in meinem Beitrag hervorheben?

fs
Forum-Anfänger
Forum-Anfänger

Beiträge: 35
Anmeldedatum: 02.01.18
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 02.02.2018, 22:15     Titel:
  Antworten mit Zitat      
Die Frage ist, wie es geht. Ich habe es mit \includegraphics versucht, aber da stieg LaTeX aus. Inzwischen habe ich das Problem aber selbst lokalisiert und gelöst: Wenn \includegraphics Optionen hat, der Ausdruck also eckige Klammern besitzt, kann LaTeX damit nicht umgehen. Das Ganze in geschweifte Klammern zu setzen, hat es gelöst:

\item[{\includegraphics[...]{...}}]

Das sind so Stellen, an denen LaTeX unschöne Frickelei ist. Man fragt sich, warum das nicht sauber geparst wird.

Grüße
Frank
_________________

Dipl.-Inform. Frank Seitz
IT Consultant / {Web, Database, Linux} Developer + Admin
Tel: +49-176-78243503, Hauptstr. 32-34, D-25462 Rellingen

Blog: http://fseitz.de/blog
Private Nachricht senden Benutzer-Profile anzeigen

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 03.02.2018, 14:49     Titel:
  Antworten mit Zitat      
Genau deshalb wurde zurecht nach einem InfoMinimalbeispiel gefragt. In einem InfoMinimalbeispiel hätte man nämlich gesehen, was das Problem bei Dir ist.

Zur Frage nach den Argumenten: TeX kennt zwei Arten von Argumenten: balanced arguments und delimited arguments. Balanced arguments sind das, was die meisten Leute als Argument erkennen, nämlich ein Argument in geschweiften Klammern. Tatsächlich sind es entweder genau ein Token oder Listen von Token zwischen Argument-Anfang-Token und Argument-Ende-Token auf gleicher Ebene, wobei das Argument-Anfang-Token und das Argument-Ende-Token von TeX nach dem Parser weggeworfen werden. Geschweifte Klammern sind solche Argument-Anfang- und Argument-Ende-Token.

Eckige Klammern sind dagegen keine Argument-Anfang- und Argument-Ende-Token. Befehle mit eckigen Klammern sind daher per delimited argument in der Art:
Code • Öffne in Overleaf
\der\foo[#1]{}
definiert. Die Klammern sind also Teil der Definition. Das erste Argument endet mit dem ersten Auftreten des Begrenzers. Aber: #1 selbst ist dabei balanced text. Der einzige Unterschied zu einem normalen balanced argument ist, dass wenn das nachfolgende Token kein Argument-Anfang-Token ist, das Argument noch nicht endet, sondern eben erst am Ende des delimited arguments.

Das Problem ist also weniger, dass nicht richtig geparst wird, das Problem ist eher, dass wir alle zu faul sind, korrekt \item[{…}] zu schreiben und uns stattdessen auf das Delimiter-Feature verlassen. Bei Argument mit eckigen Klammern wundern wir uns dann und meckern, obwohl TeX ganz richtig gehandelt hat.

Übrigens kann man bei TeX aus der Sprache selbst heraus die Tokenerzeugung beeinflussen, indem man die Kategoriecodes der Zeichen ändert. Das führt dazu, dass man zum Parsen von TeX-Code eine Maschine benötigt, die TeX-Code expandieren kann. Man braucht also bis auf den Typesetter eine nahezu komplette TeX-Implementierung. Alles, was sonst so TeX-Code zu verarbeiten versucht, arbeitet mit Vereinfachungen, die nicht bei jedem TeX-Code funktionieren.

Näheres zur Funktionsweise von TeX ist »The TeXbook« zu entnehmen. Wenn man das liest, merkt man sehr schnell, das TeX eine extrem komplexe Sprache ist, und LaTeX zwar versucht, einiges dieser Komplexität vor dem Anwender zu verbergen, das aber natürlich nicht vollständig kann. TeX ist außerdem eine vergleichsweise alte Sprache. Die erste Implementierung stammt noch aus den 70ern. Wobei diese 1982 durch eine komplett neue Implementierung ersetzt wurde. Das Prinzip der Sprache blieb aber gleich. 1989 kam dann TeX3. Das war allerdings keine komplette Neuimplementierung. Es gab nur ein paar wenige, zusätzliche Primitive und die 7-Bit-Zeichen wurden durch 8-Bit-Zeichen ersetzt. Wenig später kam dann ɛ-TeX, das erneut ein paar Erweiterungen brachte. omega war ein erster Versuch, die 8-Bit-Begrenzung zu überwinden und Unicode direkt zu verarbeiten. pdfTeX brachte dagegen die direkte Erzeugung von PDF ohne Umweg über DVI und ebenfalls ein paar eigene Primitive. XeTeX brachte ebenfalls Unicode-Unterstützung in Form von UTF8, Unterstützung für Systemfonts und ein erweitertes DVI-Format, das dem Rechnung trägt und somit auch besser als Zwischenschritt für die PDF-Umwandlung taugt. LuaTeX schließlich begann als Nachfolger von pdfTeX mit eingebauter Lua-Engine, die über diverse Callbacks auch die Arbeitsweise von TeX verändern kann. Heute verwenden wir fast nur noch pdfTeX, XeTeX und LuaTeX, wobei die ersten beiden nichts an den Grundprinzipien von TeX ändern, während man bei LuaTeX von Lua-Seite aus an vielem rütteln kann. Bei LaTeX werden diese Möglichkeiten aber eher konservativ genutzt. Wenn Du etwas progressiveres suchst, solltest Du Dich mit ConTeXt beschäftigen.

fs
Forum-Anfänger
Forum-Anfänger

Beiträge: 35
Anmeldedatum: 02.01.18
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 03.02.2018, 15:59     Titel:
  Antworten mit Zitat      
Vielen Dank für die ausführliche Erläuterung. Es ist klar, dass TeX zu einer Zeit entstanden ist, wo man auf Rechnern mit heute unvorstellbaren Beschränkungen leben musste. Aber auch damals schon konnte man geklammerte Ausdrücke beliebiger Tiefe korrekt parsen und verarbeiten. Dass ausgerechnet Donald Knuth da wohl eher einen Parser für Arme gebaut hat, so lese ich das, überrascht. Es ist nicht die einzige Stelle, an der das auffällt. Natürlich ist aber, selbst bei der krautigsten Logik, aus Sicht eines TeX-Adepten immer der Nutzer schuld ;-)

Grüße
Frank
_________________

Dipl.-Inform. Frank Seitz
IT Consultant / {Web, Database, Linux} Developer + Admin
Tel: +49-176-78243503, Hauptstr. 32-34, D-25462 Rellingen

Blog: http://fseitz.de/blog
Private Nachricht senden Benutzer-Profile anzeigen

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 03.02.2018, 17:09     Titel:
  Antworten mit Zitat      
fs hat Folgendes geschrieben:
Aber auch damals schon konnte man geklammerte Ausdrücke beliebiger Tiefe korrekt parsen und verarbeiten.

Und TeX kann das auch. Wie erklärt wurde, sind für TeX in der Voreinstellung {} Klammern. (), [], <>, Aa, »«, «», }{, +-, BE und was man sich als Mensch noch sein einfallen lassen könnte, sind in der Voreinstellung keine Gruppen/Argument-Klammern. Du kannst auch bei C nicht einfach {} statt () verwenden, um Argumente zu kennzeichnen, oder [] statt {}, um Blöcke zu kennzeichnen. Sprachen haben eine Syntax. Wobei man bei TeX die Klammern auch tauschen kann. Du kannst auch X und Y zu Klammern erklären. Wären optionale Argumente ein Feature der Sprache TeX, würden sie sicher auch anders funktionieren. In TeX selbst oder plainTeX gibt es aber gar keine optionalen Argumente. Das ist eine Erfindung von Lamport. Die werden in LaTeX der Sprache TeX übergestülpt, weil man nicht für unterschiedliche Anzahl an Parametern unterschiedliche Makros definieren wollte, wie es eigentlich bei TeX vorgesehen ist. Und leider hat Lamport damals nicht dokumentiert, dass man nicht einfach […], sondern eigentlich immer [{…}] verwenden sollte. Das irgendwie Knuth anzulasten ist, als würde man Turing anlasten, dass Windows das aktuelle Word-Dokument nicht mehr sichert, wenn man am PC den Stecker zieht.

Tatsächlich sind delimited arguments in TeX für so Dinge wie
Code • Öffne in Overleaf
\def\buildrel#1\over#2{\mathrel{\mathop{\kern\z@#2}\limits^{#1}}}
vorgesehen und nicht für optionale Argumente.

fs
Forum-Anfänger
Forum-Anfänger

Beiträge: 35
Anmeldedatum: 02.01.18
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 03.02.2018, 23:25     Titel:
  Antworten mit Zitat      
C, was älter ist als TeX/LaTeX, kann selbstverständlich mit beliebig tief geklammerten Ausdrücken, gebildet über {}, (), [], umgehen, dort wo die C-Syntax entsprechende Ausdrücke vorsieht. Wenn TeX nur geschweifte Klammern als einzig schachtelbare Klammerstruktur kennt, dann hat Leslie Lamport mit seiner Einführung von optionalen Argumenten offenbar daneben gegriffen. So ist das Konzept aus meiner Sicht jedenfalls unsauber realisiert. Denn es ist doch sonnenklar, dass die Sache auch rekursiv funktionieren muss!

Grüße
Frank
_________________

Dipl.-Inform. Frank Seitz
IT Consultant / {Web, Database, Linux} Developer + Admin
Tel: +49-176-78243503, Hauptstr. 32-34, D-25462 Rellingen

Blog: http://fseitz.de/blog
Private Nachricht senden Benutzer-Profile anzeigen

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 04.02.2018, 12:27     Titel:
  Antworten mit Zitat      
Dann schlage ich vor: Mach es besser.

fs
Forum-Anfänger
Forum-Anfänger

Beiträge: 35
Anmeldedatum: 02.01.18
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 04.02.2018, 13:27     Titel:
  Antworten mit Zitat      
Naja, wir können in dem Zusammenhang nur im Konjunktiv sprechen, denn auf das Design von LaTeX habe ich im Nachhinein keinen Einfluss. Ich würde aber behaupten: Ich hätte es besser gemacht. Denn so ist es nach professionellen Maßstäben Käse. Da gibt es für mich nichts zu beschönigen.

Grüße
Frank
_________________

Dipl.-Inform. Frank Seitz
IT Consultant / {Web, Database, Linux} Developer + Admin
Tel: +49-176-78243503, Hauptstr. 32-34, D-25462 Rellingen

Blog: http://fseitz.de/blog
Private Nachricht senden Benutzer-Profile anzeigen

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 04.02.2018, 14:55     Titel:
  Antworten mit Zitat      
Man kann bei LaTeX mit Hilfe von eigenen Klassen und Paketen nachträglich schlichtweg alles ändern. Also hindert Dich niemand daran, alles von dem Du behauptest, es besser zu können, tatsächlich besser zu machen. Genau so sind viele Dinge überhaupt erst entstanden: Leute fanden beispielsweise die Standardklassen, die zu LaTeX dazu gehören, nicht gut genug. Also haben sie diese durch in ihren Augen bessere Klassen wie memoir oder die Klassen von koma-script ersetzt. Leute fanden die Möglichkeiten der Optionen für \documentclass und \usepackage nicht ausreichend. Also haben sie Pakete geschrieben, die es ermöglichen, Optionen auch dort per key=value anzugeben. Leute fanden die Möglichkeiten für Listen im LaTeX-Kern nicht komfortabel. Also haben sie Pakete geschrieben, mit denen man Listen einfacher konfigurieren und definieren kann. Leuten waren die Grafikfähigkeiten von LaTeX nicht gut genug, also haben sie so geniale Pakete wie pstricks oder pgf geschrieben. Leute fanden die komplette Syntax von Befehlen in LaTeX und TeX nicht gut. Also haben sie l3kernel etc. geschrieben. Leute fanden LaTeX insgesamt nicht so toll. Also haben sie andere Formate wie ConTeXt geschaffen.

Das waren alles Leute, die nicht groß behauptet haben, sie könnten etwas besser. Das waren alles Leute, die tatsächlich etwas besseres geschaffen haben. Und das macht dann letztlich den Unterschied.

Neues Thema eröffnen Neue Antwort erstellen Gehe zu Seite 1, 2  Weiter



Options and Permissions
Beiträge der letzten Zeit anzeigen:

Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen
.

goLaTeX ist Teil der goForen
goForen.de goMATLAB.de goLaTeX.de goPCB.de


  Datenschutzerklärung | Impressum | FAQ | goLaTeX RSS Button RSS-Feed

Copyright © 2008 - 2018 goLaTeX.de