ODT-Dokumente per C++-Programm modifizieren?

06/08/2012 - 09:37 von Edzard Egberts | Report spam
Ich habe hier ein paar Messvorgànge mit C++ automatisiert und die
Ergebnisse müssen als Datenblatt, aber auch als "Zertifikat" (mit
Stempel und Siegel) dargestellt werden. Bisher wurden die von Hand in
bestehende, aufwàndig formatierte Word-Dokumente eingetragen und meine
Software soll das genau so "schön" hinkriegen.

Ganz früher konnte man per Programm in einem Dokument einfach
Platzhalter (z.B. $NAME) austauschen, zwischendurch habe ich jahrelang
nur noch HTML-Dateien geschrieben (die sind aber nicht "schön" und nur
eingeschrànkt druckbar) und zuletzt habe ich eine HTML-Datei als
Template benutzt, Diagramme als PNG-Grafik gespeichert und ins HTLM
eingefügt und abschließend mit HTML_to_PDF umgewandelt, was aber auf
unterschiedlichen Rechnern zu unterschiedlichen Ergebnissen führt.

Das ist echt Murks, deshalb möchte ich jetzt meine Werte und Grafiken
direkt in ein ODT-Dokument eintragen (dahin kann ich bestehende "doc"
oder andere Formate leicht konvertieren), weiß aber nicht wie. Macht man
das "per Hand", also Dokument entpacken, Platzhalter suchen und wieder
alles "einpacken", gibt es da Tools oder Bibliotheken? Muss ich
OpenOffice "fernsteuern"? Gibt es eine andere Lösung, mit der ich
vielleicht direkt ein PDF erzeugen kann?

Das Ganze soll auch noch unter Linux und Windows laufen, deshalb
Crossposting nach unix.programming mit Fup to ms-windows.programmer.
ODT ist ja sowieso systemunabhàngig und für dieses Problem müsste es
doch wirklich schon Lösungen geben?
 

Lesen sie die antworten

#1 Marcel Müller
06/08/2012 - 11:32 | Warnen spam
On 06.08.12 09.37, Edzard Egberts wrote:
Ich habe hier ein paar Messvorgànge mit C++ automatisiert und die
Ergebnisse müssen als Datenblatt, aber auch als "Zertifikat" (mit
Stempel und Siegel) dargestellt werden. Bisher wurden die von Hand in
bestehende, aufwàndig formatierte Word-Dokumente eingetragen und meine
Software soll das genau so "schön" hinkriegen.



Man kann OpenOffice automatisieren. Aber empfehlen würde ich das nicht.
Langfristig zuverlàssig ist jedenfalls etwas komplett anderes.

Ganz früher konnte man per Programm in einem Dokument einfach
Platzhalter (z.B. $NAME) austauschen,



Lang ist's her.

zwischendurch habe ich jahrelang
nur noch HTML-Dateien geschrieben (die sind aber nicht "schön" und nur
eingeschrànkt druckbar)



Jedenfalls nicht mit IE.

und zuletzt habe ich eine HTML-Datei als
Template benutzt, Diagramme als PNG-Grafik gespeichert und ins HTLM
eingefügt und abschließend mit HTML_to_PDF umgewandelt, was aber auf
unterschiedlichen Rechnern zu unterschiedlichen Ergebnissen führt.



PDF ist OK, aber bitte nativ. Also ein PDF-Formular aus dem Dokument
machen (Werkzeug nach Wahl) und dann nur die Formularfelder im PDF per
Software ausfüllen. PDF-Bibliotheken gibt es wie Sand am Meer. Formulare
können nicht alle, aber eine Seltenheit ist das nicht.

Für die Grafiken geht das mit den Formularen nicht. Man könnte aber mit
einer PDF-Bibliothek, die selbiges auf Objektebene abbildet, vorher
eingebrachte Dummybilder ersetzen. Die meisten PDF-Libraries können zwar
alle mögliche PDF-Objekte darunder auch Bilder erzeugen, allerdings
nicht unbedingt alle erdenklichen PDF-Dokumente und -Formate lesen und
als Objektbaum abbilden.

Das ist echt Murks, deshalb möchte ich jetzt meine Werte und Grafiken
direkt in ein ODT-Dokument eintragen (dahin kann ich bestehende "doc"
oder andere Formate leicht konvertieren), weiß aber nicht wie.



Ich glaube nicht, dass Du damit glücklich wirst.

Macht man
das "per Hand", also Dokument entpacken, Platzhalter suchen und wieder
alles "einpacken", gibt es da Tools oder Bibliotheken?



Ich würde nicht darauf wetten, dass die Dokumente keine Redundanz
enthalten. Also z.B. die Bildgröße oder auch Prüfsummen nochmal woanders
abspeichern oder sogar ein Preview-Image. Musst Du letztlich
ausprobieren. Und wenn es durch das Dokumentformat nicht explizit
vorgesehen ist, könnte die Freude von kurzer Dauer sein. Und selbst wenn
es vorgesehen ist, zàhlt es mglw. nicht zu den best-getestetsten
Features, die in jeder Version gleich gut funktionieren.

Muss ich OpenOffice "fernsteuern"?



Ja, das wàre der Weg. Geht auch mit MS-Office und .doc, aber wirklich
empfehlen kann ich es nicht. Ich habe damit noch nie wirklich gute
Erfahrungen gemacht.

Gibt es eine andere Lösung, mit der ich
vielleicht direkt ein PDF erzeugen kann?



Wenn du das gesamte Dokument from scratch mit Deinem Programm mit einer
PDF-Bibliothek aufbaust, wirst Du keine Probleme bekommen. Das kann so
ziemlich jede PDF-Writer Bibliothek. Nachteil ist, Du musst halt alles
programmatisch erzeugen, von der Überschrift bis zur Seitenzahl.

Das Ganze soll auch noch unter Linux und Windows laufen, deshalb



Jetzt wird es eng. Denn Du kannst nur noch Bibliotheken nutzen die unter
Linux und Win gleichermaßen und in der gleichen Version compilieren. Es
kommen also faktisch nur OpenSource-Lösungen in frage, die Du
sinvollerweise in einem passenden Versionsstand mit in den Source-Tree
Deines Programms aufnehmen kannst und darfst (kann bei GPL evtl. eng
werden). Da sollte sich etwas finden lassen, aber die Auswahl wird kleiner.

Eine plattformübergreifende Sprache, wie Java oder von mir aus auch
Mono/.NET würde diesen Punkt erheblich erleichtern. Portablen C++-Code
zu schreiben, ist ob der riesigen Lücken der Standardbibliothek in
Sachen I/O und Benutzerinteraktion eine andere Nummer. Außer bei
einfachen Kommandozeilentools làuft das fast immer auf eine zusàtzliche,
eigene oder adaptierte Laufzeitbibliothek hinaus. Und selbst die
einfachen Dinger brauchen meist ein halbes Dutzend #ifdef und doppelten
Testaufwand.

Crossposting nach unix.programming mit Fup to ms-windows.programmer.



Das hat wohl nicht geklappt, oder sehe ich das falsch? Es sind zwei
unterschiedliche Postings und die Antworten werden mutmaßlich nicht
zusammenfinden.

ODT ist ja sowieso systemunabhàngig und für dieses Problem müsste es
doch wirklich schon Lösungen geben?



Office-Automatisierung kannst Du platformübergreifend sowieso vergessen.
Die Funktionalitàt ist zwar da, aber zumindest die ganze Inter Process
Kommunikation darfst Du zweimal programmieren. Einmal für Linux (vmtl
CORBA) und einmal für Win (COM). Klar, auch dafür gibt es wieder
Abstraktions-Bibliotheken, aber mehr Komponenten = mehr fummeln und mehr
Risiko.

Kannst Du denn überhaupt sicherstellen, dass Du nicht mit stàndig
wechselnden OO-Programmversionen kompatibel sein musst? Ich meine, da
àndert sich auch mal was. Und der Work-Around um den Bug von Version
x.y.1 ist nicht unbedingt passend für x.y.2. Und der nàchste hat am Ende
noch LibreOffice. Was sich als Fork natürgemàß immer weiter von seinem
Bruder OO entfernt.


Marcel

Ähnliche fragen