RichEdit: Seiten-Umbruch erkennen/auswerten/drucken

**TERWI**

Ich bastle hier grade an einem Tool, in dem vorgefertige RTFs u.a. als Hilfe-Anzeige genutzt werden sollen, bzw. um eigene RTFs (Formulare) programmintern erstellt und alle gedruckt werden sollen.

Vorgefertigte Texte erstelle ich mit LibreOffice - da hab ich meinen Seiten-Umbruch...
Wie erkenne ich aber diese nach laden ins Proggie ?
Auch diese sonst so tolle Komponente TPrintPreview (Delphi-Area) bekommt es nicht hin.
Hier wird "gedruckt", bis die Seite voll ist und erst dann kommt ein Seitenumbruch.
Die Delphi-eigene Kompo (hier D2009) scheint da auch nix zu bieten.

Wenn ich das in den Specs zu RTF richtig gelesen habe, gibt es ja Symbole/Flags wie \page oder \pagebb (das nutzt LibreOffice) um da entsprechendes anzuzeigen.

Hat jemand Ideen, wie man z.B. das ganze RTF in einzelne RE's (temporär) aufteilen kann ?
Bzw. wie ich einen Seitenumbruch "richtig" selbst codiere ?
Mir fehlt da etwas der Ansatz weil Newbie auf diesem Sektor. Und das Rad will ich nicht unbedingt neu erfinden ....

**p80286**

Zum einen muß ein RTF-Interpreter nicht zwangsläufig \page oder \pagebb kennen. Zum anderen, bist Du sicher, daß diese in der RTF-Datei vorkommen?

Zumindest das Richedit in D7 ignoriert alles was mit Seitentrennung zu tun hat (Kopf/Fußzeile neue Seite)

Gruß
K-H

**TERWI**

Zitat:

Zum einen muß ein RTF-Interpreter nicht zwangsläufig \page oder \pagebb kennen. Zum anderen, bist Du sicher, daß diese in der RTF-Datei vorkommen?

... das eben scheint ja hier das Prob zu sein !

Hier mal meine kleine Test-Datei "DivPages.rtf" mit 3 Seiten aus LibreOffice:

markieren

Code:

			{\rtf1\ansi\deff3\adeflang1025

{\fonttbl{\f0\froman\fprq2\fcharset0 Times New Roman;}{\f1\froman\fprq2\fcharset2 Symbol;}{\f2\fswiss\fprq2\fcharset0 Arial;}{\f3\froman\fprq2\fcharset0 Liberation Serif{\*\falt Times New Roman};}{\f4\fswiss\fprq2\fcharset0 Liberation Sans{\*\falt Arial};}{\f5\fnil\fprq2\fcharset0 Microsoft YaHei;}{\f6\fnil\fprq2\fcharset0 Mangal;}{\f7\fnil\fprq0\fcharset128 Mangal;}}

{\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue255;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red255\green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\green128\blue128;\red0\green128\blue0;\red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red128\green128\blue128;\red192\green192\blue192;}

{\stylesheet{\s0\snext0\nowidctlpar\hyphpar0\cf0\kerning1\dbch\af8\langfe2052\dbch\af6\afs24\alang1081\loch\f3\hich\af3\fs24\lang1031 Normal;}

{\s15\sbasedon0\snext16\sb240\sa120\keepn\dbch\af5\dbch\af6\afs28\loch\f4\fs28 \u220\'dcberschrift;}

{\s16\sbasedon0\snext16\sl288\slmult1\sb0\sa140 Textk\u246\'f6rper;}

{\s17\sbasedon16\snext17\sl288\slmult1\sb0\sa140\dbch\af7 Liste;}

{\s18\sbasedon0\snext18\sb120\sa120\noline\i\dbch\af7\afs24\ai\fs24 Beschriftung;}

{\s19\sbasedon0\snext19\noline\dbch\af7 Verzeichnis;}

}{\*\generator LibreOffice/5.4.2.2$Windows_X86_64 LibreOffice_project/22b09f6418e8c2d508a9eaf86b2399209b0990f4}{\info{\creatim\yr0\mo0\dy0\hr0\min0}{\revtim\yr2017\mo12\dy8\hr15\min36}{\printim\yr0\mo0\dy0\hr0\min0}}{\*\userprops}\deftab709

\viewscale200

{\*\pgdsctbl

{\pgdsc0\pgdscuse451\pgwsxn11906\pghsxn16838\marglsxn1134\margrsxn1134\margtsxn1134\margbsxn1134\pgdscnxt0 Standard;}}

\formshade\paperh16838\paperw11906\margl1134\margr1134\margt1134\margb1134\sectd\sbknone\sectunlocked1\pgndec\pgwsxn11906\pghsxn16838\marglsxn1134\margrsxn1134\margtsxn1134\margbsxn1134\ftnbj\ftnstart1\ftnrstcont\ftnnar\aenddoc\aftnrstcont\aftnstart1\aftnnrlc

{\*\ftnsep\chftnsep}\pgndec\pard\plain \s0\nowidctlpar\hyphpar0\cf0\kerning1\dbch\af8\langfe2052\dbch\af6\afs24\alang1081\loch\f3\hich\af3\fs24\lang1031{\rtlch \ltrch\loch

PAGE 1}

\par \pard\plain \s0\nowidctlpar\hyphpar0\cf0\kerning1\dbch\af8\langfe2052\dbch\af6\afs24\alang1081\loch\f3\hich\af3\fs24\lang1031\rtlch \ltrch\loch

\par \pard\plain \s0\nowidctlpar\hyphpar0\cf0\kerning1\dbch\af8\langfe2052\dbch\af6\afs24\alang1081\loch\f3\hich\af3\fs24\lang1031\pagebb{\rtlch \ltrch\loch

PAGE 2}

\par \pard\plain \s0\nowidctlpar\hyphpar0\cf0\kerning1\dbch\af8\langfe2052\dbch\af6\afs24\alang1081\loch\f3\hich\af3\fs24\lang1031\rtlch \ltrch\loch

\par \pard\plain \s0\nowidctlpar\hyphpar0\cf0\kerning1\dbch\af8\langfe2052\dbch\af6\afs24\alang1081\loch\f3\hich\af3\fs24\lang1031\pagebb{\rtlch \ltrch\loch

PAGE 3}

\par \pard\plain \s0\nowidctlpar\hyphpar0\cf0\kerning1\dbch\af8\langfe2052\dbch\af6\afs24\alang1081\loch\f3\hich\af3\fs24\lang1031\rtlch \ltrch\loch

\par }

Man findet darin 2x " \pagebb" -andere schreiben vielleicht nur "\page" (wenn überhaupt ?!)

**p80286**

Da das TPrintview auf TRichedit basiert manifestieren sich die Unzulänglichkeiten von TRichEdit auch in TPrintPreview. Wenn ich Dich richtig verstanden habe, hast Du ein RTF-Dokument, das mehrere Seiten (explizit formatierten) Text enthält. Diese Seiten möchtest Du jeweils in einem eigenen Fenster anzeigen. Ist das soweit richtig?

Gruß
K-H

**TERWI**

Korrekt erkannt: Siehe Quelltext in #3. Das sind 3 Seiten, auf jeder steht nur jeweils 'page..'. Der Seitenumbruch wurde in LibreOffice mit Strg-Enter erzeugt (geht in Word genau so).

Es soll nun auch genau so gedruckt werden, wie das RTF in LO angezeigt wird - also hier 3 Seiten mit jeweils nur einer Zeile.

Auch wenn ich das 'per Hand' selber rendere und auf PDF24 drucke, habe ich keinen Seitenumbruch - dieser kommt dann wie in TPrintPreview nur als neuer Absatz/Zeile.
Ich müsste nun ggf. eine Latte Leerzeilen einfügen, damit das dann passt, aber das kann nicht klappen, wenn man die Seitenformatierung ändert ....

Ist mir irgendwie schleierhaft, warum nach das nach xx Jahren (immer) noch nicht richtig implementiert ist. Ich bin doch sicher nicht der erste, dem das aufgefallen ist.

Mein Ansatz ist im Moment, der RTF-Source nach '\page(bb)' zu parsen und dann z.B. den jeweils davor liegenden Text in ein separates RE zu kopieren und zu drucken.
Aber wie stellt man das am gescheitesten an, ohne das Rad neu zu erfinden ?
Da gibt es doch bestimmt schon was ... aber wo ?

Eine andere Idee hab ich gelesen, ein Sonderzeichen in den Text einzufügen (z.B. #12) und dann mit RE.FindText zu suchen und dann zu separieren.
Wird sicher funzen, aber auch keine gute Lösung, weil dann die Texte entsprechend geschrieben werden müssen und 'normaler' Text mit Seitenumbruch von irgendwo her auch nicht passend gedruckt wird.

**p80286**

Naja, Ich vermute Du sitzt da dem verbreiteten Irrtum auf, das Trichedit wäre ein Wysiwyg-Editor. U.U. gibt es Komponenten, die das können, die kenn ich aber nicht.
Deinen Ansatz nach \page* zu scannen halte ich nicht für falsch, allerdings müßtest Du auch für jede Seite die Definitionen vom Anfang des Dokumentes mitschleppen (z.B. Fontdefinitionen) und da ist eine RTF-Datei, die durch eine Textverarbeitung erstellt wird, alles andere als schlank.

Gruß
K-H

**TERWI**

Ne ne, als Editor (schon gar nicht Wysiwyg) betrachte ich das nicht. Ich will hier ja keinen basteln, sondern feritge RTFs nutzen.

Was mich stört ist, das man lediglich (in TPrintPreview 'RichTextDemo') mitbekommt, wann der zu druckende Text eben nicht mehr auf den Druckbereich passt und dadurch erst dann eine neue Seite generiert wird. Das ist zwar schon sehr schön, aber eben nur die halbe Miete.

Ein \page* wird/sollte da schon eher kommen. Warum wird das nicht ausgewertet ???
... ich bin diesbezüglich noch nicht tief genug im Thema - ich hample erst seit einigen Tagen damit rum.
Ein Ansatz sehe ich vielleicht hier:

Klick mal drauf

Betreff Dokument-Formatierung:
Scheint sich TPrintPreview nicht sonderlich dran zu stören - die Beispiele im o.g. Link auch nicht.

Kann TJvRichEdit da vielleicht mehr ?

**p80286**

Zitat von TERWI:

Kann TJvRichEdit da vielleicht mehr ?

Weiß ich nicht, könnte aber sein. In älteren Threads wurde darauf hingewiesen, das die dort unterstützte Version von RTF um einiges aktueller ist.

Gruß
K-H

**TERWI**

... hab mal die JVCL_Master gezogen - sind ja NUR 51 MB, entpackt 220 MB. Das tue ich mir erst mal nicht an ...
Da werde ich mich dann wohl mal selbst auf den Weg machen und die RTF-Abgründe erforschen und einen kleinen Parser dazu basteln.

Interessante Lektüre dazu

Angedachte Vorgehensweise:
- RTF im Source nach \page* durchsuchen
- Zugehörige Zeile ermitteln
- Im RE bis dahin in Temp-RE kopieren (mit Formatierungen ?!)
- Temp-RE rendern, nächste Seite
- ... solange bis kein \page mehr kommt.

Für den Anfang hab ich was in Delphi gefunden:

MWKEdit. Sieht relativ unkompliziert und vielversprechend aus.

Falls noch jemand andere Ideen, Tipps oder Links hat - her damit.
Ich melde mich wieder, wenn's hier was brauchbares gibt.

**TERWI**

HEUREKA

Ich hab's elemtar auf dem Schirm

... JA: auch Delphi's TRichEdit kennt so was wie '\page'' ! Wertet das nur nicht wirklich aus (gibt es aber 'weiter')...

Bevor ich euch meine Bastelei zeige, muss ich dass alles noch ein bischen in eine begreifbare Reihe bringen. Nach nunmehr > 48 Stunden ununterbochenem Hard-Learning & Heavy-Coding in Sachen RTF brauche ich etwas Ruhe... dann gibbet Quell-Kram zum selber testen.

Please be patient & stay tuned !