Algo zu textrendering, Absatzformatierung
Jan Bruns
Hallo.
Mich beschäftigt nun seit einiger Zeit das praktische Problem,
Textabsätze möglichst "hochwertig" zu formatieren:
Ein Textabsatz habe eine fixe Zeilenhöhe, in den Text
untschiedlicher Grösse normalerweise hineinpasst (nach
den üblichen Regeln).
Nun soll der Text aber auch "Anker", Platzhalter für
andere, rechteckförmige Objekte (Bilder, Formeln) enthalten
können. Diese Anker sollen constraints über ihre Positionierung
enthalten können: Man soll festlegen können, daß das Objekt
genau an der fliessenden Textposition des Ankers beginnen soll,
und zwar wahlweise nach oben oder unten ragend (soweit die
Objekthöhe eben die Zeilenhöhe überschreitet). Der Text soll
dementsprechend natürlich durch die störenden Objekte
"hindurchfliessen" (als wenn die Hindernisse selbst Teil des
Textflusses wären). Dazu noch weiterer "Kleinkram" wie Blöcke
mit Zeilenumbruchverbot usw.
Das ganze ergibt, wenn man es ausformuliert, auf jeden Fall
ein recht komplexes Regelwerk. Ich traue mir gerade noch zu,
einen naiven Algorithmus dazu zu formulieren, der aber
sicherlich weder optimale Ergebnisse (im Sinne von
flächenminimierter Darstellung) liefern würde, noch sonderlich
effizient gescheit hinsichtlich der Auflösung der Constraints
wäre. Zudem wie gesagt nervig komplex.
Das ganze 'nem externen, universellen solver zu übergeben
scheint mir wegen der zu erwartenden Problemkomplexität in
Relation zur Brauchbarkeit suboptimaler Lösungen auch so gar
nicht angemessen zu sein.
Das Problem lässt sich je ganz gut als Raster-Aufgabe
formulieren, sieht dann ziemlich wie Tetris mit zusätzlichen
Regeln, dafür aber erlaubtem Rückgängigmachen aus.
Wäre das nicht mal ein interessantes Problem, das die
Menschheit im Jahr 2009 eigentlich wenigstens bis zur
praktischen Verwendbarkeit gelöst haben sollte? Kann
doch nicht sein, daß wir die nächsten 100 jahre oder
so immer noch mit in dieser Hinsicht echt
stumpfestmöglichen Textfenstern leben müssen.
Gruss
Jan Bruns
--
Ein paar Fotos: http://abnuto.de/gal/
Olaf Musch
> Hallo.
>
Hallo,
> Mich beschäftigt nun seit einiger Zeit das praktische Problem,
> Textabsätze möglichst "hochwertig" zu formatieren:
>
das hat vor Dir schon andere Menschen beschäftigt.
>
> Das ganze 'nem externen, universellen solver zu übergeben
> scheint mir wegen der zu erwartenden Problemkomplexität in
> Relation zur Brauchbarkeit suboptimaler Lösungen auch so gar
> nicht angemessen zu sein.
>
nicht unbedingt.
> Wäre das nicht mal ein interessantes Problem, das die
> Menschheit im Jahr 2009 eigentlich wenigstens bis zur
> praktischen Verwendbarkeit gelöst haben sollte? Kann
> doch nicht sein, daß wir die nächsten 100 jahre oder
> so immer noch mit in dieser Hinsicht echt
> stumpfestmöglichen Textfenstern leben müssen.
>
Welche "Textfenster" meinst Du? In irgendeiner Anwendung?
Welcher?
[ ] Du hast mal was von TeX gehört
[x] Du möchtest TeX neu entwickeln
[ ] Du hast vor gut zwei Wochen http://tug.org/texlive/ gelesen
Mit anderen Worten: Nimm TeX und gut is ;-)
Olaf
Jan Bruns
Olaf Musch:
>> Wäre das nicht mal ein interessantes Problem, das die Menschheit im
>> Jahr 2009 eigentlich wenigstens bis zur praktischen Verwendbarkeit
>> gelöst haben sollte? Kann doch nicht sein, daß wir die nächsten 100
>> jahre oder so immer noch mit in dieser Hinsicht echt stumpfestmöglichen
>> Textfenstern leben müssen.
> Welche "Textfenster" meinst Du? In irgendeiner Anwendung? Welcher?
> [ ] Du hast mal was von TeX gehört
> [x] Du möchtest TeX neu entwickeln
> [ ] Du hast vor gut zwei Wochen http://tug.org/texlive/ gelesen
>
> Mit anderen Worten: Nimm TeX und gut is ;-)
Nein, wozu sollte ich TeX neu entwickeln?
Ich habe immerhin schon mehrseitige Dokumente manuell mit TeX erstellt.
Das hat funktioniert (wenn auch erstmal recht umständlich, aber ist
klar, wenn man erstmal damit umzugehen lernen muss).
Ich bin aber offensichtlich nicht der einzige, der nicht darüber
informiert ist, daß TeX die hier diskutierte Funktionalität überhaupt
bietet (ich habe jedenfalls die Erfahrung gemacht, daß viele Autoren
ernsthafte Probleme haben, im Text referenzierte Objekte auch nur
auf eine halbwegs nahegelegene Seite(!) zu bekommen...).
Und nein, ich will kein komplettes Textsatzsystem entwickeln. Ich
entwickle nur nebenbei ein kleines GUI-Toolkit für meine Zwecke,
und da will ich natürlich 'nen wenigstens halbwegs verwendbares
"RichText"-Element. Existierende, gängige Desktop-Oberflächen
bieten die hier diskutierte Funktionalität übrigens nicht;
Browser können's daher soweit ich weiss auch nicht (wobei aber
IIRC schon HTML/CSS die entsprechende Textauszeichnung gar nicht
gestatten würde)
Jan Bruns
Heiko Schlenker:
> * Jan Bruns <jansa...@arcor.de> schrieb:
>> Ich bin aber offensichtlich nicht der einzige, der nicht darüber
>> informiert ist, daß TeX die hier diskutierte Funktionalität überhaupt
>> bietet
Hat zwar jetzt nicht so viel mit dem Thema zu tun, aber da diese
Behauptung hier jetzt schon zum zweiten mal auftaucht: Kann mal jemand
Beispielcode/doku dazu liefern?
Das Paket picinpar kommt nach der Beschreibung aus dem 2. feu-Hagen
Skript zu Latex der gefragten Funktionalität schonmal ähnlich,
positioniert aber nicht fliessend, sondern absolut (innerhalb
eines Absatzes), was ein weitaus einfacheres Problem ist
(OpenOffice kann das z.B. auch); denn dann hat kann man einfach
die "Grafikobjekte" (u.ä.) zuerst positionieren, und hinterher dem
fliessenden Text dann schlicht eine "keepout-area" aufdrängen.
>> (ich habe jedenfalls die Erfahrung gemacht, daß viele Autoren
>> ernsthafte Probleme haben, im Text referenzierte Objekte auch nur auf
>> eine halbwegs nahegelegene Seite(!) zu bekommen...).
> Sie haben das Prinzip der Gleitobjekte nicht verstanden. :-)
Nunja, das ist vielleicht "etwas" übertrieben.
Florian Weimer
> Sie haben das Prinzip der Gleitobjekte nicht verstanden. :-) LaTeX
> f�gt sie dort ein, wo es *typographisch* sinnvoll ist.
Stimmt das inzwischen? LaTeX hat fr�her nur sehr krude Heuristiken,
was daran lag, da� es aus einer Zeit stammte, als man nicht den ganzen
Dokumenttext und alle Bildgr��en im Speicher halten wollte (sondern
nur einzelne Abs�tze). Globale Optimierungen gibt es z.B. in Lout.
Wenn LaTeX globale Optimierungen hat, dann sage uns bitte, wie man sie
einschaltet.
Jan Bruns
Jan Bruns:
> Ein Textabsatz habe eine fixe Zeilenhöhe, in den Text untschiedlicher
> Grösse normalerweise hineinpasst (nach den üblichen Regeln).
> Nun soll der Text aber auch "Anker", Platzhalter für andere,
> rechteckförmige Objekte (Bilder, Formeln) enthalten können. Diese Anker
> sollen constraints über ihre Positionierung enthalten können: Man soll
> festlegen können, daß das Objekt genau an der fliessenden Textposition
> des Ankers beginnen soll, und zwar wahlweise nach oben oder unten ragend
> (soweit die Objekthöhe eben die Zeilenhöhe überschreitet). Der Text soll
> dementsprechend natürlich durch die störenden Objekte "hindurchfliessen"
> (als wenn die Hindernisse selbst Teil des Textflusses wären). Dazu noch
> weiterer "Kleinkram" wie Blöcke mit Zeilenumbruchverbot usw.
Relativ einfach zu handhaben sind dabei absolut positioniete
"Grafikobjekte", und solche, die in Textflussrichtung hinter ihrer
Ankerposition einzufügen sind (also für uns: nach unten ragende Bilder),
denn dann kann man stumpf alle Objekte nacheinander in Flussrichtung
positionieren, muss dabei nur Hindernisse berücksichtigen. Das Ergebnis
dürfte dann meistens schon recht brauchbar sein. Eine Verbesserung
könnte bspw. durch Zulassen von horizontalen Verschiebungen bereits
positionierter Objekte bringen (z.B. solange das nicht zu zus.
Zeilenumbrüchen führt).
Richtig problematisch sind dagegen Objekte, die von der Ankerposition
aus entgegen der Flussrichtung eingefügt werden sollen (also für
uns: nach oben ragende Bilder). Bezogen auf einen Algorithmus, der
(wie gerade beschrieben) Objekte in Textflussrichtung nacheinander
abarbeitet, könnte man versuchen, solche Objekte so zu behandlen,
als seien sie (von einem unechten Anker aus) in Flussrichtung
einzufügen. Dazu muss man aber eine geeignete, unechte Ankerposition
erstmal finden (ungeeignet sind jedenfalls Positionen, von denen aus
das Objekt den echten Anker gar nicht mehr erreichen kann, weil
bspw. zuviele Zeilenumbrüche zwischen echtem und unechtem Anker
liegen müssen).
Bei Verwendung solch eines Algos wird man also eine sinnvolle,
unechte Ankerposition nur schätzen können, mithin also mehrere
Möglichkeiten ausprobieren wollen. Das ist natürlich rechenintensiv,
sobald zwischen unechtem und echtem Anker weitere Paare von echten
und unechten Ankern liegen. Diesem Problem könnte man begegnen, indem
man die "Entfernung" eines Paares von echtem und unechtem Anker so
begrenzt, daß eben nur eine begrenzte Verschachtelung von Ankerpaaren
möglich ist, was allerdings ziemlich schnell zu auffällig schlechten
Ergebnissen führen würde.
Andere Ideen?
Jan Bruns
> Bei Verwendung solch eines Algos wird man also eine sinnvolle, unechte
> Ankerposition nur schätzen können, mithin also mehrere Möglichkeiten
> ausprobieren wollen. Das ist natürlich rechenintensiv, sobald zwischen
> unechtem und echtem Anker weitere Paare von echten und unechten Ankern
> liegen.
Genauer gesagt resultiert die Verschachtelung bereits aus sich
überlappendenden, von ankerpaaren eingeschlössenen Bereichen.
Ein völlig anderer, meiner Schätzung nach praktisch nicht verwendbarer
Ansatz wäre, das Problem als System von boolean constraints zu
überführen. Bspw. könnte man zunächst die auszufüllende Fläche
aufrastern, und sodann für jede Flächeneinheit und jedes dort mögliche
Textelement eine Variable verwenden, und all die Anforderungen zur
Anordnung generieren. Selbst wenn sich so ein trivial lösbares System
ergäbe: Schon der Speicheraufwand für das Regelwerk wäre derart enorm,
daß ich ausschliessen kann, daß das für meine konkrete Anwendung
sinnvoll einzusetzen sein könnte. Mag aber sein, daß das i.A. eine
sinnvolle Vorgehensweise wäre (möge das jemand anders überprüfen).
Aber prinzipiell scheint mir die Idee, die zur Verfügung
stehende Fläche erstmal aufzurastern, um da dann die Objekte
hin- und herzuschieben, Lösungsansätze zu bieten, auch wenn mir
da keine konkrete Idee in den Sinn kommen will.