Auf Mastodon ansehen
Präservativ - eine Vorbemerkung
Nachdem ich (vor einem Vierteljahrhundert) für ein Projekt mal "Word" als Editor verwendet habe, später dann "normale" Texteditoren und das Terminal nebst einer PDF Ansicht mit 'mupdf', nutze ich für den "Hausgebrauch" u.a. direkt eine "GUI Textverarbeitung" wie den LO Writer und/ oder Markdown, mit LO Writer, LaTex, PDF, HTML (oder 'sonstwas') als "Endprodukt".
Aus meiner subjektiven Sicht kann man mit Markdown einerseits flexibler sein, es kann andererseits aber eben wiederum Ausgangspunkt für LaTex sein. Ein spezieller "LaTex" Editor kann somit sinnvoll sein, muß aber nicht.
Ferner habe ich neulich "erste Gehversuche" mit Typst gemacht, und auch da gibt es geeignete Vorlagen für Briefe (und viel mehr). Den Typst-Compiler kann man in 'bin' ablegen, und das in ~.profile reinschreiben als export TYPST=~/bin/typst.
Etwa über Skripte -d.h. halt solange man noch keinen "GUI Editor" hat- kann man nun PDFs erzeugen mit . ~/.profile && typst compile brief2omi.typ (ggf. ein 'alias' anlegen).
Die Benutzeroberfläche
Was ich sehr gelungen finde, und warum ich das Ding hier vorstelle, ist die Einfachheit und Übersichtlichkeit, aber auch die "Live Vorschau". Es fehlen nur wenige "Kleinigkeiten", die es ziemlich sicher in anderen GUI Editoren gibt, das muß aber gar kein Nachteil sein.
Wir sehen (ausgeblendet habe ich Status- und Werkzeugleiste) auf der rechten Seite das fertige Dokument in der Live Vorschau sowie drei weitere Tabs für 'Projekt', 'Bibliografie' und 'Build/Logs'. Am unteren Bildrand läßt sich die PDF Darstellung regeln.
Auf der linken Seite sehen wir den Quelltext sowie am unteren drei Tabs mit denen sich Bilder, Tabellen und (mit Zeilen und Spalten den Tabellen nicht ganz unähnlichen) Matrizen in den besagten Quelltext pasten lassen. Ein kompletter GUI "Formeleditor" (für alles außer Matrizen!) fehlt allerdings, bzw. findet er "anderswo" statt (s.u.).
Zwei Arten, um Templates/ "Präambeln" zu verwalten
In den Einstellungen läßt sich zunächst eine Art "Standard Template" vorgeben ("welcome.tex"), welches für ("Neue") Dokumente verwendet werden kann und das beim Start der GUI erscheint. Das ursprüngliche "welcome.tex" habe ich für deutschsprachige Texte geringfügig angepasst.
Weiterhin gibt es eine "Template Engine", die sich verwenden läßt, falls es halt doch einmal was anderes als das erwähnte "Standard" Template werden soll ("Neu aus Vorlage").
Die "Ablageorte" sind ~/.config/gummi/welcome.tex sowie ~/.config/gummi/templates/ für weitergehende Templates, bzw. Latex Präambeln samt Schluß mit \end{document}.
Wichtig: Für die "Live PDF Vorschau" läßt sich nicht grundsätzlich jede Präambel verwenden, bzw. kann die Vorschau da etwas "zickig" sein. Meine ausdrückliche Empfehlung wäre, geeignete Templates anzulegen, die nachweislich funktionieren, und dann nur diese zu verwenden. In meinem Fall habe ich eine Art "Report" sowie ein "Brief" Dokument.
Eine Inkonsistenz und der Absturz
Nicht verschweigen will ich, wie im Rahmen meiner –teilweise extrem dummen– "Experimente", der Editor erfolgreich zum Absturz gebracht werden konnte, und zwar beim Hantieren mit mehreren "inkonsistent" miteinander verknüpften Dateien (s.u.).
Der Fehler war eine mit \input{bla} in das (nicht abgespeicherte) Hauptdokument eingebundene (jedoch abgespeicherte) Datei –ohne selbiges als "Projekt" angelegt zu haben– und dann "ohne Abspeichern" die GUI einfach komplett schließen zu wollen.
Dieser inkonsistente Zustand wurde -zumindest mit geöffnetem "Projekt Tab" nicht völlig unerwartet- mit Absturz quittiert. Ausgesehen hat das jedenfalls folgendermaßen – die eingefügten "roten Punkte" dienen hier lediglich der "Illustration", also hoffentlich...
Vor- und Nachteile, Fazit und Ausblick
Ob ich für wirklich "große" Gesamtprojekte heute noch einen GUI LaTex Editor verwenden würde, weiß ich offen gesagt nicht. Es lassen sich größere Projekte aber bekanntlich in kleinere Abschnitte aufteilen, und wahlweise kann man dergleichen ja zunächst/ vorab auch mit Markdown angehen.
Trotzdem läßt sich für den "Hausgebrauch", wenn man auch für kleinere Dinge "aus Gründen" LaTex Features nutzen will, der Editor gewinnbringend einsetzen, zur Not sogar auf nur 1026*600 Bildpunkten. Ideen dazu könnt Ihr gerne in den Kommentaren absetzen.
Quellen:
Außer dem abgebildeten "HTML Formular" für den (alternativen) *"Schmalspur Formeleditor"*, von dem ich nicht mehr weiß, woher ich den habe, stammen alle Abbildungen von mir. Die "Report" Dokumente entstammen der mit 'Gummi' mitgelieferten Vorlage.
Der Editor kann über die üblichen 'Repos' bezogen werden (u.a. Debian) und die Projektseite ist offenbar diese hier:
https://github.com/alexandervdm/gummi
Letzte Änderung im GitHub-Repo im November 2024. Dort angegebene Website bei mir nicht aufrufbar. Is it dead, Jim?
Certainly not, Steve! - It is just the Smell that might be a Funny one...
Dass der Autor nicht "24/7" am vorgestellten Editor fummelt, liegt für mich im Bereich des Erwartbaren. https://tracker.debian.org/pkg/gummi legt jedoch nahe, dass seit 2025 der Schritt von (0)8.3.5 auf (0)8.3.6. in der Pipeline liegt.
...Es geht im Debian Repo also KLAR voran! ☘️ ...auch wenn eine der Seiten tot sein mag. -LG
Also, ich bin ja kein LaTeX Freund, obwohl es mit Sicherheit das mächtigste und umfassendste System in dieser Richtung sein wird.
In einer früheren Tätigkeit habe ich für Dokumentationen das AsciiDoc-System gewählt. Das bietet mehr Auszeichnungen als Markdown, ist aber ähnlich "lesbar". Außerdem können kleine Abfragen und Verlinkungen eingebaut werden. Das habe ich in Verbindung mit Templates dann sowohl für einen HTML-Export (war für eine Software als "Online-Hilfe" gedacht) als auch für einen PDF-Export verwenden können.
Bei Markdown ist mir das alles etwas zu "hackish", wenn zum "Basis-Standard" dann Dinge wie Tabellen oder verschachtelte Elemente dazu kommen. Da gibt es dann wieder Abweichungen. Das hat mich dann eben zu AsciiDoc gebracht.
Bei LaTeX war ich immer zu blöd, die ganzen Einzeldokumente passend zusammenzuführen, ein Inhaltsverzeichnis zu bauen und ein eigenes Template zu verwenden. Da ging immer etwas schief. Da wird man nur glücklich, wenn man die Zeit dafür mitbringt. Das war bei mir damals aber nicht der Fall ;-)
Bitte nicht falsch verstehen, ich finde es toll wenn die Community Beiträge erstellt und weiß das auch zu schätzen, aber Ich würde den Artikel leider als _konfus _bezeichnen.
Der Abschnitt „Präservativ - eine Vorbemerkung“ ist m. E. unnötig. Geht es nicht um LaTeX?
> Ein spezieller "LaTex" Editor kann somit sinnvoll sein, muß aber nicht.
Hä?
Und wozu der Hinweis auf typst? Was hat das denn jetzt mit Gummi zu tun?
Stefan, es mag ja durchaus sein, dass ich mir meine Blödelei mit "Verhüterlis", wie man sie in der Schweiz wohl nennt, im Zusammenhang mit Gummis und Latex hätte verkneifen können, aber was bitte ist daran "konfus"?
Zu tun haben wir es hier mit "Textauszeichnung" und Editoren dafür, und da führen einfach mehrere Wege nach Rom, von denen ich persönlich auch fast alle benutze. OK, "AsciiDoc" nutze ich noch nicht, was aber rein gar nichts über AsciiDoc aussagt!
Als Editor ist "Gummi" tatsächlich rein optional, d.h. es gibt viele andere. Ich selber komme z.B. mit "scite" für fast alles sehr gut zurecht. Einen "typst Modus" gibt es bislang in Gummi tatsächlich nicht, das hatte ich aber auch nirgendwo behauptet. - Alles klar?
Alles klar, vielen Dank!
Den Editor Gummi hatte ich vor einigen Jahren auch mal angeschaut. Zwar war die Entwicklung noch nicht ganz so stagnierend, aber die schlechte Unterstützung von biblatex, vom Fehlen einer solchen für biber ganz zu schweigen, war schon nicht mehr zeitgemäß. Damit ist es wirklich eher für einfache Dokumente geeignet.
Den LaTeX-Editor vom GNOME-Projekt fand ich bezüglich der Benutzeroberfläche ähnlich übersichtlich. Leider ist auch hier die Entwicklung eingeschlafen. Dafür gibt es mit Setzer einen Editor, der auf Gtk4 und ähnliche Prinzipien setzt. Das ist meines Erachtens der Editor der Wahl, wenn es übersichtlich sein soll und sich mit den Ideen von GNOME hinsichtlich Konfigurierbarkeit anfreunden kann.
Na ja, klein ist immer relativ. Hier will er 806 MB an Abhängigkeiten installieren:
Installiere:
gummi
Installiere Abhängigkeiten: dvisvgm libdevel-stacktrace-perl libmpfi0 libspreadsheet-writeexcel-perl ruby-ruby2-keywords fonts-lato libdigest-perl-md5-perl libmro-compat-perl libstring-crc32-perl ruby-rubygems fonts-lmodern libdist-checkconflicts-perl libmujs3 libsub-exporter-perl ruby-sdbm fonts-texgyre libdynaloader-functions-perl libmupdf25.1 libsub-exporter-progressive-perl ruby-webrick fonts-texgyre-math libemail-date-format-perl libnamespace-autoclean-perl libsub-identify-perl ruby-xmlrpc libalgorithm-c3-perl libeval-closure-perl libnamespace-clean-perl libsub-install-perl ruby3.3 libb-hooks-endofscope-perl libexception-class-perl libole-storage-lite-perl libsub-name-perl rubygems-integration libb-hooks-op-check-perl libfile-homedir-perl libpackage-stash-perl libsub-quote-perl t1utils libbit-vector-perl libfile-which-perl libpackage-stash-xs-perl libsys-hostname-long-perl tcl libcarp-clan-perl libfontbox-java libpadwalker-perl libteckit0 tcl8.6 libclass-c3-perl libgtksourceview-3.0-1 libparams-classify-perl libtexlua53-5 teckit libclass-c3-xs-perl libgtksourceview-3.0-common libparams-util-perl libtypes-serialiser-perl tex-gyre libclass-data-inheritable-perl libgtkspell3-3-0 libparams-validationcompiler-perl libunicode-linebreak-perl texlive-base libclass-method-modifiers-perl libgumbo3 libparse-recdescent-perl libunicode-map-perl texlive-binaries libclass-xsaccessor-perl libipc-shareable-perl libpdfbox-java libvariable-magic-perl texlive-extra-utils libcommon-sense-perl libjcode-pm-perl libpotrace0 libxstring-perl texlive-fonts-recommended libcommons-logging-java libjson-perl libptexenc1 libyaml-tiny-perl texlive-latex-base libcrypt-rc4-perl libjson-xs-perl libreadonly-perl libzzip-0-13t64 texlive-latex-extra libdata-optlist-perl liblog-dispatch-perl libref-util-perl lmodern texlive-latex-recommended libdate-calc-perl liblog-log4perl-perl libref-util-xs-perl mupdf-tools texlive-luatex libdate-calc-xs-perl libmail-sendmail-perl librole-tiny-perl preview-latex-style texlive-pictures libdate-manip-perl libmime-charset-perl libruby rake texlive-plain-generic libdevel-callchecker-perl libmime-lite-perl libruby3.3 ruby texlive-xetex libdevel-caller-perl libmime-types-perl libsombok3 ruby-csv tipa libdevel-globaldestruction-perl libmodule-implementation-perl libspecio-perl ruby-did-you-mean tk libdevel-lexalias-perl libmodule-runtime-perl libspreadsheet-parseexcel-perl ruby-net-telnet tk8.6
Ja, dergleichen hatte ich –wenn auch nur indirekt– mit 'typst' erlebt: Das hier kürzlich vorgestellte typst "Beispieldokument" verwendete (war es in Zeile 11?) einen exotischen Font, wies aber darauf hin, dass man den problemlos durch einen anderen ersetzen kann.
Selbiger Font war dann jedenfalls Bestandteil eines 'TeX Live' Unterpakets, welches mir ebenfalls weitere 600+ MB eingehandelt hätte (obwohl ich die gar nicht brauchte!). Den Font hatte ich mir dann separat besorgt und in '~\home' an geeigneter Stelle abgelegt.
Soweit ich das beurteilen kann, benötigt 'gummi' natürlich sehr wohl eine LaTex Umgebung (die auch mehr oder weniger "groß" werden kann), es setzt selbst aber nur überschaubare Abhängigkeiten voraus: https://packages.debian.org/source/stable/gummi