Misverstanden over PDF/A – deel 2

Dit is deel twee van een bespreking van de meest voorkomende misverstanden over het gebruik van PDF/A. De volgende misverstanden komen aanbod:

• Alle documenten kunnen worden geconverteerd naar PDF/A
• Een stukje PDF/A is niet toegestaan

Alle documenten kunnen worden geconverteerd naar PDF/A

Nee. Er is behoefte aan documenten met een andere inhoud dan die is toegestaan door de ISO-standaard 19005-1, zoals video, audio en transparante aantekeningen. Niet ieder document heeft bovendien een afdrukbare weergave, zoals een MS Project bestand. Dergelijke documenten moeten nog worden gehandhaafd in een ander formaat – meestal hun oorspronkelijke bestandsformaat – omdat er gewoon nog geen geschikt standaard formaat is waarnaar het bestand kan worden geconverteerd.

De richtlijn is dus: alle documenten naar PDF/A converteren waar dit mogelijk én praktisch is. In toekomstige versies van PDF/A met een verbeterde functionaliteit is het wellicht wel mogelijk een aantal van deze bestandsformaten alsnog te converteren naar PDF/A. PDF/A is geen statische specificatie, maar wordt verder ontwikkeld om in reactie op nieuwe eisen van de markt. Een conversie variant is het vermelden waard: sommige gebruikers archiveren bepaalde documentsoorten in zowel PDF/A als in het oorspronkelijke bestandsformaat. Daarmee beschikken ze over de geldige visualisatie op het moment dat het document werd gemaakt, maar ook over de officiële versie met niet-zichtbare inhoud.

Een stukje PDF/A is niet toegestaan

Natuurlijk mag dit. PDF/A Validators kunnen alleen werken met binaire logica: een document “voldoet” of “voldoet niet” – er is geen “voldoet bijna”. Een gebruiker kan echter zelf bepalen in welke indeling zijn documenten moeten worden gehandhaafd, zolang hij de wettelijke eisen met betrekking tot inhoud en visuele identificatie maar respecteert. Een bron voor talrijke gesprekken is de eis in ISO 19005-1 voor het insluiten van lettertypen. Zonder deze lettertypen, zal een Validator een document identificeren als niet compliant met PDF/A. Dit leidt er uiteindelijk toe dat een auditor, de regulerende instantie of wie dan ook tot taak heeft de documenten te accepteren, de bestanden zal verwerpen, omdat de validatie-resultaten een rode X door de “conformiteit tonen”. En een revisor – zal heel begrijpelijk – de bestanden niet accepteren omdat hij niet weet of kan weten wat de oorzaak en gevolgen zijn. De revisor neemt de binaire logica “voldoet” of “voldoet niet” van de software over en verwerpt de bestanden. Tot zover de theorie. Nu de praktijk.

Stelt u zich eens twee organisaties voor die beide al hun documenten als PDF/A willen archiveren. De één is een adviesbureau dat jaarlijks ongeveer 25.000 Word-documenten maakt en deze bestanden in een elektronische klantdossier wil opslaan. Dit adviesbureau zal waarschijnlijk geen probleem hebben met het opnemen van een subset van twee font families in de documenten. Maar het tweede bedrijf, een grote verzekeringsmaatschappij, dat jaarlijks 50 miljoen documenten maakt (en dit is een realistisch aantal) zal daar wel degelijk een groot probleem mee hebben. Als u ervan uit gaat dat de twee subsets 50 KB geheugenruimte nodig hebben, dan zou deze verzekeraar de fonts 50 miljoen keer per jaar opslaan en alleen al daarvoor 50 miljoen x 50 KB = 2,5 TB schijfruimte nodig hebben. En de gedachte dat in tien jaar zo’n 25 TB schijfruimte nodig is voor hetzelfde lettertype is zo absurd, dat niemand een dergelijk voortel serieus neemt.

Nota Bene: Dit is zonder inbegrip van de documentgegevens zelf. Men kan stellen dat alleen de lettertypen slechts een klein deel van de volledige geheugenruimte bepalen en dat de relatie tussen lettertypen en documentgegevens in dat perspectief moet worden gezien. Echter vooral grote gebruikers genereren doorgaans extreem kleine printstreams in hun rekencentra (1403 of AFP) waarvoor slechts een paar KB per document nodig zijn. Op deze manier wordt er geen ruimte verspild aan visualisatie resources. Dergelijke objecten zijn altijd gekoppeld en niet ingesloten, of men drukt ze af met een basis 1403 line printer notatie met een zuinige “jaren ‘70 retro-look”. Er zijn een aantal concrete voorbeelden waar de geheugenruimte vereist voor de lettertypen tot 10 keer groter is dan de geheugenruimte die vereist is voor de documentinhoud.

Wat is in zulke situaties dan een praktische oplossing?

De verzekeraar kan besluiten om PDF/A te gebruiken maar dan zonder de ingesloten lettertypen. Hij gebruikt de basisvoorwaarden voor PDF/A en delegeert bijna de hele verantwoordelijkheid voor de lange termijn reproduceerbaarheid aan de ISO-standaard. De enige uitzondering betreft de lettertypen: dat hij regelt zelf onder eigen verantwoordelijkheid, net zoals hij dat – wettelijk bindend – deed in de tijd voordat de PDF/A werd ingevoerd. De verzekeraar zal kan bijvoorbeeld alle gebruikte lettertypen slechts één keer en niet in elk document ingesloten archiveren. Of hij kan alleen de essentiële lettertypen (bijvoorbeeld de niet-Latijnse lettertypen voor de lijsten of formules) insluiten. Wat hij doet, hij kan uitzonderingen maken op de zuivere leer, maar hij draagt zelf de verantwoordelijkheid voor de consequenties van deze uitzonderingen.

Wordt vervolgd.