Das war mal wieder eines dieser Probleme, bei denen man stundenlang nach einer Lösung sucht und die unwahrscheinlichste es dann tut.
Vorgeschichte
Im Rahmen der Umstellung von Amyuni PDF Converter zu SWING PDF Converter bat eine Kundin um Unterstützung. Wir hatten ihre Notes-Anwendung aufgrund gestiegener Datenströme so angepasst, dass deutlich größere Datenmengen schneller bearbeitet und flexibler gedruckt werden können. Bestandteil dieser Lösung war, dass ein Teil der Daten mittels PassThru-HTML (Durchgangs-HTML) in der Druckansicht dargestellt wurde, um in der Gestaltung weniger an Notesbeschränkungen gebunden zu sein. Dabei funktionierte der Ausdruck sowohl im Notes-Client als auch im Amyuni-PDF-Ausdruck zuverlässig. Da Amyuni jedoch andere Schwachstellen hatte, sah sich die Kundin nach Alternativen um und testete SWING PDF.
Proof of Concept
In der Einführungsphase stellte sie jedoch fest, dass SWING PDF leider (neben seinen Vorteilen) den Nachteil hat, dass er kein PassThru-HTML drucken mag. Es wurde nicht einmal die HTML-Tabellen-Struktur berücksichtigt, sondern einfach nur der HTML-Baum gedruckt. Um nun möglichst effizient einerseits die bereits existenten HTML-Bestandteile des Ausdrucks möglichst weiterverwenden zu können, andererseits nicht die gewonnenen Darstellungsvorteile durch die Rückkehr zu Notes-Standard-Verfahren zu verlieren, kam die Idee auf, statt des PassThru-HTML MIME-Rich-Text-Felder zur Darstellung des HTML-Anteils zu verwenden. Schließlich kann SWING ja auch empfangene Mails PDF-drucken, welche MIME-Inhalte besitzen. In Absprache mit der Kundin entwickelten wir zunächst einen Proof of Concept in einer separaten Datenbank, damit wir anhand eines ihrer Beispiele prüfen konnten, wie der neue PDF-Drucker mit dieser Art von Daten klarkommt. In der Testphase stellte sich heraus, dass er in dieser Hinsicht recht robust ist und je nach Feld- und Maskeneinstellungen oft gute Ergebnisse liefert. Es mussten nicht einmal die HTML- und MIME-spezifischen Häkchen gesetzt werden (siehe Bilder)
Umsetzung in Kundendatenbank
Die Übertragung auf die konkrete Notes-Anwendung konnte also starten und sollte im Wesentlichen Fleißarbeit sein. Danach sah es dann auch lange Zeit aus. Die NotesMIMEEntity-Klasse sorgte auf Basis einer schon länger genutzten Funktion unseres LotusScript-Frameworks für eine weitgehend ereignisarme Umsetzung. Spannend - in Hinblick auf später - war allenfalls, dass in einigen der Ausdrucksmasken der Kundin zwei verschiedene Rich-Text-Felder zur Darstellung unterschiedlicher Tabellen gefüllt werden wollten statt nur einer. Und so wartete ich nach getaner Arbeit wieder auf das Feedback der Kundin, da ich selbst keine SWING-Installation vorliegen hatte.
SWING PDF ignoriert das Styling
Dieses Feedback war allerdings unerwartet: Der HTML-Anteil wird korrekt interpretiert und in der gewünschten Tabellenform dargestellt. Lediglich das Styling mittels CSS schaffte es auf scheinbar unerklärliche Weise nicht mehr in den Ausdruck. Und so begann die Fehlersuche: Sind die Feldeinstellungen genau so wie im Proof of Concept? Habe ich bei den Maskeneinstellungen etwas übersehen? Sollten wir testweise das Styling anders implementieren als bisher? Alles sah soweit so richtig aus. Daher probierten wir weitere Einstellungen durch, aber auch diese Änderungen konnten das Styling nicht zum Vorschein bringen, obwohl der PDF-Drucker vorher doch so robust wirkte.
Die Lösung
Da die Problemklärung der Kundin mit SWING nicht sofort neue Erkenntnisse brachte, starteten wir eine gemeinsame Lösungssuche, denn manchmal sehen vier Augen mehr als zwei. Wieder gingen wir die Feld- und Maskeneinstellungen durch. Der einzige Unterschied zum Proof of Concept schien der Feldname zu sein. Einmal war es "Body", einmal je nach Ausdrucksversion "TabelleX" und/oder "TabelleY". Da alle anderen Versuche nicht fruchteten, passten wir eines der Felder und den Programmcode so an, dass "Body" statt "TabelleX" beschrieben wird. Ohne besondere Hoffnung starteten wir den weiteren Testlauf und siehe da: Die Tabelle war wunderbar gestylt!
Nachbetrachtung
In der konkreten Situation ist die Umbenennung leider nicht der Königsweg, da nach der bisherigen Programmierung teilweise zwei Tabellen benötigt werden. Zwar könnte man beide zusammenfassen und dann in ein "Body"-Feld schreiben, doch bevor dies weiteren Aufwand versursacht, bleibt die Hoffnung, dass SWING sein Produkt in puncto Feldnamen verbessert. Das Ergebnis steht derzeit noch auch.
