BuX — Textsatz mit Forth

Der (vorläufige) Arbeittitel des Projekts, B_UX ist natürlich eine Anspielung auf T_EX. 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 T_EX kann man auch mittellange Texte wie wissenschaftliche Artikel oder Diplomarbeiten schreiben, ohne in wildes Gehacke zu verfallen. B_UX soll auch für komplexere Bücher brauchbar sein.

Je nach Sprache kann man B_UX „Buch“ oder „Books“ aussprechen, als reines ASCII schreibt man BuX. Markenrechtlich wohl auch kein Problem.

Projektstatus: Brainstorming.

Die Motivation für B_UX 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.

• 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