Aus Webanwendung PDF, RTF, ... generien
Tobias Nissen
Ich muss in einer Webanwendung aus einem XHTML-Dokument ein PDF
generieren. Später kommt vielleicht nochmal Unterstützung für RTF oder
CSV dazu. (Der erste Satz stimmt nicht ganz, denn wenn es Vorteile
bietet, würde ich auch etwas anderes generieren, wenn es sich dann
leichter in PDF, RTF, whatever umwandeln lässt.)
Nun habe ich mich etwas schlau gemacht und bin bei diesen Möglichkeiten
gelandet:
* mit XSLT XSL-FO erzeugen und daraus dann PDF
* mit einem der PDF-Module ein PDF direkt im Programm erzeugen
(und das gleiche dann für RTF, ...)
Beide Alternativen gefallen mir (auf den ersten Blick) nicht. Wenn ich
etwa Apache FOP nehme, dann kann ich daraus anscheinend recht gut PDF
generieren. Bei RTF sieht die Sache aber vollkommen anders aus. Meine
Dokumente bestehen aus riesigen Tabellen, bei denen Feintuning angesagt
ist, damit es auf der Seite gut aussieht. Meine Befürchtung ist (nach
Lektüre von [0]), dass ich zur Generierung von RTF FOP nicht verwenden
kann. Das wäre extrem ärgerlich, da das Erstellen eines passenden
XSL-Stylesheets äußerst aufwändig ist.
Wenn ich die PDF-Dokumente direkt erzeuge, dann ist es einfach
unelegant. Bisher ist es nur eine Ansicht, die nach PDF exportiert
werden soll. Wenn nun andere folgen, muss ich jedesmal einen neuen
Haufen Code anlegen. Dazu kommt, dass man Tabellen gar nicht so direkt
erzeugen kann, wenn ich das richtig sehe. Ich muss die mir also mit
Kästchen und milimetergenauen Abständen selbst bauen... So genau habe
ich mich aber damit noch nicht beschäftigt, vielleicht ist es ja doch
gar nicht so schlimm.
Nun habe ich ja bereits ein CSS-Stylesheet, welches die Seiten zum
Drucken schön aufbereitet. Recht wäre mir natürlich etwas, was genau
diese Ausgabe in PDF hinbekommt. Gibt es da was? Und in Anbetracht
dessen, dass vielleicht noch andere Ausgabeformate dazukommen, ist der
Ansatz überhaupt empfehlenswert?
Sollte ich vielleicht auf ein Zwischenformat wie DocBook umsteigen?
Damit kann ich zumindest alle Formate erzeugen und das scheint ja auch
gut zu funktionieren. Kann da jemand etwas zu sagen? Und wie sieht es
dann mit der Perl-Integration aus? Es wäre mir schon lieb, wenn alles
aus einem Guss wäre und ich nicht nur von Perl als Glue-Language
gebrauch mache.
Fragen über Fragen...
Schöne Grüße!
Tobias
Christian Kirsch
> Moin!
>
> Ich muss in einer Webanwendung aus einem XHTML-Dokument ein PDF
> CSV dazu. (Der erste Satz stimmt nicht ganz, denn wenn es Vorteile
> leichter in PDF, RTF, whatever umwandeln lï¿œsst.)
>
> Nun habe ich mich etwas schlau gemacht und bin bei diesen Mï¿œglichkeiten
> gelandet:
>
> * mit XSLT XSL-FO erzeugen und daraus dann PDF
> * mit einem der PDF-Module ein PDF direkt im Programm erzeugen
>
Warum brauchst Du denn mehrere Formate? PDF ist doch fï¿œr das Anzeigen
wunderbar? RTF ... wenn der Empfï¿œnger die Daten nochmal bearbeiten soll,
CSV dito (abgesehen davon, dass CSV fï¿œr mehr als Tabellen ï¿œberhaupt
nicht geeignet ist, anders als PDF und RTF).
> Wenn ich die PDF-Dokumente direkt erzeuge, dann ist es einfach
> unelegant. Bisher ist es nur eine Ansicht, die nach PDF exportiert
> werden soll. Wenn nun andere folgen, muss ich jedesmal einen neuen
> Haufen Code anlegen. Dazu kommt, dass man Tabellen gar nicht so direkt
> erzeugen kann, wenn ich das richtig sehe. Ich muss die mir also mit
> Kï¿œstchen und milimetergenauen Abstï¿œnden selbst bauen... So genau habe
> ich mich aber damit noch nicht beschï¿œftigt, vielleicht ist es ja doch
> gar nicht so schlimm.
>
PDF ist als PS-Abkï¿œmmling eine stackorientierte
Seitenbeschreibungssprache. Und ja - es ist so schlimm. Du kannst Dir
natï¿œrlich in Perl ein Modul bauen, mit dem Du Tabellen leichter
erstellen kannst. Du kannst vermutlich auch PDF-Funktionen im Header
jedes Dokuments erzeugen, die dasselbe tun. YMMV.
Aber es fï¿œhrt kein Weg drum herum, "millimetergenaue Abstï¿œnde" etc. zu
ermitteln.
Wie sollte das auch sonst gehen? PDF ist fï¿œr die Druckausgabe entwickelt
worden, und da kommt es halt auf sowas an. Anders als bei HTML... Du
wirst Dich damit beschï¿œftigen mï¿œssen, ob die Tabelle aufs Papier passt,
das ist ein wenig anders als im Browser, wo man ja scrollen kann ...
> Nun habe ich ja bereits ein CSS-Stylesheet, welches die Seiten zum
> Drucken schï¿œn aufbereitet. Recht wï¿œre mir natï¿œrlich etwas, was genau
> diese Ausgabe in PDF hinbekommt.
Ja, dann nimm doch dieses Stylesheet auch fï¿œr den Medientyp "print" und
ï¿œberlass es dem Betrachter Deiner Webseite, das Dokument zu drucken.
Warum muss das unbedingt PDF sein? Abgesehen davon kï¿œnnen manche
Plattformen auch aus einer Webseite PDF erzeugen, notabene Mac OS X.
> Gibt es da was? Und in Anbetracht
> dessen, dass vielleicht noch andere Ausgabeformate dazukommen, ist der
> Ansatz ï¿œberhaupt empfehlenswert?
>
> Sollte ich vielleicht auf ein Zwischenformat wie DocBook umsteigen?
Weil DokBook-XML irgendwie ... anderes XML ist als XHTML?
> Damit kann ich zumindest alle Formate erzeugen und das scheint ja auch
"Mit" DocBook als solchem erzeugst Du doch erstmal gar keine Formate.
Auch da brauchst Du irgendwelche XSL-Programme, die PDF, RTF, whatnot
draus machen. Was also soll das bringen?
Mein letzter Blick auf DocBook (vor einigen Jahren!) war jedenfalls
ernï¿œchternd. Abgesehen davon ist das im Zusammenhang mit der Ausgabe von
simplen Tabellen wohl eher eine Atombombe, die Du auf einen Spatzen wirfst.
Tobias Nissen
> Tobias Nissen schrieb:
[HTML, PDF, RTF, CSV, ...]
> Warum brauchst Du denn mehrere Formate?
Weil ...
> PDF ist doch für das Anzeigen
> wunderbar? RTF ... wenn der Empfänger die Daten nochmal bearbeiten
> soll, CSV dito (abgesehen davon, dass CSV für mehr als Tabellen
> überhaupt nicht geeignet ist, anders als PDF und RTF).
... OK, Du gibst die Antwort schon selbst.
>> Nun habe ich ja bereits ein CSS-Stylesheet, welches die Seiten zum
>> Drucken schön aufbereitet. Recht wäre mir natürlich etwas, was genau
>> diese Ausgabe in PDF hinbekommt.
>
> Ja, dann nimm doch dieses Stylesheet auch für den Medientyp "print"
> und überlass es dem Betrachter Deiner Webseite, das Dokument zu
> drucken.
Genauso läuft es auch bisher.
> Warum muss das unbedingt PDF sein?
Keine Ahnung, möchte der Auftraggeber. PDF-Export finde ich nun aber
nicht soo ungewöhnlich...
[...]
>> Gibt es da was? Und in Anbetracht
>> dessen, dass vielleicht noch andere Ausgabeformate dazukommen, ist
>> der Ansatz überhaupt empfehlenswert?
>>
>> Sollte ich vielleicht auf ein Zwischenformat wie DocBook umsteigen?
>
> Weil DokBook-XML irgendwie ... anderes XML ist als XHTML?
Naja, nun hat man bei DocBook allerdings halbwegs brauchbare
XSLT-Stylesheets und muss nicht bei Null anfangen. Ansonsten habe ich
im Netz ganz genau /eine/ andere Resource für XSL-FO Stylesheets
gefunden und die waren dann mit FOP nicht kompatibel. Und welchen
freien XSL-FO-Prozessor gibt's noch, der nicht noch im alpha-Stadium
ist? Keinen. Nur proprietären Krams, der einem Wasserzeichen aufs PDF
macht. Das war mir dann auch schon wieder fast zu viel :-)
>> Damit kann ich zumindest alle Formate erzeugen und das scheint ja
>> auch
>
> "Mit" DocBook als solchem erzeugst Du doch erstmal gar keine Formate.
> Auch da brauchst Du irgendwelche XSL-Programme, die PDF, RTF, whatnot
> draus machen. Was also soll das bringen?
Jaja, soweit war ich eben noch nicht.
> Mein letzter Blick auf DocBook (vor einigen Jahren!) war jedenfalls
> ernüchternd. Abgesehen davon ist das im Zusammenhang mit der Ausgabe
> von simplen Tabellen wohl eher eine Atombombe, die Du auf einen
> Spatzen wirfst.
Ich habe den heutigen Tag damit verbracht, die Alternativen zu
evaluieren. U.a. habe ich mit DocBook herumgespielt und festgestellt,
dass das absolut nix für mich ist. Der Vergleich mit der Atombombe
passt sehr gut, finde ich.
Ich mache es nun folgendermaßen. Ich mache mir ein RTF-Template (schön,
in jedem Wordprocessor editierbar, Kunde kann's zur Not auch) und füge
da von Hand ein paar Marker ein, an denen ich dann mit Perl ein paar
Veränderungen vornehme. Das generieren von RTF ist damit ein
Kinderspiel, so kompliziert ist RTF ja nicht.
Ich war zunächst etwas skeptisch, was das Umwandeln in PDF angeht. Aber
dank unoconv[0] (installiert zwar viel von OpenOffice, benötigt aber
dennoch kein X!) kriege ich eine exakte Umwandlung nach PDF hin. Oh,
und alle anderen Formate, in die Openoffice exportieren kann, kriege
ich damit auch geschenkt :-)
Tobias Nissen
[unoconv]
> installiert zwar viel von OpenOffice, benötigt
> aber dennoch kein X!
Die Aussage stimmt wohl nicht so ganz, wie ich gerade feststelle.
Christian Kirsch
> Tobias Nissen wrote:
> [unoconv]
>> installiert zwar viel von OpenOffice, benï¿œtigt
>> aber dennoch kein X!
>
> Die Aussage stimmt wohl nicht so ganz, wie ich gerade feststelle.
Vielleicht wï¿œre dann der Weg ï¿œber (La)TeX hilfreich(er)? Aus dem
DVI-Zwischenformat sollte sich ja auch alles mï¿œgliche erzeugen lassen.
Tobias Nissen
> Tobias Nissen schrieb:
>> Tobias Nissen wrote:
>> [unoconv]
>>> aber dennoch kein X!
>>
>> Die Aussage stimmt wohl nicht so ganz, wie ich gerade feststelle.
>
> DVI-Zwischenformat sollte sich ja auch alles mögliche erzeugen lassen.
Ich wollte nicht nochmal auf mich selbst antworten, aber nun kann ich
meine Erkenntnisse hier ja nochmal loswerden :-)
Also so ganz rock-solid ist unoconv gewiss nicht. Die Fehlermeldungen
sind ein Witz, es gibt hin und wieder mal Segmentation Faults, aber die
Konvertierung klappt, wenn's denn erstmal läuft, ganz gut. Man muss
offensichtlich allen möglich OpenOffice-Kram installieren (nicht bloß
das, was unoconv unter Debian an Abhängigkeiten hat, sondern
offensichtlich auch openoffice.org-writer, openoffice.org-headles und
so, vgl. [0].
Einen X-Server braucht es aber ab 2.4 oder so wohl nicht mehr. Ich habe
schon erst gedacht, ich müsste auf dem Server mit Xvfb oder so
arbeiten. Das ist heutzutage aber wohl nicht mehr nötig, wie ich dann
in unoconv's README las.
Das Konvertieren funktioniert nun gut und sogar schnell. Bei
Gelegenheit gucke ich mal, ob ich dafür theoretisch OpenOffice::UNO
nutzen kann, dann wird's auch wieder OnT. Man kann, um die Startzeit
von OOo zu minimieren, auch die ganze Zeit eine Instanz laufen lassen,
die die Auftrage von unoconv dann bearbeitet.
Den Weg über LaTeX wollte ich auch zunächst einschlagen. Letztlich bin
ich mit der jetzigen Lösung aber zufriedener, da das Aussehen der
Dokumente wirklich eins zu eins (von Format zu Format) stimmt. Das
dürfte bei LaTeX->RTF schwierig bis unmöglich sein. Und als günstigen
Nebeneffekt gibt's DOC und ODT dazu, auch nett.
Peter J. Holzer
> Vielleicht w�re dann der Weg �ber (La)TeX hilfreich(er)? Aus dem
> DVI-Zwischenformat sollte sich ja auch alles m�gliche erzeugen lassen.
DVI ist nur dann "device independent", wenn Du als nur Drucker mit einer
bestimmten Papiergr��e betrachtest.
hp