Word: Strategie hinter ausgeglichener Spaltenaufteilung

[hansklok]

Hallo,

ich beschäftige mich ja grade mit den Grundlagen von Text Prozessoren und bin auf eine Frage gestoßen.

Angenommen, ich habe einen mehrspaltigen Abschnitt der Absätze enthält, wie würdet ihr vorgehen, um die Spalten ausgeglichen, so wie man es zum Beispiel aus Microsoft Word oder Libre Office kennt, zu rendern und darzustellen?

Hier die Hierarchie:

Code:

- Abschnitt
  - Spalten
    - Absätze
      - Zeilen
        - Runs

Die Schriftgröße des größten Run Wertes einer Zeile, bestimmt deren Höhe. Daraus folgt, dass Zeilen eine unterschiedliche Höhe besitzen können. Die Höhe eines Absatzes ergibt sich aus der Höhe aller Zeilen. Die Höhe einer Spalte ergibt sich aus der Höhe aller Absätze. Die Höhe des Abschnitts ergibt sich aus der Höhe seiner höchsten Spalte (kann variieren, falls es z.B. einen erzwungenen Spaltenumbruch gibt).

Wie könnte man nun beim Erzeugen dieser Struktur vorgehen, wenn man folgende Voraussetzungen hat?

Code:

- Abschnitt mit 3 Spalten (1 Spalte: 4 cm, 2. Spalte: 3 cm, 3. Spalte: 10 cm)
  - Absatz
  - Absatz
  - Absatz

Danke für eure Beiträge.

[Sherlock]

Die Spaltenbreite wird im Word doch nicht automatisch bestimmt, sondern vorgegeben bzw. ist manuell änderbar. Dabei ist sie unabhängig vom Inhalt. So war das zumindest noch bei meinem letzten Abstecher in Word 2013.

Sherlock

[hansklok]

Zitat:

Zitat von Sherlock (Beitrag 1459945)

Die Spaltenbreite wird im Word doch nicht automatisch bestimmt, sondern vorgegeben bzw. ist manuell änderbar. Dabei ist sie unabhängig vom Inhalt. So war das zumindest noch bei meinem letzten Abstecher in Word 2013.

Es geht um das Rendering der Datenstruktur auf eine Canvas! Und dort muss ich ja alle Objekte für das Layout einer Seite aus dem Datenmodell generieren.

[stahli]

Ich hatte mal mit einer längst vergessenen Komponente so etwas in der Richtung versucht: https://www.delphipraxis.net/176186-...omponente.html

Deine Zielstellung ist allerdings recht unscharf formuliert.
Man muss im Einzelfall da sicherlich noch viele Fälle unterscheiden, wann etwas komprimiert, umgebrochen, auseinandergezogen oder verschoben werden darf.

Eine allgemeine Antwort wird also schwierig sein.

[hansklok]

Zitat:

Zitat von stahli (Beitrag 1459957)

Deine Zielstellung ist allerdings recht unscharf formuliert.

Ja? Was genau für Angaben benötigst Du?

[hansklok]

Zitat:

Zitat von stahli (Beitrag 1459957)

Ich hatte mal mit einer längst vergessenen Komponente so etwas in der Richtung versucht: https://www.delphipraxis.net/176186-...omponente.html

Es ist nicht ganz die Richtung von der ich spreche. Mir geht es darum, wie man die Zeilen der Absätze der Datenstruktur (ein Absatz kann aus x Zeilen bestehen), die Teil eines Abschnitts sind, der durch z.B. drei unterschiedlich breite Spalten definiert ist), beim Layouten so günstig über die drei Spalten verteilt, dass man ein einheitliches Bild bekommt und die Spalten (die Klassen der Layout Engine sind), annähern dieselbe Höhe bekommen.

[stahli]

Tut mir leid, ich kann das nicht genug nachvollziehen (wo lässt sich was einstellen, welche Daten liegen vor, kann man vorab außerhalb der Engine etwas berechnen) und entsprechend auch nicht wirklich helfen.

[hansklok]

Ok, also ich habe zwei Module, eines für die Daten, das andere fürs Layout.

Datenstruktur

Code:

TSection:
  Columns: Integer
  ColumnsWidth[]: Double
  Paragraphs[]: TParagraph
  Width: Double

TParagraph:
  Items[]: TRun

TRun:
  Text: String
  FontSize: Double
  FontName: String

Layout Struktur

Code:

TLayout
  Width: Double
  Height: Double

TLayoutSection (TLayout)
  Data: TSection
  Columns[]: TLayoutColumn

TLayoutColumn (TLayout)
  Paragraphs[]: TLayoutParagraph
  Parent: TLayoutSection

TLayoutParagraph (TLayout)
  Lines[]: TLayoutLines
  Parent: TLayoutSection

TLayoutLine (TLayout)
  Items[]: TRun
  Parent: TLayoutParagraph

Die TLayout Klassen, insbesondere TLayoutSection muss aus ihrem Parent (Data) die Spalten und deren (Teil-)Absätze sinnvoll generieren.

[gast2019]

Zwei Spalten in Word sollten reichen. In die Erste schreibt man (mit Zeilenumbrüchen) rein, wohin der Excel-Link der zweiten Spalte führt.

IMHO nennt man das, was Du suchst "optimale Spaltenbreite". Word und Excel parsen/rendern daher, bevor sie reagieren?

Siehe #4 von stahli :-)

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

Und wenn das irgendwann mal klappen sollte, kommt jemand mit der Forderung nach einem lesbaren Ausdruck (auf Nadel/Tinte/Laser) um die Ecke...

Danach kommen farbige Ausdrucke auf unterschiedlichen Papierformaten.
Alles leider schon selbst (mit damals dBase3) erlebt :-(

Toitoitoi!

[hansklok]

Zitat:

Zitat von gast2019 (Beitrag 1459968)

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.

[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:

Zitat von stahli (Beitrag 1459974)

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:

Zitat von stahli (Beitrag 1459974)

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.

[gast2019]

Zitat:

Zitat von hansklok (Beitrag 1459971)

Zitat:

Zitat von gast2019 (Beitrag 1459968)

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 :wink:

[hansklok]

Zitat:

Zitat von gast2019 (Beitrag 1459976)

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:

Zitat von stahli (Beitrag 1459978)

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:

Zitat von stahli (Beitrag 1459978)

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:

Zitat von stahli (Beitrag 1460000)

Oha. Wir tun uns wirklich schwer miteinander...

Haha.

Zitat:

Zitat von stahli (Beitrag 1460000)

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:

Zitat von stahli (Beitrag 1460004)

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:

Zitat von stahli (Beitrag 1460004)

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:

Zitat von stahli (Beitrag 1460004)

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:

Zitat von stahli (Beitrag 1460004)

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 ;)

[stahli]

Ich bin schon eine gei... Sau - oder? :stupid:

Ok, mal drauf rum denken...


Wenn man davon ausgeht, dass der Text annähernd homogen ist, dann könnte man vielleicht als Ausgangsbasis vom Gesamtvolumen des Textes ausgehen.

Als Idee:

- Text komplett in Spalte 1 rendern, so dass Du z.B. 300 kurze Zeilen hast mit deren höhen und und der benötigten Gesamthöhe.
- Wenn Du jetzt 3 gleich breite Spalten hättest, wäre die Aufteilung rel. einfach. Eben dritteln (jeweils 100 Zeilen) und gut ist.
- Bei unterschiedlich breiten Spalten musst Du einen Faktor mit einrechnen (bei Breiten 30, 30, 60) wäre die dritte Spalte doppelt so breit wie die ersten zwei und müsste 2 mal so viel Zeilen aufnehmen wie die ersten beiden (75, 75, 150 Zeilen von der ersten Berechnung).
- die dritte Spalte müsste wegen den Umbrüchen natürlich neu berechnet werden.
- Wenn diese Annäherung noch nicht passt, musst Du weitere Tests machen (z.B. mit 72, 72, 156 Zeilen) und neuer Berechnung der dritten Spalte. Bis das Ergebnis ok ist.


Hilft Dir das? Hattest Du ähnliche Gedanken?

Kann natürlich auch naiv und untauglich sein, aber das wäre mein erster Ansatz.

[hansklok]

Zitat:

Zitat von stahli (Beitrag 1460007)

Ich bin schon eine gei... Sau - oder? :stupid:

Haha, kein Kommentar.

Zitat:

Zitat von stahli (Beitrag 1460007)

- Text komplett in Spalte 1 rendern, so dass Du z.B. 300 kurze Zeilen hast mit deren höhen und und der benötigten Gesamthöhe.

Du meinst also die gesamte Breite des Absatzes?

Zitat:

Zitat von stahli (Beitrag 1460007)

- Bei unterschiedlich breiten Spalten musst Du einen Faktor mit einrechnen (bei Breiten 30, 30, 60) wäre die dritte Spalte doppelt so breit wie die ersten zwei und müsste 2 mal so viel Zeilen aufnehmen wie die ersten beiden (75, 75, 150 Zeilen von der ersten Berechnung).

Und an welchen Faktor oder welche Vorgehensweise denkt Du da?

Zitat:

Zitat von stahli (Beitrag 1460007)

- Wenn diese Annäherung noch nicht passt, musst Du weitere Tests machen (z.B. mit 72, 72, 156 Zeilen) und neuer Berechnung der dritten Spalte. Bis das Ergebnis ok ist.

So in etwa waren auch Gedankengänge von mir. Die Frage ist, wie könnten die Methoden dazu aussehen? Einiges hört sich für mich nach Iteration an. Auch wenn ich schon lange entwickle, bin kein Profi, habe ich damit nie zu tun gehabt und tue mich immer schwer mit dem Verständnis dieser.

Zitat:

Zitat von stahli (Beitrag 1460007)

Kann natürlich auch naiv und untauglich sein, aber das wäre mein erster Ansatz.

Naiv ist immer gut. Vielen Dank.

[stahli]

"coole Sau" oder "geiler Typ" wäre wohl auch passender gewesen... ;-)

Also nochmal:

- alles rendern in eine schmale Spalte (Breite = 30) -> ergibt 300 Zeilen Text und 3000 Pixel Höhe
- 3 Spalten mit Breiten 30, 30, 60 ergeben 100% Breite
- Ergibt Faktoren pro Spalte 0.25, 0.25, 0.5
- also Zeilen pro Spalte 75, 75, 150
- das wäre die erste Abschätzung
- für die ersten 2 Spalten könnte man das erste Ergebnis sofort übernehmen und die Höhe auf 750 festlegen
- die dritte Spalte müsste neu berechnet werden, wegen den verschobenen Wortumbrüchen
- die benötigte Höhe kann nun kleiner sein (größer eher nicht, würde ich denken)
- wenn der freie Platz zu groß ist, könntest Du die Gesamthöhe von 750 und 75 Zeilen zeilenweise reduzieren, bis die Spaltenhöhen der Texte ausgeglichen sind.

[hansklok]

Danke für Deinen Beitrag.

Zitat:

Zitat von stahli (Beitrag 1460015)

- alles rendern in eine schmale Spalte (Breite = 30) -> ergibt 300 Zeilen Text und 3000 Pixel Höhe
- 3 Spalten mit Breiten 30, 30, 60 ergeben 100% Breite

Wie kommst Du auf diese Werte? 30 + 30 + 60 = 120 :?

Ich habe mir eben noch einmal angesehen, wie Microsoft Word vorgeht. Dort wird erst ab der 4. Zeile in der ersten Spalte umgebrochen. Danach wird die Lage neu bewertet. Anbei ein Bildschirmvideo, wie das in MS Word aussieht. Kann man daraus eine Abfolge, einen Algorithmus ableiten?

[stahli]

Die beispielhaften 120 Einheiten (cm oder was auch immer) wären halt 100% der Breite der Zeichenfläche.
Also Spalten 1 und 2 hätten 1/4 der Gesamtbreite und die rechte Spalte 1/2.

Das Video schaue ich mir im Laufe des Tages mal an...

[hansklok]

Also in Microsoft Word werden ab vier Zeilen in der ersten Spalte dann Zeile drei und vier in die zweite spalte verschoben. 
Sobald wir eine fünfte Zeile haben, wird die logische (fortlaufende) Zeile 4 (Zeile 1 aus der 2. Spalte) in die erste Spalte verschoben. Bei insgesamt sechs Zeilen, wird wieder alles einheitlich über die drei Spalten aufgeteilt (2 Zeilen pro Spalte). 

Erkennst ihr eine Logik, ein Muster, welches man in einem Algorithmus ausdrücken kann?

Es sieht für mich danach aus, als wäre es immer so, als würde die Anzahl der Zeilen von einer Spalte immer der Zeilenanzahl der vorherigen Spalte minus eins betragen.


[Sherlock]

Was Du da beobachtest ist die Vermeidung von Hurenkindern und Schusterjungen. Das lässt sich irgendwo in den Tiefen der Einstellungen der Textverarbeitung schalten.

Sherlock

[stahli]

Ok, ich habe mir das Video mal angesehen.

Ich würde es tatsächlich so anfangen, wie oben besprochen und dann Stück für Stück verfeinern.
Die grundsätzliche Frage ist, was Dir am wichtigsten ist.

Angenommen, Du hast Text mit 3 Zeilen.

Du kannst nun sagen, das Wichtigste ist, alle drei Spalten gleichmäßig zu füllen.
Dann kommt jede Zeile in eine Spalte.

Oder Du sagst, die Spalten sollen möglichst nicht höher werden als 10 Zeilen.
Dann füllst Du erst die linke Spalte bis zehn Zeilen und machst dann weiter rechts weiter.
Erst nach 30 Zeilen vergrößerst Du alle Spalten.

Das ist halt Geschmackssache und auch davon abhängig, wie Deine Text aussehen.
Können die auch dynamisch wachsen, wie beim Tippen im Video? Oder gibt es quasi einen festen Satz, der quasi gedruckt wird?

Mein Ansatz von oben würde die Spalten immer möglichst gleichmäßig ausfüllen.
Statt aber ständig zeilenweise immer wieder für alle Spalten neue Ergebnisse auszurechnen und diese immer weiter neu aufzufüllen, würden die ungefähren Ergebnisse schon mal zuvor abgeschätzt.
Da braucht es dann sicher noch etwas Feinarbeit, um an die bestmöglichen Abschätzungen zu kommen.
Zum Schluss gibt es dann noch ein paar Iterationen, um zum Endergebnis zu kommen.

So würde ich es wohl machen.

[hansklok]

Zitat:

Zitat von stahli (Beitrag 1460075)

Können die auch dynamisch wachsen, wie beim Tippen im Video? Oder gibt es quasi einen festen Satz, der quasi gedruckt wird?

Es gibt einen festen Satz.

Zitat:

Zitat von stahli (Beitrag 1460075)

Zum Schluss gibt es dann noch ein paar Iterationen, um zum Endergebnis zu kommen.

Was für Iterationen?

Die Sache ist folgende, dadurch, dass Zeilen eine unterschiedliche Höhe haben können, dürfte das doch den Ansatz, erstmal alles in eine Spalte zu packen und dann durch die Anzahl der Spalten zu teilen, um dann die restlichen Zeilen zu befallen, schwierig sein, oder?

[stahli]

Du wirst keine Formel finden, die Dir die beste Höhe und die besten Umbrüche vorab ausgibt (ohne wirkliche Texte zumindest temporär zu schreiben und die Höhen und Breiten zu ermitteln.)

Bei jeder kleinen Änderung können sich am Ende wieder völlig andere Ergebnisse ergeben. Insofern wird es mehrere Durchläufe brauchen, um ein gutes Ergebnis zu erhalten.

Im Fall einer fließenden Eingabe (wie beim Tippen) wird man versuchen, nicht ständig vor und zurück zu springen und eine gewisse Kontinuität beizubehalten (also nicht bei jedem Tastendruck das vorherige Ergebnis komplett verwerfen, sondern erst mal davon weiter ausgehen). Aber das brauchst Du ja nicht, da Du einen fertigen Text hast, der in bestimmte Spalten gesetzt werden soll.

Da der Text und die Spalten gegeben sind, könntest Du zunächst eine grobe Annäherung berechnen (z.B. wie ich vorgeschlagen hatte - das sollte eigentlich grob funktionieren).

Da es aber nicht genau passen wird, musst Du Dich nachher mit einigen Durchgängen noch einer optimalen Lösung annähern. Das meinte ich mit Iterationen.

Direkt bei der Vorberechnung die Höhe der einzelnen Zeilen zu beachten, wird schwierig werden. Du weißt ja vorab nicht, ob hohe Zeilen eher in der linken, mittleren oder rechten Spalte landen werden oder vielleicht sogar ausgeglichen sind. Diese Feinheiten sollten dann bei den Optimierungsdurchläufen berücksichtigt werden.