SoftMaker.de

Hi
In einer neu angelegten tmv-Vorlagendatei sind lediglich drei gif oder png Grafiken zu 40 kB bis 80 kB Größe und einige Textrahmen enthalten. Die entstehende Dateigröße ist mit rund 220 kB auch dazu passend / angemessen.

Um diese Vorlage zusammen mit einem CRM-System (julitec) verwenden zu können, muss ich sie im RTF-Format speichern. Dabei nimmt ihr Volumen auf 133 MB zu! Würde ich damit über das CRM-System einen Serienbrief an 100 Teilnehmer versenden wollen, entsteht eine Druckdatei von über 133 GB. Lustig!

Ich habe drei ähnliche Vorlagendateien, die fast genau so aufgebaut sind und auch Grafiken enthalten. Bei allen funktionierte die Speicherung als RTF reibungslos. Aus einer 69 kB TMV-Datei wurde allerdings eine 591 kB große RTF-Datei. Auch das halte ich zwar für viel zu viel, könnte aber damit notfalls auskommen.

In den o.g. Vorlagen sind Platzhaltertexte für das Einfügen von Feldern enthalten, die das CRM benötigt. Diese Texte beginnen und enden mit Rauten wie z.B. #Textbeginn##AnschriftBrief##Anrede.Ansprechpartner##Textende#

Von MS-Word & Co weiß ich, dass diese Programme von jeder eingebetteten Grafik mehrere Versionen im RTF mit speichern, wodurch die Dateigröße enorm anschwillt. Durch einen Registry-Eintrag kann man diesen Effekt verhindern. Vielleicht ist es hier ein ähnliches Problem, das sich ebenfalls per Registry-Eintrag lösen lässt?

PS: Es ist keine Lösung, die Grafik lediglich durch Verknüpfung ins Dokument einzufügen, weil es beim Druck des Serienbriefs sowie generell beim Zusammenspiel mit dem CRM-System dann zu Schwierigkeiten kommen kann.

RTF mit Bildern ist generell problematisch. Eine einfache Lösung gibt es dafür nicht.
Der Grund ist ganz einfach folgender:
RTF ist intern so aufgebaut, dass nur ASCII-7-Zeichen vorkommen. Sonderzeichen, zu denen dann bereits die deutschen Umlaute gehören, müssen ebenso codiert werden wie Linien oder Pixelgraphiken. Und zur Codierung von Pixelgraphiken hat man sich folgendes ausgedacht: Jedes Byte der Originaldatei wird durch einen zweistelligen Code aus Buchstaben repräsentiert.
Das ist genau der Grund, warum sich RTF-Dateien unverhältnismässig aufblasen, sobald Pixelbilder darin enthalten sind.
Eine einfache Lösung gibt es in dem Sinne nicht. Am einfachsten wäre wohl am Ende die Anschaffung eines CRM, das andere Dateiformate als RTF liest. Ansonsten käme eigentlich nur noch in Frage, die verwendeten Bilddateien "abzuspecken", also ihre Auflösung zu verringern, so dass weniger Bytes codiert werden müssen.

Das lässt sich alles aber nur generell sagen, im Einzelfall müsste man das je nach Datei und zugehörigen Graphiken beurteilen, daher ggf. eine Nachricht an support(at)softmaker.de bzw. forum(at)softmaker.de mit beigefügten Beispieldateien und Problembeschreibung schicken.

Vielen Dank für diese ultraschnelle Antwort! Und das noch über's Wochenende!

Ich halte es für sehr wenig wahrscheinlich, dass julitec in seinem CRM vom RTF-Vorlagenformat abweichen wird. Man verwendet es bereits seit der ersten Programmversion. Das julitec-CRM ist endlich genau das CRM, was meine Anforderungen erfüllt und daher mag ich es nicht aufgeben.
Ich finde es oftmals besser, vorrangig eigene Lösungen zu entwickeln und sich nicht abhängig zu machen. Daher meine Frage, ob Textmaker die Platzierung von Vektorgrafiken unterstützt und wenn ja, welche. Oder ob es eine andere Möglichkeit von Einbettungen gibt.

Tatsache ist jedenfalls, dass ich zwei Kleinstunternehmen betreibe und es ein völlig übertriebener Aufwand wäre, zum gegenwärtigen Zeitpunkt für jedes Unternehmen geeignete Briefpapiere drucken zu lassen, ich zugleich aber auf die professionelle grafische Gestaltung der Korrespondenz nicht verzichten kann.
Mir ist dabei durchaus klar, dass dies nicht mehr unmittelbar ein Textmaker-Thema ist.

Vielleicht gibt es doch noch Lösungsideen?

Das Problem besteht leider bei eingebetteten Vektordateien ähnlich fort: Diese werden ebenfalls aufgebläht, wobei der Effekt allerdings nicht ganz so schwer wiegt, da diese Dateien kleiner sind. Mit einem Test-Dokument, das als TMD rund 20 KB gross ist und ein Vektorbild, das als Datei ca. 18 KB benötigt, habe ich das mal getestet: RTF wird über 80 KB gross.
Weiter kommt erschwerend hinzu, dass es bei den Vektorformaten eine grosse Zahl gibt, die teilweise für sehr spezielle Anwendungen bestimmt sind. TextMaker unterstützt bisher zuverlässig allein das WMF-Format, wobei dieses aber kein reines Vektorformat ist, sondern auch Pixeldaten enthalten kann. EMF und SVG stehen meines Wissens auf der Wunschliste.

Immerhin gibt es eine Möglichkeit, die ohne wesentliche Aufblähung auskommt: Werden graphische Elemente wie Linien, Rechtecke, Kreise u. dgl. mit den entsprechenden Funktionen direkt in TM gezeichnet, dann werden diese unmittelbar im RTF-Dokument mit den RTF-eigenen Codierungen niedergelegt. Auch diese benötigen mehr Platz als in einem Binärformat wie TMD oder DOC, doch kommen sie vergleichsweise knapp daher und werden nicht übermässig aufgebläht.

Wenn Sie uns die Originaldatei einmal einsenden, können wir Ihnen vermutlich sagen, warum in Ihrem speziellen Fall die Dateigröße so zunimmt, sobald Sie im rtf-Dateiformat speichern. Wie Panosis schon sagt, liegt es vermutlich an den Grafiken.

_________________
Sven Leßmann
SoftMaker Software GmbH

Heute habe ich mal einen kleinen Test zu RTF und Pixelbildern gemacht:

Ich habe ein Bild von 1000x1000 Pixel erstellt und in den Formaten BMP, JPG, PNG sowie WMF gespeichert. Der Witz an diesem Bild: Es enthält nichts als eine schwarze Fläche. (Somit wäre es an sich möglich, die gesamte Fläche durch die Angabe der Koordinaten der beiden Eckpunkte oder durch die Festlegung der Bildgrösse in Pixel sowie durch die Farbangabe zu definieren und eindeutig zu reproduzieren. Diese Angaben benötigten ein paar Bytes, mehr nicht.)

Hier nun die Angaben der Dateigrössen in Bytes:

BMP: 3'000'054
JPG: 27'987
PNG: 4'457
WMF: 7'022'830

RTF/BMP: 6'069'857
RTF/JPG: 6'115'845
RTF/PNG: 6'068'356
RTF/WMF: 14'187'306

Bei den Orginalbildern sind die Schwankungen erklärlich: BMP benutzt eine sogenannte Run-Length-Encoding-Komprimierung, die vergleichsweise wenig komprimiert. JPEG komprimiert stark, enthält aber in jedem Fall die Farbinformationen, weshalb bei schwarzweisen oder sonst monochromen Bildern die Kompression recht schlecht ist (ab drei tatsächlich verwendeten Farben wäre dies verhältnismässig günstiger). PNG staucht ingesamt am meisten, WMF scheint ohne Kompression auszukommen, was die vergleichsweise riesige (und mehr als doppelte im Vergleich zu BMP) Dateigrösse erklärt.

Wie RTF genau Pixelbilder speichert, konnte ich der Dokumentation zum Format auf die schnelle nicht ganz entnehmen. Es scheint so, dass Pixelbilder im wesentlichen gleich codiert werden, unabhängig davon, in welchem Dateiformat das Originalbild vorliegt (das ist auch für den Austausch zwischen verschiedenen Programmen und über Betriebssystemgrenzen hinweg besser); demgemäss schwanken die Dateigrössen der RTFs mit eingebetten BMP, JPG und PNG nur gering und bewegen sich bei ca. dem Doppelten eines BMP-Bildes.
Warum ausgerechnet RTF mit eingebettetem WMF sich unverhältnismässig aufbläht, weiss ich auf die schnelle auch nicht zu sagen. Es scheint offenkundig, dass RTF ein WMF anders codiert als die anderen Formate. Und hier ist auch die eingangs von mir bereits erwähnte Verdoppelung zu erkennen: Von 7 auf 14 KB - wenn jedes Byte des Originals durch eine zwei-Byte-Kombination von Buchstaben ersetzt wird, dann ergibt diese diese ungefähre Verdoppelung.

Fazit, wie bereits oben bemerkt: Ausweichen wenn möglich auf die integrierten vektororientierten Funktionen der Textverarbeitung und hilfsweise auf ein Vektorformat, das auch aufgebläht wird, aber nicht so stark.

PS: Bei dieser Gelegenheit an Sven Leszmann die Frage: Wie weit ist inzwischen die Unterstützung für EMF oder SVG? Lässt sich dazu bereits etwas sagen? Div!

Hallo!
Ich bin sehr erfreut über das Engagement von Ihnen, mir hier zu einer Lösung zu verhelfen. Ich bin etwas weiter gekommen, habe aber nun neue Probleme, die ich in Word 2000 übrigens nicht hatte:

Da alle Logos bis auf eines letztlich Signets sind, also Schriftzeichen / Texte usw., habe ich mit den Format-Mitteln das bisherige Signet recht gut nachbilden können. Damit muss nur noch eine einzige Grafik eingebunden werden. Das führt im RTF zu ca. 300kB. Ich werde aber noch Versuche mit dem PNG-Format machen.

Das neue Problem entsteht daraus, dass ich in der Vorlage mehrere Tabellen und Textrahmen genau zueinander und auf dem gesamten Briefbogen positionieren muss.
Solange ich diese Konstruktion als *.tmv-Datei speichere, funktioniert alles einwandfrei. Speichere ich es mit "Datei speichern unter... als RTF, sieht es nur noch so lange gut aus, wie ich es nicht schließe und anschließend wieder öffne. Nach dem Öffnen des RTF sind Texte falsch formatiert (hoch- oder tiefgestellte Formatierungen sowie solche zur Laufweite und Glyphenbreite werden verworfen) und die Textrahmen und die Grafik sind an völlig falschen Plätzen positioniert. Auch wurden Unterlängen einer Schrift einfach abgeschnitten, weil im RTF-Format der Textrahmen eine zu geringe Höhe erhielt.
Kann es sein, dass RTF nicht in der Lage ist, mit exakt positionierten Text- oder Grafikrahmen umzugehen? Oder muss ich in den Textmaker-Vorlagen etwas anderes beachten als bei Word? Denn eine Mustervorlage mit Word im RTF-Format konnte ich mit solchen Rahmen und Tabellen Textrahmen durchaus zuverlässig gestalten.

Gerade erhielt ich auch von julitec die definitive Aussage, dass man beim RTF-Format für Vorlagen bleiben würde. Mein Aufwand wird sich also durchaus als funktionierende dauerhafte Lösung auszahlen. Aber ich mag nicht blind herum tasten, wenn ich hier durch hilfreiche Tipps viel schneller zum Ziel komme.

Besten dank im Voraus!

Nur mal kurz, bevor ich anderen Angelegenheiten nachgehen muss:

Ich empfehle, die fragliche RTF- und ggf. TMD-Datei, aus der sie erstellt wurde, an den support zu schicken.
Der Grund, warum ich dies empfehle ist der, dass RTF vergleichsweise selten nachgefragt wird und dass verhältnismässig wenig Fehler berichtet werden. Zudem ist die Dokumentation des RTF-Format durch Microsoft, na ja, sagen wir mal: 99%-ig. Somit kann es durchaus sein, dass Produkte von Microsoft RTF-Dateien geringfügig anders handhaben, als die Dokumentation es auszuweisen scheint.

An sich sollten Rahmen sich in RTF auch überlappen können, doch siehe oben. RTF ist ausserdem primär ein Text- und kein Graphik- oder Objektformat, manche Sachen betreffend Layout sind damit einfach nicht oder nur begrenzt möglich.

Zur Frage der unterschiedlichen Kopfzeilen:
Dazu müssen unterschiedliche Masterseiten angelegt werden. Diese können über Format/Kapitel/unterschiedliche erste Seite erzeugt werden. Nach dem Anlegen einer Kopf- oder Fusszeile (oder was sonst auf die Masterseite gehört) sollten Seiten 2 und 3 gelöscht werden können, ohne dass die Masterseiten verloren gehen. Wenn der Text von Seite 1 auf Seite 2 überfliesst, "lebt" Masterseite 2 dann wieder "auf", dito für 3.
Jedenfalls mit TMD/TMV oder DOC müsste das eigentlich funktionieren. Ob es bei RTF auch geht, weiss ich nicht. RTF ist ja eben ein Format für Dokumente, nicht für Vorlagen.
Wenn mit den unterschiedlichen Masterseiten gearbeitet wird, ist es auch nicht nötig, auf S. 1 ein Element so zu montieren, dass es Elemente, die auf den Folgeseiten erscheinen, gleichsam "zudeckt".

Das in aller Eile und ohne Gewähr für gänzliche Richtigkeit.

Hallo Panosis!
Während Sie antworteten, hatte ich meinen letzten Beitrag verändert, um neue Erkenntnisse einfließen zu lassen.

1.) Ich habe die Sache mit der Masterseite etc.verwirklichen können und sogar im RTF funktioniert dies einwandfrei! Wenn also das CRM einen langen Text einfließen lässt, sodass ein mehrseitiger Brief entsteht, wird die Sache funktionieren.

2.) Ein Layout mit überlappenden Rahmen, Grafiken etc.benötige ich jetzt nicht mehr. Der Fehler liegt aber offensichtlich woanders, weil auch die Positionierung einfach positionierter Rahmen / Grafiken im RTF verändert wird.

3.) Zudem habe ich auch das Problem, dass anscheinend alle Zusatz-Attribute der Zeichenformatierung verloren gehen, wie z.B. hochgestellt, tiefgestellt, Laufweite, Zeichenbreite usw. Gerade mit diesen Attributen ist mir aber der designgerechte Nachbau des Signet gelungen. Nur bekomme ich ihn nicht genau so ins RTF hinein.
Dies ist aber anscheinend die letzte Möglichkeit für mich, das Signet passend ins RTF zu bekommen, da Grafiken aufgrund des entstehenden Dateivolumens nicht in Frage kommen.

Jetzt scheint es, als sei ich soooo nah an der fertigen Lösung dran! Jetzt sollte es nicht an den Formatierungen und an dem Positionierungsproblem von Grafiken und Rahmen scheitern!

Leider erst später als geplant zurückgekehrt, deshalb in aller Kürze:
Trotz der Fortschritte möchte ich empfehlen, das (die) Dokument(e) an den Support zu schicken. Ich habe selbst eben gerade ein Problem mit RTF festgestellt, es kann aus den gestern erwähnten Gründen schon sein, dass da beim RTF-Filter noch nachgebessert werden kann.
Bei einer Suche in der RTF-Dokumentation ist mir auf den ersten Blick aufgefallen, dass Positionierungen meistens nur als halbe Punkte angegeben werden können. Womöglich gibt es auch bei der Definition und Berechnung der Punkte noch ein Problem (es gibt verschiedene Arten, die Grösse eines typographischen Punkts zu berechnen).

Summa summarum also wohl genügend Futter für den Support.