Inhaltsverzeichnis
BuX — Textsatz mit Forth
Der (vorläufige) Arbeittitel des Projekts, BUX ist natürlich eine Anspielung auf TEX. Populäre Satzsysteme geben ja bekanntlich den geplanten Projektumfang im Namen an: Mit Word sollte man sich eher auf einzelne Wörter beschränken, Pagemaker reicht immerhin bis zu einer Seite, und mit TEX kann man auch mittellange Texte wie wissenschaftliche Artikel oder Diplomarbeiten schreiben, ohne in wildes Gehacke zu verfallen. BUX soll auch für komplexere Bücher brauchbar sein.
Je nach Sprache kann man BUX “Buch” oder “Books” aussprechen, als reines ASCII schreibt man BuX. Markenrechtlich wohl auch kein Problem.
Projektstatus: Brainstorming.
Motivation
Die Motivation für BUX rührt natürlich aus Unzufriedenheit mit LaTeX her. Helmar hat in comp.lang.forth
ein Brainstorming angeregt, und das haben wir dann auf dem nächsten Münchner Forth-Treffen (am Tag danach) auch gemacht. Helmar hat schon verschiedene anspruchsvolle Bücher mit LaTeX gesetzt (viel Ägyptologie mit Hieroglyphen), und kennt die Grenzen des Systems — sie liegen natürlich im grundsätzlichen Aufbau des Systems, also in TeX.
Leider ist TeX auch nur bedingt wartbar — die Sprache, in der TeX implementiert ist (Web) ist eine Sprache, die Donald Knuth extra für den Zweck kreiert hat, und deren Übersetzung in das gebräuchlichere C wird mit einem eher wilden Hack namens cweb erledigt. Zudem fehlen Web natürlich viele Features, die wir an Forth schätzen gelernt haben .
TeX ist als Programmiersprache für TeX-Erweiterungen auch nicht besonders toll. Eigentlich hatte TeX ja keine richtige Programmiersprache werden sollen.
Anforderungen
- Das System muss LaTeX-Markup verstehen können (Rückwärtskompatibilität zu vorhandenen Tools und Texten)
\def
-Gehacke muss es nicht verstehen, allenfalls ganz einfache Textsubstitution- Schwachstellen von LaTeX, etwa Fußnoten in Überschriften und Tabellen, die nur mit Hacks möglich sind, muss es auch nicht verstehen können.
- Andere Markup-Syntax (XML, Wiki-like) als Erweiterung jederzeit möglich
- Output nach Cairo, PDF, PostScript und wenn möglich DVI
- Einfach anfangen (z.B. fit-first Absatzumbruch), und später ausgefeilter werden
- Grobe Datenstruktur einer Seite: Vertikale Liste von Zeilen, die wieder horizontale Liste von Wörtern sind — natürlich verschachtelt
- Box&Glue-Modell für verschachtelte Objekte und variable Abstände, Absatzumbruch u.U. auch anders gelöst
- Besserer Umbruchalgorithmus:
- Bewertung des Absatzumbruchs anhand einer echten Grauwertberechnung (mit Cairo ins Memory zeichnen und auswerten)
- Einzelne höhere Zeichen, die aus der Zeile ragen (Brüche, einzelne Hieroglyphen) sollen nicht einfach automatisch zu einer Vergrößerung des Zeilenabstands führen, sondern nur, wenn tatsächlich eine Kollision vorliegt.
- Umbrechen nicht nur in ein Rechteck, sondern auch in frei wählbare Formen, die als Graymap vorgegeben werden — der Grauanteil der Graymap korreliert dann hinterher mit dem Grauanteil des Texts.
- Speicherverwaltung: Zunächst verschwenderisch; auch lange Bücher enthalten höchstens ein paar Megabyte an Text
- Zeichensätze: OpenType, TrueType