Word: Strategie hinter ausgeglichener Spaltenaufteilung

**stahli**

Die Trennung von Daten und Layout ist ja sinnvoll. Dennoch brauchst Du irgendeine Stelle, die alles miteinander abgleicht.
Das Problem ist, dass Du einige Vorgaben von außen treffen kannst (z.B. 3 Spalten, 2 mit 33,3 % Breite und die dritte nutzt den Rest)
ABER Du willst ja auch auf die Inhalt reagieren und das ist z.B. Text- und Textformatabhängig. Also beeinflussen sich äußere und innere Kriterien.

Da wir Deine genauen Schnittstellen und Möglichkeiten nicht kennen und diese sicher auch einige Einarbeitung erfordern würden, bleibe ich dabei, dass Hilfestellung schwierig sein wird.

Ich hatte vorhin mal einen längeren Text geschrieben und dann auf Grund Deines späteren Posts verworfen.
Habe es aber noch in der Zwischenablage (sind ein paar Überlegungen, aber auch keine konkrete Hilfe):

Zitat:

Ich denke nicht, dass Du hier Tipps erhalten kannst, die Dich wirklich weiter bringen.
Dazu ist die Aufgabenstellung zu spezifisch und sicher auch genau im Kontext Deines Projektes zu betrachten.

Grundsätzlich würde ich zunächst einfach von Rechtecken (ohne Inhalt) ausgehen und die auf einer verfügbaren Fläche "virtuell" anordnen.
Dazu kann man jedem Rechteck bestimmte Kriterien mitgeben (feste Breite oder variable Breite in einem bestimmten Bereich und evtl. sogar einem gewissen Widerstand gegen Abweichungen von der Sollbreite oder der aktuellen Breite).
So könnten sich die Rechtecke wie unter einer Physik verhalten und z.B. bei seitlichen Drücken unterschiedlich zusammenpressen lassen.

Wenn sich die Rechtecke nach einer Textbreite richten soll, dann musst Du diese wohl zunächst zeichnen und die Textbreite bestimmen und danach die Breite der Rechtecke vergeben.

Wenn die Gesamtbreite der Rechtecke aber die Seitenbreite übersteigt, musst Du irgendwo weiter nachgeben. Evtl. sind sogar mehrere Iterationen notwendig...

Ist sicherlich kein einfaches Problem.

**hansklok**

Zitat von stahli:

ABER Du willst ja auch auf die Inhalt reagieren und das ist z.B. Text- und Textformatabhängig. Also beeinflussen sich äußere und innere Kriterien

Lassen wir dies bitte erst einmal außen vor. Ich versuche mein Problem auf den kleinsten Nenner zu reduzieren, um übersichtlich zu bleiben. Wir gehen also von einem unveränderlichen Inhalt aus, der in ein Layout übersetzt werden soll.

Zitat von stahli:

Da wir Deine genauen Schnittstellen und Möglichkeiten nicht kennen und diese sicher auch einige Einarbeitung erfordern würden, bleibe ich dabei, dass Hilfestellung schwierig sein wird.

Es gibt im Moment nicht mehr als die von mir beschriebenen Klassen.

Deine Anmerkung in Bezug auf das Box Modell ist logisch und ich hatte mir diese Abstraktion vorher auch schon überlegt.

Zitat von hansklok:

Zitat von gast2019:

Wieviele Zeichen/Zeilen hast Du denn pro Tabellenfeld, die in Word umgesetzt werden/angezeigt werden müssen/sollen?

Aus meiner Datenstruktur geht doch hervor, da ich strikt auf die Trennung von Daten und Layout Wert lege, da sich TLayoutSection selbstständig um alles kümmern muss. TSection hat keine Ahnung davon, in welcher Spalte sich ein TParagraph befindet. Die Struktur ist genau die, die wir aus Word und Libre Office kennen.

Also:
- TLayoutSection kümmert sich um Alles und
- TSection hat keine Ahnung davon

Klingt einleuchtend für mich, da die Beiden wohl nichts miteinander zu tun haben...

Das übersteigt wohl meinen recht beschränkten Delphi5-Horizont noch etwas, sorry!

Halte es daher künftig mehr mit Nuhr+Fresse

**hansklok**

Zitat von gast2019:

Also:
- TLayoutSection kümmert sich um Alles und
- TSection hat keine Ahnung davon

Im Constructor von TLayoutSection wird das Quellobjekt, eine TSection übergeben (danach ist TLayoutSection.Data = TSection). TLayoutSection soll eine Methode bekommen, die aus den reinen Daten des Zeigers (TLayoutSection.Data) diese grafisch umsetzt. Das bedeutet, dass TLayoutSection aus den Angaben von TSection.Columns und TSection.ColumnWidths erst einmal TLayoutSection.Columns die benötigte Anzahl an Spalten hinzufügt. Danach müssen alle Absätze aus TLayoutSection.Data.Paragraphs ins Layout übersetzt werden. Dazu werden TLayoutParagraph Objekte angelegt usw. Ein TRun.Text kann ja viel länger sein, als eine Spalte. Deswegen muss TLayoutSection die jeweiligen Tuns in einzelne Worte und Leerzeichen splitten. Daraus erziehen wir dann neue TRuns, die dann zu TLayoutLine.Items hinzugefügt werden. TLayoutLine hat die maximale Breite seines Elternelements TLayoutParagraph. Man kann einer TLayoutLine also nur solange diese Teil Runs hinzufügen, solange TLayoutLine.Width kleiner als TLayoutParagraph.Width ist. Ansonsten muss eine neue Zeile eingefügt werden, mit der dann weiterverfahren wird. Für einen einspaltigen Abschnitt ist das wirklich easy zu realisieren, bei Spalten muss man jedoch u.U.für TParagraph ein Teil TLayoutParagraph in TLayoutColumn einfügen, der den rest des vorherigen Absatzes aus der Spalte zuvor zu Ende darstellt. Außerdem müssen all die TLayoutParagraphs darauf achten, dass sie über die Spalten gleichmäßig verteilt sind.

Ja, es geht um den Spaltenausgleich.

Ich verstehe nicht, wo ich mich unverständlich ausdrücke, ehrlich. Vielleicht hat meine Erläuterung jetzt zu etwas mehr Licht geführt. Dankeschön.

**stahli**

@hansklok

Ok, da sich niemand anderes weiter einklinkt, können wir uns ja mal untereinander weiter nerven

Mein Vorschlag zur Annäherung:

Wir sollten vielleicht von Rechtecke reden und Text, Daten und Klassen außen vor lassen.

Ok, wir haben ineinander gesetzte Rechtecke, die auf eine Fläche anzuordnen sind. Die Breiten und Höhen sollen optimiert werden.

Was ist jetzt genau die Vorgabe und das Problem dabei?
Woran scheitert es?

Machst Du vielleicht mal eine Skizze und ein Handyfoto?

**hansklok**

Zitat von stahli:

Wir sollten vielleicht von Rechtecke reden und Text, Daten und Klassen außen vor lassen. ... Wir sollten vielleicht von Rechtecke reden und Text, Daten und Klassen außen vor lassen.

Sehr gern!

Zitat von stahli:

Machst Du vielleicht mal eine Skizze und ein Handyfoto?

Anbei zwei Schemata.

Im Falle meines Layout Schemas sollte festgehalten werden, dass in der Realität für das im Bild gezeigte Szenario, man vermutlich in jeder der drei Spalten jeweils zwei Zeilen an Texten hätte. Dabei würden der Absatz der ersten Spalte auf die zweite aufgeteilt und der Absatz der zweiten Spalte ebenfalls nach Spalte drei aufgeteilt.

**stahli**

Oha. Wir tun uns wirklich schwer miteinander...

Ich verstehe jetzt so viel, dass Du einen roten und einen grünen Rahmen hast, in denen unterschiedlich große und unterschiedlich viele schwarze Kästen stecken.
Jetzt willst Du das so aufteilen, dass alles vernünftig angeordnet wird.

Soweit als Zwischenfazit ok?
Vielleicht kann Dir meine

https://www.delphipraxis.net/117765-...llboxflow.html sogar etwas helfen?

Was ich jetzt schon wieder nicht verstehe ist, warum Du die Inhalte der zwei Kästen jetzt auf 3 aufteilen willst und nach welchen Kriterien.
Die Maße der schwarzen Blöcke sind für mich nicht nachvollziehbar, da da keinerlei Relationen erkennbar sind. Wozu hast Du 100x25 usw angegeben?
Wäre es nicht besser, unterschiedlich große Blöcke zu zeichnen und zu nummerieren? Dann könnte man nachvollziehen, welcher Block wohin bewegt und wie verändert wird.
Dass Du jetzt wieder von Text und Zeilen sprichst, verwirrt mich zusätzlich beim Problemverständnis.

Tut mir leid, dass ich so begriffsstutzig bin, aber vielleicht kommen wir ja doch noch ein Stück weiter.

**hansklok**

Stahli, ich habe die zwei Absätze mit unterschiedlichen Farben gefüllt, um zu demonstrieren, wie diese Container später im Layout formatiert werden. Also nur, damit man sie auseinanderhalten kann.

Die Maße der Kästen sind wie alle Dinge in den beiden Grafiken nur abstrakt dargestellt, um die Problematik zu veranschaulichen.

Zitat von stahli:

Oha. Wir tun uns wirklich schwer miteinander...

Haha.

Zitat von stahli:

Ich verstehe jetzt so viel, dass Du einen roten und einen grünen Rahmen hast, in denen unterschiedlich große und unterschiedlich viele schwarze Kästen stecken.
Jetzt willst Du das so aufteilen, dass alles vernünftig angeordnet wird.

Soweit als Zwischenfazit ok?

Genauso sieht es aus.

Ich habe jetzt nochmal in fragiler Kleinarbeit Grafiken erstellt, die genau zeigen, was alles aus 01 - Daten für das Layout generiert und angeordnet werden muss. Mehr und anders kann ich das Thema nicht veranschaulichen

**stahli**

Ok, dann war ich wohl ziemlich auf der falschen Spur...

Der Renderer müsste auch damit klar kommen, wenn die Spalten nicht schmal, schmal, breit wären sondern z.B. breit, schmal, schmal. Richtig?

Die Breite der Spalten würde immer fest stehen und der Text müsste fließend so eingefüllt werden, dass alle Spalten möglichst gleich hoch gefüllt sind. Korrekt?

Der Renderer müsste also die Texte so zerschneiden, dass sie die 3 Spalten gleichmäßig füllen, auch wenn diese Spalten wiederum in mehrere Abschnitte unterteilt sind. So?

Die Breite der Spalten und die Anzahl deren Unterteilungen stehen zuvor fest und der Renderer muss sich nach dieser Vorgabe richten. Habe ich es jetzt?

**hansklok**

Zitat von stahli:

Der Renderer müsste auch damit klar kommen, wenn die Spalten nicht schmal, schmal, breit wären sondern z.B. breit, schmal, schmal. Richtig?

Ganz genau

Zitat von stahli:

Die Breite der Spalten würde immer fest stehen und der Text müsste fließend so eingefüllt werden, dass alle Spalten möglichst gleich hoch gefüllt sind. Korrekt?

Korrekt.

Zitat von stahli:

Der Renderer müsste also die Texte so zerschneiden, dass sie die 3 Spalten gleichmäßig füllen, auch wenn diese Spalten wiederum in mehrere Abschnitte unterteilt sind. So?

Auch das stimmt.

Zitat von stahli:

Die Breite der Spalten und die Anzahl deren Unterteilungen stehen zuvor fest und der Renderer muss sich nach dieser Vorgabe richten. Habe ich es jetzt?

Du hast es jetzt