Wenn Du nicht permanent rechnen willst, dann hat jedes Zeichen seine eigenen Attribute. RTF,
HTML und alle anderen Formate beschreiben ja nur die Texteingabe. Die Darstellung des Textes ist da eine ganz andere Baustelle.
Sagen wir mal, ich gebe mit
TextOut eine Zeile aus, dann hab ich doch vorher schon alles andere berechnet: Schriftart, -stil, -grösse, -farbe usw.:
TextOut(X, Y, MeineZeile);
Ich muss vor der Ausgabe also nur "rechnen" (den Prozessor beanspruchen), wenn sich in der Zeile Änderungen an diesen Parametern ergeben, z.B. ein {b} für die Einleitung von Fettschrift. Ich brauch also einen Parser für das Text-Script (Text mit Steuerzeichen), der alles veranlasst. Das stelle ich mir so vor, dass ich eine Klasse habe, die eine Struktur anbietet, in der ich z.B. eine Zeile zusammenstellen kann. Im Parser muss ich mir auch nicht jedes Zeichen anschauen, sondern immer nur nach den Steuerzeichen suchen. Alles zwischen zwei Steuerzeichen bleibt unverändert. Findet er ein Steuerzeichen, muss er darauf mit einer Methode reagieren, die die Schriftparameter setzt. Dabei habe ich im Speicher in einer anderen Struktur Platz für einen kompletten Satz von Steuerzeichen (eine weitere Klasse, aus der ich Steuerzeichensätze instanziere), den ich durch das Script-Steuerzeichen identifizieren kann. Habe ich eine Zeile zusammen, wird die im Schleifendurchlauf ausgegeben, wobei die Schleife nur einmal durchläuft, wenn in der Zeile keine Steuerzeichen sind.
Die Länge der Zeile ist nochmal eine andere Baustelle, das hab ich jetzt erstmal unterschlagen. Aber ich denke, wenn ich in meiner Klassenstruktur jedem Zeichen alle verfügbaren Attribute verpasse, muss ich mehr rechnen. Vielleicht irre ich mich ja auch, dann wäre es lieb, wenn du mir genauer erklärst, warum man bei deiner Vorgehensweise weniger rechnen muss.
Ein Absatz besteht aus einer Zeile. Ist diese Zeile länger als die Canvas Breite, wird diese umgebrochen. Also gibt es innerhalb von Absätzen Codeblöcke, die jeweils die Zeilen enthalten. Geht eine Textzeile also über zwei Zeilen (wegen des Umbruchs), so muss der Absatz 2 Codeblöcke enthalten. Codeblock 2 bezieht seine Position dann aus der Position des vorherigen Codeblocks. Das Dokument wiederum hat dann eine Liste von Absätzen, die es dann untereinander darstellen kann. Analog zu den Codeblöcken oben, beziehen die Absätze ihr Position jeweils aus der Position und Höhe des vorherigen.
Das sind die Gedanken zur Darstellung. Nun gilt es einen Weg zu finden, Zeilen innerhalb des Canvas bei der WYSIWYG-Eingabe umzubrechen, also einen neuen Codeblock innerhalb des aktiven Absatzes anzulegen. Welches Absatz und welcher Codeblock aktiv ist, müssten anhand der Koordinaten des Mauszeigers errechnet werden. Ebenfalls, an welcher Stelle sich der Cursor (Caret) befindet, um Text weiter einzugeben.
Eine Textzeile besteht aus Wörtern. Diese haben z.B. im Constructor fest definierte Anfangswerte für Größe, Schriftart, Schriftfarbe etc. Wird ein Teile des Wortes markiert und die Werte geändert, müsste also innerhalb des WordsArray der Textzeile an der entsprechenden Stelle ein neues Wort eingefügt werden. Dann mit den neuen Eigenschaftswerten.
Meine Gedanken dazu.
Was dann später noch dazukommt, und da habe ich überhaupt keine Ahnung, wie man, damit man sich den Arbeitsspeicher nicht zukracht, immer nur den benötigten Ausschnitt auf dem Canvas darstellt. Oder anders, wie man eine Seitendarstellung (A4 etc.) machen kann, die kontinuierlich scrollt, aber ebenfalls nicht den Arbeitsspeicher crasht.
Ich weiss nicht so recht, was du mit "Codeblock" meinst. Man muss hier wirklich sehr sorgfältig und gründlich vorgehen und alle Eventualitäten berücksichtigen. Und am besten man fängt erst zu programmieren an, wenn man das ganze Konzept vorher auf Papier ausgearbeitet hat.
Angenommen, du hast eine Zeile auszugeben, die wie die folgende aussehen soll:
Wenn man ein
Fachbuch über das
Schreiben von Fachbüchern
schreibt, gerät man in eine vertrackt
selbstreflexive Position.
Dann
berechnest du erstmal die Länge der Zeile, indem du die Längen jeder Einheit dieser Zeile addierst. Als Einheit verstehe ich Zeichen, die zwischen zwei Anweisungen stehen, hier erstmal das W mit grösserer Schrift und in Fett:
L := TextWidth(MeinText);
natürlich mit vorangegangener Einstellung der Textparameter. Zu diesem Zweck hast du einen virtuellen Canvas im Speicher. Ist die gesamte Zeile (alle Resultate der verschiedenen Textlängenberechnungen addiert) länger als die Breite des Ziel-Canvas, musst du die Zeile kürzen.
Ich hab das auch noch nie gemacht, obwohl mir schon ein paarmal der Gedanke kam, das war mir aber dann doch zuviel Arbeit. Heute verwende ich auf Arbeit eine professionelle Lösung von einem Drittanbieter, um professionell aussehende Texte ausgeben zu können. Da stecken garantiert ungezählte Mannjahre an Arbeit drin. Trotzdem bin ich sicher, dass du, wenn du nach und nach das ganze Konzept erarbeitet hast, zu einer funktionierenden Umsetzung kommst. Du musst halt nur vorher wissen, was du alles brauchst und dir dann überlegen, wie du diese Dinge in Delphi realisierst, also eine Klasse, die deine mit dem Parser zu analysierenden Zeilen enthält. Da du mit D2010 arbeitest, hast du
Unicode-Strings und kannst in so einen String einen ganzen Absatz reinpacken, das wäre dann eine Zeile in der Klassenstruktur, oder eine Stringliste. Wie man die Berechnungen jetzt alle so macht, willst du ja eigentlich selber herausfinden, um was zu lernen, wenn ich das richtig verstanden habe.