Konzepte: - headers Author: ... - 1d-block foo XX bar XX quux - 2d-block XX ... - table ++ | .. | - XX tags XX - entities ..{xxx}.. Examples: o '' XX foo bar baz quux XX is applied to "foo bar baz", not to "quux". o '' XX foo XX bar quux XX is applied to "foo", not to "bar quux" o '' foo bar XX quux XX is applied to "quux" __and__ "foo bar", because not closed XX environment wraps around at end of paragraph. With this the following is equvalent: '' XX foo bar quux XX '' XX foo bar quux '' foo bar quux XX this way headings are not special case: '' ==heading== '' ==heading '' heading== '' heading == '' heading ======= begins a 2d block with head tag and ends (explicitly or implicitly) with the same tag's markup, the 2d block is treated as a "head line" (for table of contents, etc.) Else is is treated as "paragraph heading" (not included in table of contents). Brainstormings with Christian Reiber: 1. Scanner erkennt die Intentation, strippt sie weg, berechnet aber durch sie die "schliessenden Klammern" zu den 2d-tags. 2. Scanner erkennt auch die Unterschiede zwischen 1d und 2d tags, da der Parser ja keinerlei Unterscheidung treffen kann (spaces/indent nicht mehr da) 3. Scanner hat einen Look-Ahead von 1 Zeile plus ihrem Indent 4. Das Parsen von Headern "(====)" geht einfach: Der Scanner erkennt nur das "^========" und ein Baumtransformator haengt spaeter die Sohn-Sequenz " x ..... y

" um in "

x ... y", d.h. der transformator geht bis zum letzten Paraphraph Knoten zurueck. If the "text" on hyperlinks is missing in links, the reference is printed instead. For internal links the text is chapter and pagenumber (except for HTML, there exists real hyperlinks). Stichworte: Whatever | Irgendwas ---------- | ----------------------------- Brain Dump | VHIT (Vom Hirn ins Terminal) Blabla | ASCII WYSIWYG Design-Grundsaetze ------------------ 1. KISS bei der Sprache (Beschreibung geht auf eine Seite und ist ISO-Latin-1!) 2. KISS bei der Implementierung (Code-Groesse <= 80KB) 3. Wir implementieren nur das, was wir _WIRKLICH_ brauchen. 4. Sugar ist wie Unix: Wenige Konzepte existieren und werden konsequent durchgezogen 5. Sugar hat *keine* GUI, sondern ist ein Filter! Beispielaufruf: $ cat test.txt | sugar --html -otest.html 6. Sugar ist stand-alone (bis auf Postscript), man braucht also nicht 1001 Tools bei der Installation 7. Release early, release often (Eric S. Raymond) 8. Jedes Markup kann immer eindeutig formuliert werden (=non-magic), nur sieht es dann eventuell nicht so schoen aus. Wenn man sich an bestimmte Regeln haelt, kann man im Magic Mode ASCII-Aesthetik pur nutzen. Non-Magic ist immer nutzbar und aktiviert, Magic-Mode per default an, aber kann abgeschalten werden (per -xx und/oder inline tag) Idee: -xx im Dokument direkt eingeben ala vi/less Was Sugar nicht ist ------------------- 1. Sugar ist _keine_ Textverarbeitung oder ein DTP-Tool 2. Sugar ist keine Markup-Sprache (der Text ist bereits das Endprodukt) 3. Sugars Brother is more/less and not nroff (i.e. Sugar is fast!) Anwendungsfeld -------------- 1. Technische Dokumentation fuer mehrere Darstellungsplatformen: Plain ASCII (= Sugar Quelle), roff/-man (Unix), HTML (= Online), PS (= Print) 2. Brain Dump! Optionale Zusatzfeatures ------------------------ - ToC: Automatische Generierung - Numerierung von Headern - Index - Aufrufen von Makroprozessor: m4 Tabellen: --------- o Tabellen sind Bloecke und werden mit ++ eingeleitet wie andere Bloecke auch, d.h. Ende ist bei Ausrueckung oder selber Level. o Jede Tabellenzeile faengt mit einem | an und immer in der selben Spalte. o Die |'s der ersten Zeile geben die Gesamtanzahl und die Normposition der Spalten an. o Besteht die erste Zeile nur aus |'s (und keinem Inhalt), dann ist sie eine _reine_ Normungszeile und erzeugt auch keine Leerzeile. Ansonsten (Zeile 2, ...) kann man so selbstverstanelich eine Leerreihe erzeigen. o Spaltentrennungs-| koennen an belieber Stelle stehen, wenn genuegend da sind. o Folgespalten sind dadurch gekennzeichnet, dasz ihr | eingerueckt erscheint. o Multicolums liegen vor, wenn weniger |'s auftreten, als die Normungszeile vorgibt. Die Erkennung der Span's erfolgt dabei ueber die Position der |'s, d.h. sie muessen die |'s der Normunszeile matchen. Zusaetzlich kann die Normungszeile beliebig oft wiederhlt werden. Aber dabei darf sich nur die Position der |'s aendern, aber nicht die Anzahl (klar!). o Leerzeilen bestehen aus nur einem |' am Anfang und sonst nichts. o Normungszielen haben mind.(!) 2 |'s. o Leerzeilen erzeugen im Output soviele |'s wie die Normungszeile vorgibt. Fuer andere Layouting-Dinge muss man z.B. ``| \_'' schreiben. o In einer Tabelle koennen alle Zeichenformatierungen genutzt werden. o In der Normungszeile kann mit den Zeichenformatierung-Tags die Formatierung der Tabellenspalten angegeben werden! o Wie gibt man Tabellenzeilen an, die als Headers gelten? Eventuell gar nicht, wenn man Tabellen nicht umbrechen laesst, denn dann muss man diese headerzeilen auch nicht wiederholen und muss deshalb solche nicht explizit auszeichnen ++ | ((** | %% | )) | | foo | quux | bar | | foooooooo | quux | 3. Block-Konzept Es gibt zwei Blockkonzepte: - character block (eindimensional) und - line block (zweidimensional). Der //character block// wird durch das Tag eingeleitet und wieder beendet. Das Paragraph Ende beendet in jedem Fall den character block. Der //line block// beginnt mit dem Tag __ausgerückt__, wobei davor keine Leerzeile stehen muß (ein \n und ggf. \s davor reicht). Er enthält ganze Zeilen und zwar solange, wie Text in der Zeile mindestens zwei Leerzeichen weiter rechts beginnt als das einleitende Tag. Achtung: Tags stellen selbst __nicht__ den Zeilenanfang dar! Damit kann ich also line blocks schachteln. (Anders gesagt: Es geht nicht um den linken Rand der Textdatein, sondern um den linken Rand des übergeordneten Line Blocks.) Automatischer reflow durch den Editor ist bei character blocks **kein** Problem, da das Tag keine positionsabhängige Bedeutung hat (daher wurde auch verworfen, daß ein Tag am Zeilenanfang, aber nicht ausgerückt, am Zeilenende beendet wird). Das Start-Tag beim line block wird vom Editor nicht versetzt (wenn er was taugt). Möglicherweise kann für bestimmte Tags das Ende des char blocks auch das Zeilenende (nicht das Para. Ende) sein. Gedacht ist an Kommandos: Gehen sich nach http://laber.lall Das ist ## eine blöde Zeile und ich will daß ##das## unterstrichen ist ''##das ist ungut## ##das ist intuitiver, bedeutet aber Kommandoende=Zeilenende Das wäre dann eine Eigenschaft des Tags, d.h. es verhält sich dann //immer// so (und nicht mal so und mal anders). Beispiele: 1. ''Dies ist ein Beispiel für einen Text, __in dem der zweite Halbsatz unterstrichen wird__, obwohl er sich über eine Zeilengrenze erstreckt. o. ''__In diesem Fall wird der line block unterstrichen. Das geht solange, bis der Text wieder ausgerückt wird. Auch Leerzeilen stellen da kein Hindernis dar. Diese Zeile beendet den Line Block. o. ''Ein Sonderfall: __Dieser Text hat kein Ende-1d-Tag. Er wird dann durch das Paragraph-Ende beendet. Ab hier also keine Unterstreichung mehr. Das haben wir gemacht, weil sonst bei vergessenen Endetags das Restdokument fehlformatiert wird. o Native-Output-Stuff xxxx ``jdjlasdjajlad`` skd asdk s dsö ksaölkdaös## dfkdjsdal html xxxx ##endif xxxx o Comments ##// ##/* ##*/ 5. Inline-Images - Source ist immer Bitmap-Grafik im GIF Format! (Fuer ASCII: gifscii, Fuer HTML: Direkt, Fuer PS: gif2ps) ##img xx.gif size=jsjs s=xx - UNBEDINGT Unicode und UTF-8 unterstutezen von anfang an! Idea for homogenous tags: - any XX tags can be repeated multiple times, ie XXXXX is valid also - any begin XX tag at the end of a paragraph wraps around its scope, ie it is applied to the whole paragraph as it would stand at the start of the block (marged out?). Results: - headlines are marked equally with blocks ------------------------------------------------------------------------------ OSSP Sugar Brainstorming Meeting 27-06-2001 @ C&W ================================================= gewuenschter output: html (online), text, pdf/ps (print) |sugar, soll schnell sein fuer preview, 1-2sec gewuenschter input: simple (20-30 tags), wenig Stilmittel, aehnlich textoutput *eindeutige* Tags in SXML SRML invisible markup pre-processing pass 1: include, macros, pass 2: area substitution, diversion meta-information author, mtime, ctime, title, abstract, subject, version parameters passthrough for backends 2d-block headings 1-4 paragraph align left, right, centered, indented(?) preformatting lists, ordered/callout, unordered, description import extern(URL)/embedded vs. include figures format(EPS,PNG,TXT), scaling tables, titlerow, rows, columns, cells, spanning, hlines, vlines, nesting caption 2+1d block verbatim boxed, striked, tele-typed logical markup (emphasize, nonbreaking) notes foot, end, margin shellescape 1d-block bold, italic, underline escaping(?) linebreaks(?) subscript, superscript anchores, references intern, extern index items word-breaking entitities (ISO chars, newline, etc.) o no align (left, center, right, indented) in general only needed in tables idea: first line specified table layout like TeX o eventuell: kein escaping, man koennte verbatim hernehmen aber: wie escape ich dann verbatim tag! o eventuell kein linebreak, da normaler linebreak eher neuer paragrpah sein sollte und fuer andere preformatted ausreicht! o generell sugar koennte immer SXML sein, aber abkuerzend koennte es SRML Teile enthalten o ------------------------------------------------------------------------------ Ideas from AFT: - non-intended verbatim mode with optional filtering for pretty-printing | ^<<[filter] | ^>> - a pre-formatted mode would be cool, too. ------------------------------------------------------------------------------ XML-FO panda+pandascript (C API, Perl API, Shell API, GPL) http://www.stillhq.com/cgi-bin/getpage?area=panda&page=index.htm pdflib http://www.pdflib.com/ clibpdf http://www.fastio.com/