“In plaats van een bericht in de HTML in de browser, wil ik het bericht als opgemaakt PDF-bestand beschikbaar kunnen stellen”.
Heel simpel gezegd eigenlijk. En op een desktop nog redelijk simpel te doen ook. Ook ik heb (een niet gratis, maar wel netjes gekochte) virtuele printerdriver geïnstalleerd staan die alles wat ik kan printen ook in PDF kan ophoesten.
Toch blijkt dat in PHP en met Nucleus (al heeft dat tweede er waarschijnlijk niets mee te maken) nog een stuk moeilijker dan ik dacht.
Zoeken
Zoeken op het Nucleus-supportforum levert een link op naar een plugin van Radek Hulán (ja, die van BLOG:CMS). Maar die link werkt niet meer sinds (blijkbaar) de omstandigheden die geleid hebben tot het afsplitsen van BLOG:CMS.
Iemand anders had er wel een kopie van en heeft die online gezet. Die kopie bevat echter wat foutjes en het duurde daarom geruime tijd voordat ik ook maar wat eerste teksten op mijn beeldscherm kreeg.
Probleem
Probleem met de code was echter dat de opmaak van de pagina volledig in de code vastgelegd was (ik wilde uiteraard veel liever skins en templates gebruiken) én het was alleen bruikbaar voor individuele berichten.
Ik wilde graag ook in staat zijn om bijvoorbeeld alle berichten van één maand of alle berichten van een dag etc. naar PDF te converteren.
Terwijl ik de code begon om te bouwen, kwam ik er achter dat deze code gebruikt maakt van FPDF een gratis class in PHP voor het maken van PDF-documenten. Daar bovenop had Radek code gebouwd die leek op de bij HTML2FPDF eschikbaar gestelde code. Uiteindelijk heb ik ook de code van Radek (die overigens niet onder de GPL-licentie was vrijgegeven en waarvan niet helemaal duidelijk was of die met Nucleus samen gebruikt mocht worden) in zijn geheel vervangen door wat HTML2FPDF deed en een eigen plugin voor Nucleus die het gebruik van het interne skins-systeem mogelijk maakt.
Eerste resultaten
Toch werkt het nog niet allemaal zoals ik wil. Ik heb nog problemen met het ‘goed’ krijgen van de opmaak. Ik was inmiddels gewend om dat met div-elementen en externe css-bestanden te doen, maar dat lijkt niet altijd het gewenste effect te hebben. Een ander probleem is dat de uitlijning aan de linkerkant niet altijd lekker werkt.
Ook het gebruik van afbeeldingen in combinatie met div-elementen voor de plaatsing, werkt niet helemaal zoals het zou moeten.
Er zal dus nog het nodige getweaked moeten worden aan de PDF-coversiekant.
Ik heb de links onder aan de berichten (bij de detailpagina) en onder aan de pagina’s met overzichten (per dag en per maand) voor het tonen (eigenlijk: genereren) van de PDF-versie voorlopig toch maar alvast actief gemaakt. Als de opmaakproblemen blijven, verdwijnen ze weer en op momenten dat ik er mee aan het testen ben kunnen er soms foutmeldingen getoond worden in plaats van PDF-bestanden.
Mmm… Nice, well done!
Op mijn Mac kan ik altijd al standaard printen naar PDF en met TeX maakte ik al voor 1995 PDF’s van al mijn essays, verlagen, etc. Ik kan al jaren niet zonder. PDF is gewoon heel goed digitaal papier.
Ik had van het W3C begrepen dat XML naar FO kan worden omgezet en dat W3C een FO naar PDF programma beschikbaar hebben. Ik heb wel eens websites gezien waarbij als de link eindigde op ".html" je de html kreeg en bij ".pdf" de pdf, gemaakt de eerste keer on-demand en daarna cached.
Helaas wordt nog vaak (ook hier) geheel overbodig een nieuwe window geopend als je een PDF link kiest. PDF download ik altijd want ik lees het liever in Preview waar ik tenminste snelheid en fatsoenlijke controls heb. Bovendien lees ik ze vaak offline en niet online. Dit betekend dat ik dus ongevraagd een leeg window voor me neus krijg zodra ik een PDF link kiest. Klein min puntje.
Hoi Gideon,
Voor Windows op de desktop heeft het (vind ik) inderdaad relatief lang geduurd voordat er écht concurrentie voor Adobe kwam wat betreft het maken van PDF-bestanden. Ook Linux heeft standaard wel de een of andere tool aan boord om die conversie te doen.
Wat FO betreft: Ik heb een tijdlang met Docbook gespeeld. Het mooie van Docbook is dat er een groot aantal XSLT-stylesheets voorhanden is om conversies uit te voeren. Eentje daarvan converteert naar FO, dat je dan weer, met FOP bijvoorbeeld, naar PDF.
Nadeel is dat het (op windows zeker) een aantal stappen vergt, verschillende tools en niet zomaar iets wat je achter een webpagina hangt. Ook van Apache komt Cocoon. Dat is een engine die daar juist wel voor geschikt is en wellicht ook achter die pagina’s die jij gezien hebt hangt.
Belangrijk verschil tussen dat en wat ik hier doe is dat daarnaast mijn berichten niet uit nette XML bestaan. En je ziet ook in de code van de parsers dat er véél checks voor mallformed HTML in voor komen. Daar waar een XML-parser in het algemeen meteen afhaakt en een error produceert.
Het openen in een nieuw venster is op dit moment optioneel, ik kan het vinkje in de plugin omzetten en dan opent hij netjes in het huidige scherm.
Cachen doet hij de PDF’s ook. Het is nog een redelijk rudimentaire (op zichzelf staande) cache die de PDF opslaat en pas 60 minuten later opnieuw aanmaakt. Als ik het bericht wijzig binnen die 60 minuten en iemand had de PDF al laten genereren, dan komt de wijziging dus niet in de PDF voor. Volgende stap is om deze functionaliteit te integreren met de cache-functie voor de pagina’s zelf. Dan ‘weet’ je namelijk wanneer de de PDF’s moet verwijderen.