htmlText = "<p><span style='font-size:6px'>Guten</span> <span style='color: rgb(255, 102, 0);'><strong>Tag</strong></span></p>";
bodyText = (ArrayList< Element >)HTMLWorker.parseToList(new StringReader(htmlText), null);

bodyText enthält nun eine Liste mit einem Paragraph, der aus zwei Chunks besteht, die jeweils die gesetzten Eigenschaften (Schriftgröße, Farbe) besitzen. Die Elemente der Liste können nun z.B. einem ColumnText (hier textCol) hinzugefügt werden.

for (Element element : bodyText) {
 textCol.addElement(element);
}

Ein denkbarer Einsatzzweck wäre die Bearbeitung des PDF Inhalts vor dem Erzeugen des Dokuments im FCKEditor mit einem entsprechend auf einfache Textformatierungswerkzeuge begrenzten ToolbarSet.

Anmerkung zur Unterstützung der Textgröße (font-size): In der aktuellen iText Version 2.1.5 sorgt ein Bug dafür, dass die Schriftgröße auf 8px gesetzt wird, sobald die Eigenschaft “font-size” verwendet wird. Dieser Bug wurde mit Revision 3895 gefixt.

1) Tomcat sollte die URL (und damit u.a. GET-Parameter) als UTF-8 kodieren. Dies wird über das URIEncoding Attribut des Connector Elements in der server.xml eingestellt.

<connector connectionTimeout="20000"
 port="8080"
 protocol="HTTP/1.1"
 redirectPort="8443"
 URIEncoding="UTF-8"/>

2) Das richtige Encoding der Request (und damit unter anderem der POST Daten eines Forms) wird mit einem CharacterEncodingFilter in der web.xml sichergestellt. Dieser sollte als einer der ersten Filter eingerichtet werden (das filter-mapping Element des charsetFilter also im Deployment Descriptor vor den anderen Mappings stehen).

<filter>
 <filtername>charsetFilter</filtername>
 <filterclass>org.springframework.web.filter.CharacterEncodingFilter</filterclass>
 <initparam>
  <paramname>encoding</paramname>
  <paramvalue>UTF-8</paramvalue>
 </initparam>
 <initparam>
  <paramname>forceEncoding</paramname>
  <paramvalue>true</paramvalue>
 </initparam>
 
 <filtermapping>
  <filtername>charsetFilter</filtername>
  <urlpattern>/*</urlpattern>
 </filtermapping>
</filter>

3) Um schon von vornherein allen Beteiligten (z.B. dem Browser) die Möglichkeit zu geben, die richtige Kodierung zu benutzen, sollte in den ausgelieferten HTML Seiten das verwendete CharacterEncoding vermerkt sein. Dies geschieht in JSPs so:

< %@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

und endet in der HTML Seite so:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Damit sollte nun alles auf UTF-8 eingerichtet und auf UTF-8 gefasst sein, damit zum Beispiel Umlaute und sonstige Zeichen korrekt dargestellt und verarbeitet werden können.

@RequestMapping(value="bearbeiten.do", method = RequestMethod.GET)
...
@RequestMapping(value="bearbeiten.do", method = RequestMethod.POST)

In einer Klasse, von der mehrere Controller erben, können dann Methoden implementiert werden, die unter gleichem relativen Pfad aufgerufen werden sollen. Das finale Mapping wird dann zusammengesetzt aus dem @RequestMapping auf Typebene der erbenden Klassen und dem relativen Pfad im @RequestMapping der Methode. Das ist nicht wirklich überraschend, dennoch gerade hilfreich.

applicationContext.xml

<bean id="viewResolver"
 class="org.springframework.web.servlet.view.UrlBasedViewResolver"
 p:viewClass="org.springframework.web.servlet.view.tiles2.TilesView"
 p:order="2">
</bean>

Details zur Einrichtung von Tiles ist in der Spring Dokumentation zu finden (2.5, 3.0). Die zugehörige Tiles Konfigurationsdateien enthalten die Tiles Definitions, die zum Rendern aus den Controllern angesprochen werden können und beschreiben, wie die ausgelieferte Seite zusammengesetzt werden soll.

Um PDF Dokumente zur Laufzeit zu erzeugen und dem Benutzer anzubieten, wird ein zweiter ViewResolver benötigt. Ich habe dazu einen ResourceBundleViewResolver hinzugefügt, der die Datei views.properties nutzt, um die richtige Viewklasse zu einem Viewnamen zu finden.

applicationContext.xml

<bean id="viewResolverPDF"
 class="org.springframework.web.servlet.view.ResourceBundleViewResolver"
 p:basename="views"
 p:order="1">
</bean>

views.properties

AnschreibenPdf.class=de.springblog.projekt.view.pdfviews.AnschreibenPdf
AnlagePdf.class=de.springblog.projekt.view.pdfviews.AnlagePdf

Beide ViewResolver haben die Property order, die die Reihenfolge der Resolver festlegt. Zuerst wird geschaut, ob in der views.properties File ein Eintrag für den vom Controller zurückgegebenen Viewnamen passt (ResourceBundleViewResolver, order 1). Wenn keiner gefunden werden kann, wird versucht, den Viewnamen als Tiles Definition zu interpretieren (UrlBasedViewResolver, order 2).

Die in der views.properties genannten Klassen erweitern bzw. implementieren die abstrakte Klasse AbstractPdfView und vor allem deren abstrakte Methode buildPdfDocument, in der das PDF gebaut wird (mit Hilfe der iText Bibliothek).

Wird nun also für den zurückgegebenen Viewnamen (z.B. AnschreibenPdf) eine Viewklasse (entsprechend de.springblog.projekt.view.pdfviews.AnschreibenPdf) gefunden, wird die überschriebene Methode buildPdfDocument dieser Klasse aufgerufen und das PDF erzeugt.

Setzt man nun einen HTML Link auf eine PDF Datei, die auf eine Controller-Methode gemappt wird (zum Beispiel durch @RequestMapping) und gibt diese einen Viewnamen aus der views.properties zurück, so rendert die angegebene Klasse ein PDF und Spring liefert dieses an den Browser aus.