Solid teknik inbäddad i intuitiva programvaror

callas software, som utvecklar preflight-tekniken som används i Adobe® Acrobat®,
erbjuder en rad egna skrivbords- och serverprogramvaror som gör det möjligt för
användare att antingen interaktivt eller automatiskt bearbeta PDF-filer.

Produktfamiljen callas pdfToolbox riktar sig till tryck- och publiceringsmarknaden,
medans produktfamiljen callas pdfaPilot riktar sig till alla som behöver tillförlitlig
långtidsförvaring och e-arkivering av PDF-baserade digitala dokument
för en mängd olika branscher.

callas pdfToolbox har revolutionerat sättet att hantera PDF-filer för utskrift/tryck.
Istället för att behöva leta efter fel, gräva igenom rapporter och redigera
enskilda objekt, åtgärdar pdfToolbox snabbt filer för den produktionsprocess
de är avsedda för och använder sig av ledande visualiseringsteknik för att
markera eventuella kvarvarande potentiella problem.

Samma filosofi har callas software implementerat
för dokumentarkivering med callas pdfaPilot.

Fånga problemen tidigt - Preflight för en problemfri produktion

Med dessa kontroller kan man upptäcka de viktigaste problemen i PDF-dokument,
hur man rapporterar dem och hur man rättar till vanliga problem:

• 0. Introduktion till preflight


• 1a. Preflight av PDF-filer


• 1b. Rapportering av identifierade preflight-fel - Preflight-rapporter


• 1c. Visuell inspektion av PDF-filer


• 1d. Arbeta med färg i pdfToolbox

Preflight - Vad är det?

Preflight (teknisk kvalitetskontroll) är processen att kontrollera om
dokument är lämpliga för den avsedda användningen.

Preflight

• är inte begränsat till tryckt material


• är olika för olika arbetsflöden

När bör man utföra preflight?

• i alla viktiga processteg i arbetsflödet,


• vid stora förändringar av arbetsflödet,


• så många gånger som möjligt, och där det är meningsfullt


• Rekommenderade tillfällen för preflight:
• när man skapar nya dokument


• efter generering/export till PDF


• vid arbetsflödesförändringar:
  • om man tar emot externa filer
  
  
  • innan man sänder filer till annat arbetsflöde

Preflight-standarder och -profiler

• en standard eller specifikation definierar vad en PDF bör och inte bör göra


• en preflight-profil implementerar en sådan standard i
  programvara för att rapportera om:
• information: saker du vill känna till


• varningar: saker som kan utgöra ett problem


• fel: saker som definitivt kommer att utgöra ett problem

Detektera vs åtgärda (fixa)

• Programvaruverktyg
  (såsom callas pdfToolbox, callas pdfaPilot eller Adobe Preflight)
  kan ofta:
• upptäcka problem (preflight), och


• åtgärda (fixa) problem


• Varför åtgärda?
• ofta snabbare att åtgärda


• den som gjorde filen kanske inte vet hur man åtgärdar problemet


• Vad skall åtgärdas?
• saker som bör åtgärdas


• saker som det är säkert att åtgärda


• saker där följdverkan av åtgärden är känd och hanterbar


• vissa saker kan inte åtgärdas (t.ex. för låg bildupplösning)


• vissa saker bör inte åtgärdas automatiskt,
  utan att problemet har undersökts noggrannare

Använd befintliga standarder och profiler för preflight

Preflight av PDF-filer utföres för att kontrollera PDF-dokument
med avseende på om de är lämpliga för användning för
tryck, publicering, långtidsarkivering eller för annat syfte.

Med callas software preflight-teknik medger både manuell
och/eller helautomatisk kvalitetskontroll.

Som ett bevis på kvaliteten och tillförlitligheten hos callas softwares
preflight-motor kan nämnas att den är licensierad av Adobe och
används i Adobe Acrobat preflight-plug-in.
Läs mer här nedan om hur du kan utföra preflight på
dina PDF-dokument på olika sätt.

Det hela börjar med en profil

Hörnstenen i all kvalitetskontroll som görs med en programvara
från callas software är en "preflight-profil".

En profil är en samling av de kontroller som du vill göra på ett
PDF-dokument och (eventuellt) de problem du vill åtgärda med en preflight.

För att kunna utföra preflight på dina PDF-dokument måste du antingen
välja en fördefinierad preflight-profil (en av de som ingår i programvaran)
eller skapa din egen profil.

De fördefinierade profiler som tillhandahålls av
callas software ingår i följande kategorier:

• Profiler enligt PDF-standarder såsom PDF/X, PDF/A, PDF/VT och fler.


• Profiler som utför PDF-specifikationer från branschorganisationer
  såsom Ghent Workgroup och PDF/X-Ready.


• Andra exempel och demo profiler.

Figur 1: pdfToolbox profil-fönster visar ISO-standardprofiler

Manuell preflight

PDF-dokument kan inspekteras manuellt med
pdfToolbox Desktop eller pdfaPilot Desktop.

Båda programvarorna fungerar antingen som en plugin till
Adobe Acrobat eller som fristående tillämpningar.

Preflight av dokument är lätt att utföra:
öppna PDF-filen som du vill kontrollera,
välja rätt preflight-profil i "Profile / Profiler"-fönstret och
tryck därefter på någon av knapparna
"Analyze / Analysera" eller "Analyze and fix / Analysera och åtgärda".

Figur 2: Preflight-resultat för en utförd PDF/X-1a profil

Efter en utförd manuell preflight dyker "Resultat"-fönstret upp och
visar en lista med information, varningar och fel.

Användning av bevakade mappar (hot folders) till preflight

I många arbetsflöden är det mer effektivt att anordna automatiserad preflight;
i stället för att öppna varje PDF-fil individuellt, används en bevakad mapp (hot folder).
Alla PDF-dokument som lagras i den mappen plockas automatiskt upp för preflight.
Resultaten flyttas till fördefinierade mappar.

Figur 3: En bevakad installationsmapp används i
pdfToolbox Server för att skapa PDF/X-4-filer

Varje skapat jobb definierar en indatamapp
(den bevakade mappen där PDF-filer plockas upp från)
och utdatamappar för filer utan fel, filer med fel,
filer med varningar och så vidare.
Den preflight-profil som valts i jobbet definierar vilka kontroller och
åtgärder ("fixar") som kommer att utföras på de bearbetade filerna.

Integrerad preflight

Oftast är det mest effektiva sättet att göra preflight av PDF-filer
att göra det som en integrerad del i en större lösning,
såsom en leveransportal eller web-to-print-lösning.
callas software erbjuder både en kommandoradslösning och
en verklig SDK för att stödja detta.

• Kommandoradsintegration

pdfToolbox CLI och pdfaPilot CLI

är kommandoradstillämpningar som kan startas från
en terminal eller kommandofönstret, men typiskt startas
de från tillämpningen eller skriptet de är integrerade med.

Dessa versioner av callas software tillämpningar stöder alla
preflight-möjligheter och kan automatiskt generera detaljerade
rapporter (i PDF eller XML) för närmare integration.




• Användning av SDK

pdfToolbox SDK och pdfaPilot SDK

är lösningar som ger integration på en biblioteksnivå.

SDK innehåller de nödvändiga biblioteken, rubriker, dokumentation och exempel
för att nära integrera preflight i en egen C, C ++, Java eller NET-miljö.

Integrering av preflight genom användning av SDK kräver utvecklingsresurser,
men ger den närmaste integreringen med egna tillämpningar i slutändan.

Syftet med preflight eller teknisk kvalitetskontroll är att ta
reda på om ett PDF-dokument är lämplig för utskrift eller arkivering
(eller något annat ändamål).

För detta görs en preflight av PDF-dokumentet med en specifik
preflight-profil och en efterföljande granskning av slutresultatet.

erbjuder en rad av alternativ för att visa resultaten som preflight-rapporter;
där de olika typerna av rapporter typiskt används för olika ändamål.

Klassiska PDF-rapporter
Kommenterad rapport, transparensmaskrapport, och lagerrapport.

Tre former av PDF-rapporter visar preflight-resulten i en fast layout;
de använder olika tekniker för att tydliggöra vilka objekt som orsakade
särskilda fel eller varningar.

Rapporterna är vanliga PDF-dokument som kan öppnas i alla PDF-läsare
(t.ex. Adobe Acrobat eller Apple Preview).
Det gör denna typ av rapporter är idealiska för att skicka till slutkunder
för att förklara för dem vilka fel de måste rätta till.

Översikt

Var och en av dessa rapporter kan eventuellt inledas med en översiktsida;
denna sida sammanfattar information om det kontrollerade ("preflighted") dokumentet,
den miljö där det kontrollerades och innehåller även en lista över fel och varningar.

Figur 1: Översiktsida för en preflight-rapport

Kommenterad rapport

Denna typ av rapport använder kommentarer (även kallade anteckningar)
för att markera de objekt som orsakar en viss typ av fel.

Efter översiktssidan, följer det ytterligare sidor som är
en kopia av dokumentet som kontrollerats.

Dessa sidor har gula kommentarer ovanpå objekt som orsakar
varningar och röda kommentarer för objekt som orsakar fel.

Figur 2: En kommenterad preflight-rapport

Varje kommentar visar både namn och beskrivning av preflight-fel eller
-varning som utlöste det; det gör det enkelt för kunderna att se var
objektet var felaktigt och varför det var fel.

Transparensmaskrapport

Transparensmaskrapporten använder en kombination av transparenta objekt
och lagerhantering för att markera problemobjekt i ett PDF-dokument.

Rapporten fungerar bara i PDF-läsare som stöder lager
(t.ex. Adobe Acrobat eller Adobe Reader) och inte i läsare
som saknar detta stöd (som Apple Preview).

Figur 3: Transparensmaskpreflight-rapport

Lagerrapport

Lagerrapporten placerar objekt med ett särskilt problem i en egen lagervy;
detta gör det möjligt att växla mellan lagervyer för att se alla objekt som
orsakar ett särskilt problem.

Eftersom rapporten även lägger till bakgrundslager kan man enkelt se
problemobjekt på olikfärgade bakgrunder
(vilket är speciellt bra för att exempelvis tydligt visa vita objekt).

Rapporten fungerar bara i PDF-läsare som stöder lagerhantering
(t.ex. Adobe Acrobat eller Adobe Reader) men inte i läsare som
saknar detta stöd (såsom Apple Preview).

Figur 4: En lagerpreflight-rapport visar genomskinliga objekt
på en annorlunda färgad bakgrund

Anpassningsbara PDF-rapporter

Alla de klassiska PDF-rapporter är statiska,
i den meningen att man inte kan ändra layout,
färger eller text av preflight rapporter.

I vissa miljöer är det bra, men ofta vore det trevligare att
kunna ändra vissa aspekter av en preflight rapport
- särskilt om rapporten skall används för extern kommunikation.

Den anpassningsbara PDF-rapporten skapades specifikt för att
tillåta anpassning av hur preflight-rapporten ser ut och upplevs.
Denna rapporttyp är baserad på en HTML-mall (med stöd av CSS och JavaScript)
och eftersom man kan skapa sina egna mallar, är det lätt att ändra färger,
ändra eller lägga till egna logotyper eller utsmyckningar och
även ändra vilken text som visas.

När en mycket enklare och anpassad preflight-rapport behövs för att
kommunicera med kunder är den anpassade PDF-rapporten
det bästa sättet att åstadkomma detta...

Figur 5: Anpassningsbar PDF-rapport som ingår i pdfToolbox

Figur 6: En anpassad PDF-rapport baserad på en modifierad mall

I den modifierade rapporten ovan ändrades logotyper,
färgen på bakgrundselement ändrades från röd till lila
och även olika delar av texten har ändrades.
Naturligtvis är mycket större förändringar möjliga att göra
så länge man har viss kunskap om HTML och/eller JavaScript.

XML-rapporter

PDF-rapporter är användbara för att ge feedback till interna användare
eller externa kunder, men när en automatiserad process är inblandad är
PDF ofta ett mindre lämpligt format.

Av just den anledningen har pdfToolbox och pdfaPilot stöd
för att generera en XML-rapport som resultatet av preflight.

XML-filen innehåller all den information som finns i PDF-rapporter
(och mycket, mycket mer) och den är självklart bäst lämplig för att tolkas
av automatiserade processer eller skripts längre fram i arbetsflödet.

Vill du visa preflight-resultat inbäddade i en webbplats?
Skriv lite PHP-kod för att tolka preflight-rapporten
- det är allt som behövs.

Har du redan ett automatiserat arbetsflöde baseat på FileTrain eller Switch?
Länka då in XML-preflight-rapporten och du kan basera ytterligare
beslut på informationen i XML-rapporten.

Flera rapporttyper från en och samma preflight-körning

Ingen begränsning till bara en typ av rapport.

Alla automatiserade versioner av pdfToolbox eller pdfaPilot kan
generera flera rapporttyper från en och samma preflight-körning.

Detta gör det bekvämt att konfigurer ett arbetsflöde där

• en PDF-rapport skickas till en kund/användare och


• en XML-rapport används som indata till en databas eller
  andra jobbhanteringssystem.

En av de största styrkorna i pdfToolbox är möjligheten att göra preflight på
PDF-dokument och att returnera en detaljerad förteckning över alla fel och
varningar i PDF-dokumenten. Men i vissa fall är svaret "godkänd" eller
"icke godkänd" helt enkelt ett inte tillräckligt detaljerat svar.

Då gör visualiseringsfunktionen i pdfToolbox (och i pdfaPilot)
det enkelt att visuellt inspektera en PDF-fil.

Tryckfärgstäckning (Ink coverage)

Det kanske bästa exemplet på fall där visualiseringsfunktionen bevisar sitt värde är
när en preflight-kontroll säger att ett PDF-dokument använder för mycket tryckfärg.

Figur 1: Visualiseringsfunktionen visar färgtäckning för ett PDF-dokument

Tryckfärgtäckningsläget i visualiseringsfunktionen lägger en grå mask
över PDF-dokumentet markerar de områden i dokumentfilen som når över
en viss angiven tröskelnivå med ljusa färger:
gult för små överskridanden, via rött till lila för allvarliga överskridanden.

Detta ger dig en omedelbar uppfattning om hur allvarligt färgtäckningsproblemet är
och hjälper till att avgöra om filen fortfarande kan skrivas ut eller inte.

Separationer

I de fall där man tvivlar på om en fil kommer att separeras på rätt sätt,
eller om man bara vill undersöka färgblandning eller övertryck av vissa delar
är visualiseringsfunktionen användbar.

Man kan då välja mellan ett antal olika förhandsvisningslägen för att
visa enskilda separationer, visa enbart processeparationer,
vis enbart dekorfärgseparationer och mycket mer.

Figur 2: Visualiseringsfunktionen visar enbart cyan-separationen

Vid förhandsgranskning av separationer visar pdfToolbox
även den totala tryckfärgsmängden för separationer
(i procent av trimmruteyta och i kvadratcentimeter).

Denna information kan naturligtvis användas för kostnadsberäkningar.

Säkerhetszon

Med pdfToolbox och pdfaPilot kan preflight utföras
för att finna ut om objekt har tillräckliga utfall.

Detta är återigen ett område där man med visuell inspektion
ofta kan bestämma mer exakt om ett dokument i själva verket är
lämpligt för tryckning eller inte.

Visualiseringsfunktionen har ett "säkerhetszonsläge" där
antingen sidgräns eller utfallsarea markeras.
Dessa funktioner kan vara till stor hjälp för att hjälpa till att
bedöma ett visst PDF-dokuments status.

Figur 3: Förhandsgranskning av utfallsarea med visualiseringsfunktionen

Problem med felaktiga färgrymder och färger är ett mycket vanligt
problem vid grafiska arbetsflöden och pdfToolbox erbjuder en hel del
funktioner inom detta område för att lösa denna typ av problem.

Preflight

Först av allt, pdfToolbox stöder naturligtvis fullt ut preflight av färg.

I en preflight-profil är det möjligt att kontrollera användningen av RGB,
dekorfärg, kalibrerade färgrymder (såsom ICC-baserade färgrymder),
använd utdatametod ("output intent") och mycket mer. En komplett lösning
för att se till att den färg som återges faktiskt blir den som önskas.

Färgkonvertering med ICC-profiler

Den vanligaste färgkonverteringen är ett med ICC-profiler.
Utgående från ICC-profiler för källa och destination,
konverterar färgmotorn alla färger från källa till destination.

pdfToolbox Desktop har en dedikerad Switchboard-funktion
för denna typ av färgomvandling.

Figur 1: "Process conversion-flik i pdfToolbox Switchboard

Man kan ange vilken typ av fil som skall konverteras,
vilka färger som skall konverteras (i exemplet allt kommer att
konverteras med undantag av dekorfärger) och vad målet är.
En manuell eller interaktiv omvandling som självklart även kan
automatiseras med pdfToolbox Server/CLI/SDK.

Figur 2: Fixup-funktion för att konvertera alla färger till ISOCoatedv2

Fixup-funktionen “Convert colors” används för färgkonvertering.
Den kan konfigureras exakt som man vill och sedan ingå i en preflight-profil.

En sådan preflight-profil kan exekveras i alla
pdfToolbox-verktyg (Desktop, Server, CLI och SDK).

Färgkonvertering med DeviceLink-profiler

pdfToolbox stöder även färgkonvertering med DeviceLink-profiler.

Vid konvertering från CMYK till CMYK eller för särskild bearbetning,
såsom TAC-reduktion eller för att spara tryckfärg, ger färgkonvertering
baserad på DeviceLink-profiler ett bättre resultat.

Se även callas software blog om: Why DeviceLink profiles should interest you.

• Manuell användning av DeviceLink-profiler

I pdfToolbox Desktop Switchboard, under "Color groups" finns
funktionen "DeviceLink conversion".
Här kan önskad DeviceLink-profil väljas, vilka objekt den skall
exekveras på och vilken färgrymd som man vill konvertera.

• Automatisk användning av DeviceLink-profiler

För automatiserade arbetsflöden finns fixup-funktion för
färgkonvertering med DeviceLink-profiler.

Fixup-exemplet visar TAC-reduktion av
PDF-filer med DeviceLink-profiler från ColorLogic

• Hur får man tillgång till DeviceLink-profiler

pdfToolbox kan användas för att tillämpa DeviceLink-profiler på PDF-dokument,
men innehåller ingen profilredigerare eller stöd för att skapa DeviceLink-profiler.

För att kunna utnyttja möjligheterna med DeviceLink-funktionalitet behövs
färdiga DeviceLink-profiler och det finns ett antal alternativ för detta:

• Man kan använda de DeviceLink-profiler som ingår i tillvalsalternativet
  DeviceLink för pdfToolbox vilken är en separat beställningsbar produkt
  som innehåller en lista över viktiga DeviceLink-profiler,
  främst inriktade på att konvertera mellan standarder
  (t.ex. mellan SWOP och ISOCoated).


• Man kan även använda sina egna DeviceLink-profiler.
  Det finns olika verktyg som CoPrA från ColorLogic för att skapa DeviceLink-profiler.
  Vad som är viktigt är att se till att dessa profiler är öppna eller olåsta
  så att de är användbara i pdfToolbox.


• Man kan köpa ett DeviceLink-profiler från en annan leverantör.
  En sådan produkt innehåller förgjorda DeviceLink-profiler som
  skapats av den leverantören. Ett bra exempel på en sådan leverantör
  är ColorLogic som säljer ett brett sortiment av DeviceLink-profiler som
  inkluderar möjligheten att konvertera mellan standarder, att utföra
  TAC-reduktioner eller i fall då man behöver minska åtgången av tryckfärg.

Hantering av dekorfärger (spot colors)

Ändra eller borttagning av dekorfärger är en annan vanlig fråga och
pdfToolbox erbjuder ett brett utbud av funktioner för hantering av dekorfärger.

pdfToolbox Desktop erbjuder manuell/interaktiv hantering av
dekorfärger i ett PDF-dokument.

För varje dekorfärg finns möjlighet att ändra namnet,
ange alternativ färgrymd och värden, mappa den till en processfärg eller
annan dekorfärg eller helt enkelt konvertera den till CMYK.

I ett automatiserat arbetsflöde finns en fixup-funktion för att
mappa dekorfärger eller konvertera dem till CMYK.
Fixup-funktionen “Map spot and process colors” gör det möjligt
att mappa dekorfärger eller konvertera dem till CMYK.

Åtgärder för vanliga färgproblem

I praktiken finns det också ett antal vanligt förekommande färgproblem som
nte hanteras med någon av de ovanstående färgkonverteringsmetoderna.
Ett exempel är att korrigera fyra färger svart ("four color black")
vilket visas i fixup-funktionen nedan.

Med pdfToolbox kan alla vanliga färgproblem korrigeras, bland annat:

• Konvertera fyra färger svart till verklig svart


• Konvertera färg "All" (separation svart) till riktiga CMYK-svart


• Konvertera rik svart till verklig svart eller vice versa


• Inställning av svarta eller grå objekt för övertryck och vita objekt för "knockout"


• ...

Vilka av dessa korrigeringar som är lämpliga i ett arbetsflöde
är ett beslut som måste tas i varje fall.
pdfToolbox har all funktionalitet som krävs och som gör det enkelt
att genomföra alla nödvändiga korrigeringar i PDF-dokument!

callas programvara är specifikt avsedda för att genomföra kvalitetskontroll och
att förbereda dokument inför arkivering. Här nedan presenterar vi hur det
kan användas för att skapa ett smidigare arkivarbetsflöde:

• 2a. Skapande av arkivfärdiga PDF-filer


• 2b. Arkivering av e-post med bilagor

Mer och mer är PDF/A (ISO-standarden för långtidsarkivering av PDF-dokument)
det filformat som väljs och används för att arkivera dokumenthandlingar.

pdfaPilot är expert- och allround-verktyget för att skapa
digitala arkivfärdiga PDF/A-dokument;
Nedan beskrives standarder som stöds och hur man använder dem.

Olika versioner och utföranden av PDF/A-standarden

De första frågorna att ställa sig när man tänker skapa PDF/A-dokument är vanligtvis
vilken version och utföranden av standarden som skall användas.

Den fullständiga listan att välja ur är följande:

• PDF/A-1a, PDF/A-1b


• PDF/A-2a, PDF/A-2b, PDF/A-2u


• PDF/A-3a, PDF/A-3b, PDF/A-3u

Versioner och utföranden

PDF/A-1 den tillåter dock inte modernare PDF-funktionalitet såsom
transparens och komprimeringsformer för bilder och lager (skikt).

PDF/A-2 utökade stödet för dessa modernare funktioner och öppnade
också upp möjligheten att lagra andra PDF/A-filer inuti en PDF/A-2 fil
(dvs, tillåter en PDF/A-2 för att bete sig lite som ett litet arkiv).

PDF/A-3 är den allra senaste utökningen och öppnar nya möjligheter
för att lagra alla filer inuti en PDF/A-3 fil.
Det medför att e-postbilagor kan lagras i sitt ursprungliga källformat
inuti det arkiverade e-postmeddelandet eller att elektroniska fakturor i
PDF/A-3 format även inkluderar fakturauppgifter inbäddade i XML-format.




Utföranden

Utförande "b" eller "basic" fokuserar helt på visuell reproduktion;
det enda som räknas är att kunna se dokumentet på skärm eller att kunna
skriva ut det precis med samma utseende som när det stoppades in i arkivet.

Utförande "a" eller "avancerad" lägger till ytterligare krav.
Texten måste vara inbäddade på ett sådant sätt att den lätt kan extraheras
(innebörden måste vara tydlig, inte bara det visuella utseendet),
bilder måste ha alternativ text i samband med dem (åter igen för att
göra innebörden klar) och alla strukturelement i PDF/A måste
märkas upp (för att kunna skilja mellan olika rubriknivåer, brödtext,
sökbara stycken och tabeller osv).

Utförande "u" eller "Unicode" är ett utförande någonstans mellan "b" och "a".
Det är främst inriktad på visuell reproduktion, men kräver att all text
lätt kan extraheras eller är sökbar.




Vilken PDF/A-standard ska man använda?

Det beror mycket på typen av dokument som skall arkiveras och
vilka funktioner man vill aktivera i e-arkivet.

Tänk på att det är mycket lättare att skapa en "b" PDF/A-fil än en "a" PDF/A-fil
(på grund av alla de ytterligare kraven).

En god nyhet är att pdfaPilot stödjer alla versioner och alla
varianter av standarden, vilket ger total frihet att välja just den
PDF/A-standard som man behöver för sitt e-arkiv.

Interaktiv verifiering eller konvertering till PDF/A

pdfaPilot Desktop erbjuder olika sätt att kontrollera att en PDF-fil
uppfyller en viss PDF/A-version och olika sätt att konvertera
(eller försök att konvertera) en PDF-fil till önskad PDF/A-version.

Det enklaste sättet är dock funktionen "PDF/A med ett klick" (“PDF/A in one click”).

Figur 1: Funktionen "PDF/A med ett klick" ("The PDF/A in one click")
i pdfaPilot Desktop

Med åtgärdsknappen (knappen med kugghjulsikonen i det övre högra hörnet)
väljes önskad PDF/A-version och utförande ("b" / "a" / "U") som man vill arbeta med.

Fönstret erbjuder två knappar, en knapp för att kontrollera hur väl en PDF-fil uppfyller
vald PDF/A-standard, och en knapp för att konvertera PDF-filen till denna standard.

Genom att använda ställa in "pdfaPilot-preferenser", kan man välja om man vill
aktivera reservmetoder ("fallback") om ordinarie omvandling till PDF/A misslyckas.

Nödfallsmetoder (fallback methods) för konvertering

Nödfallskonverteringsmetoder används när pdfaPilot har försökt konvertera
till PDF/A och konverteringen av någon anledning ej lyckats.

Som en nödfallsmetod kan man då försöka:

• Konvertera hela dokumentet till Postscript och sedan tillbaka till PDF.

Detta tvingar fram en rad nyare PDF-funktioner som konverteras
till äldre funktioner och PDF-filen skrivs om från början,
vilket ibland rättar till problemen.



• Konvertera problemsidor till bilder.

Om vissa specifika sidor har problem kommer pdfaPilot att
konvertera bara de sidorna till bilder och infoga dem i PDF-filen
i stället för de ursprungliga sidorna.



• Konvertera alla sidor till bilder.

Om inget annat fungerar kan pdfaPilot skapa ett helt nytt PDF-dokument
och infoga en bildversion av alla sidorna i den ursprungliga PDF-filen
i det nya PDF-dokumentet i ett sista försök att åtgärda de problem
som finns i det ursprungliga PDF-dokumentet.

Naturligtvis tar dessa nödfallsmetoder tid och kan ofta innebära
en försämring i kvalitet för dokumenten som skall arkiveras.

Ett beslut måste tas i varje fall om man vill använda dessa metoder.
För besvärliga dokument som absolut måste arkiveras finns det dock ibland
inte något annat val än att konvertera dem enligt dessa nödfallsmetoder.

Automatiserad verifiering

I de flesta fall är volymen av filer som ska arkiveras i ett e-arkiv enorm;
pdfaPilot Server kan enkelt hantera sådana volymer och bearbeta
PDF-dokument i en automaticerad process.

Figur 2: Ett pdfaPilot jobb för automatisk konvertering till PDF/A-1b

Med pdfaPilot Server kan man skapa jobb för automatisk behandling
där varje jobb har en bevakad indatamapp ("watched folder"),
en tillhörande verifierings-/konverteringsprofil
och ett antal definierade utdatamappar.

Alla filer som placeras i den bevakade mappen plockas
automatiskt upp och bearbetas enligt den valda profilen.

Resultatet placeras i en utdatamapp för lyckade konverteringar
eller i en felmapp beroende på behandlingsresultatet.

Integrerad preflight

Ofta är det mest effektiva sättet att verifiera eller kontrollera PDF-filer
att integrera bearbetningen i en större lösning såsom en webbportal
eller dokumenthanteringssystem.

Med pdfaPilot kan integrationen göras med
en kommandoradslösning (CLI) eller en SDK-lösning.

• Kommandoradsintegration (CLI)

pdfaPilot CLI är en kommandoradstillämpning som kan startas från ett
terminal- eller kommandofönster, men som typiskt exekveras från en
tillämpning eller det script som det är interegrat i.


pdfaPilot CLI stöder all PDF/A-funktionalitet och kan automatiskt generera
detaljerade rapporter (i PDF- eller XML) för ytterligare automatisering.




• Integration med SDK (Software Development Kit)

pdfaPilot SDK är en lösning som ger integration på biblioteksnivå.
SDK innehåller de nödvändiga biblioteken, rubriker, dokumentation och kodexempel
för att närmare integrera PDF/A-stöd i en C, C ++, Java eller NET-program.

Detta kräver utvecklingsresurser,
men resulterar samtidigt i den allra närmaste integrationen.

E-post är idag en integrerad del av regelbunden affärskommunikation.
Det finns även lagar och bestämmelser som anger att e-post måste
arkiveras precis som alla andra affärs-/verksamhetsdokument.

pdfaPilot stöder fullt ut både manuell/interaktiv och automatisk e-arkivering.

Konverteringsmekanismer

pdfaPilot integreras inte i inkommande eller utgående e-postservrar för att göra sitt jobb.
Istället omvandlar pdfaPilot e-postmeddelanden i MSG- eller EML-format
(de två mest spridda e-filformaten) till PDF eller PDF/A-dokument.

Denna konvertering (omvandling) kan göras interaktivt i pdfaPilot Desktop eller
via bevakade mappar ("hot folders") i pdfaPilot Server eller integreras i andra
lösningar med pdfaPilot CLI och pdfaPilot SDK.

Konverteringar som stöds

Beroende på typ av e-post och typ av önskad konvertering erbjuder pdfaPilot
olika konverteringsmöjligheter. Alla valmöjligheter visas i pdfaPilot Switchboard
med förklaring av varje tillgänglig konverteringstyp.

Figur 1: Valmöjligheter i pdfaPilot Switchboard
för konvertering av e-post till PDF

Respektive konvertering sker enligt följande:

• PDF: Bädda in bilagor som original
  - ("PDF: Embed attachments as original").

Skapar ett vanligt PDF-dokument och bäddar in eventuella bilagor från
e-posten i det genererade PDF-dokumentet i sitt ursprungliga format.



• PDF: Bädda in bilagor som PDF
  - ("PDF: Embed attachments as PDF").

Skapar ett vanligt PDF-dokument.
Om e-posten har bilagor konverteras de till PDF-dokument och
bäddas in i det genererade PDF-dokumentet.



• PDF: Bädda in bilagor som original och PDF
  - ("PDF: Embed attachments as original and PDF").

Skapar ett vanligt PDF-dokument.
Om e-posten har bilagor konverteras de till PDF-dokument.
Resultatet av konverteringen till PDF och de ursprungliga bilagorna
bäddas in i det genererade PDF-dokumentet.



• PDF: Lägg till bilagor som ytterligare sidor
  - ("PDF: Add attachments as additional pages").

Skapar ett vanligt PDF-dokument.
Om e-posten har bilagor konverteras de till PDF och bifogas i slutet av
det konverterade PDF-dokumentet som ytterligare sidor.



• PDF/A-1: Lägg till bilagor som ytterligare sidor
  - ("PDF/A-1: Add attachments as additional pages").

Skapar ett PDF/A-1 dokument.
Om e-posten har bilagor konverteras de till PDF och bifogas i slutet av
det konverterade PDF/A-1 dokumentet som ytterligare sidor.

Detta är det enda tillåtna alternativet för PDF/A-1, eftersom standarden
PDF/A-1 inte tillåter inbäddade filer (oavsett av vilken typ de är).



• PDF/A-2: Bädda in bilagor som PDF/A
  - ("PDF/A-2: Embed attachments as PDF/A").

Skapar ett PDF/A-2 dokument.
Om e-posten har bilagor konverteras de till PDF/A-2 dokument och
inbäddas sedan i det genererade PDF/A-2 dokumentet.



• PDF/A-2: Lägg till bilagor som ytterligare sidor
  - ("PDF/A-2: Add attachments as additional pages").

Skapar ett PDF/A-2 dokument.
Om e-posten har bilagor konverteras de till PDF och bifogas i slutet av
det konverterade PDF/A-2 dokumentet som ytterligare sidor.



• PDF/A-3: Bädda in bilagor som originalet
  - ("PDF/A-3: Embed attachments as original").

Skapar ett PDF/A-3 dokument och bäddar in eventuella bilagor från
e-posten i det genererade PDF/A-3 dokument i sitt ursprungliga format.



• PDF/A-3: Bädda in bilagor som PDF/A om det är möjligt
  - ("PDF/A-3: Embed attachments as PDF/A if possible").

Skapar ett PDF/A-3 dokument.
Om e-posten har bilagor konverteras de till PDF/A-3 dokument och
inbäddas i det genererade PDF/A-3 dokumentet.

Om konvertering till PDF/A är inte möjligt för en viss bifogad fil inbäddas den
filen i sitt ursprungliga format istället i det genererade PDF/A-3 dokumentet.



• PDF/A-3: Bädda in bilagor som original och PDF/A
  - ("PDF/A-3: Embed attachments as original and PDF/A").

Skapar ett PDF/A-3 dokument.
Om e-posten har bilagor konverteras de till PDF/A-dokument.
Resultatet av konverteringen till PDF/A och de ursprungliga bilagorna
inbäddas i det genererade PDF/A-3 dokumentet.

• 3a. Skapa dynamiska arbetsflöden med hjälp av variabler

De flesta kontroller som man vill utföra på PDF-dokument är generiska:
färger måste vara korrekta, bildupplösningen måste vara tillräcklig,
felaktiga PDF-strukturer får inte förekomma och så vidare.
I dessa fall är det fullt möjligt att skapa en enda preflight-profil som kan
användas av många olika callas-verktyg eller i många olika arbetsflöden.

Men ibland är kontroller specifika för ett visst PDF-dokument och
kan inte enkelt användas för andra PDF-dokument.

Ett bra exempel på ett sådant fall är om man vill kontrollera
jobbdimensioner (såsom bredd och höjd).

Dessa mått kan mycket väl vara olika för varje jobb och det betyder
att man behöver duplicera jobbprofilen för varje verktyg och
infoga en särskild dimensionskontroll per verktyg...
Det låter inte som den bästa idén...

Naturligtvis har både pdfToolbox och pdfaPilot stöd för
variabler för dynamisk preflight (medger olika utföranden av
preflight i respektive verktyg eller för varje kontrollerad PDF-fil).

Och den bästa nyheten?
Det är lätt att använda dynamiska variabler i pdfToolbox och pdfaPilot!

Statisk (reguljär) storleks-/dimensionskontroll

Kontroll av storleken (dimensionen) för ett PDF-dokument innebär att
kontrollera höjd och bredd på en sidruta, typiskt trimmruta,
vilket ger dimensionen för den färdiga sidan. En sådan kontroll kan se ut så här:

Figur 1: Preflight-kontroll av höjden och bredden på trimmruta

Kontrollen testar bredd och höjd av trimmruta,
i detta exempel med beaktande av rutans orientering
(med andra ord, landskap och porträtt är inte utbytbara
med avseende på denna kontroll).

Dynamisk (variabel) storleks-/dimensionskontroll

I fönstret som definierar den statiska kontrollen (ovan)
syns ett antal orangefärgade ikoner.
Var och en av dem markerar möjligheten att ange en
variabel för kontroll av just denna egenskap.
När man klickar på dem startas variabelredigeraren ("variable editor"):

Figur 2: Variabelredigeraren ("The Variable Editor")

För att definiera en variabel i en kontroll- eller
korrigeringsfunktion i pdfToolbox behövs tre saker:

• "Label":

- Visas när kontrollen eller korrigeringen exekveras i pdfToolbox Desktop.



• "Default value":

- Det värde som används när inget särskilt görs under
exekveringen av kontrollen eller korrigeringen.



• "Internal Name":

- Variabelnamn som kan användas i pdfToolbox Server CLI eller SDK
för att modifiera vilket värde som faktiskt kommer att
användas av kontrollen eller korrigeringen.

För att göra kontrollen helt dynamisk måste invariabler
anges för trimmrutans bredd och höjd:

Figur 3: Dynamisk kontroll som visar använda variabler

De mer kryptiska värdena för egenskaperna bredd och höjd tydliggör att det
faktiskt finns en variabel som är definierad för var och en av dessa egenskaper.
Det är allt vi behöver definiera i kontrollen för att göra den dynamisk.

Användning av dynamiska profiler

• pdfToolbox Server

En preflight-profil som innehåller åtminstone en kontroll eller korrigering
som innehåller variabler kallas en dynamisk preflight-profil.

Sådana profiler kan väljas i pdfToolbox Server precis på
samma sätt som en vanlig profil.

Då kan man ändra vilka värden som ska användas genom att lägga till
ytterligare CLI-kommandon i jobbfönstret för pdfToolbox Server.

Figur 4: Jobbfönster för pdfToolbox Server

Även om ovanstående pdfToolbox Server jobb ser helt normalt ut,
kan ytterligare CLI parametrar läggas till för inställning av ingående variabler.

För varje variabeltillägg används formatet: "--setvariable=:"

• "variable_name" är det symboliska namnet för variabeln som
  den är definierad i kontrollen eller korrigeringen.


• "new value" är det värde man vill använda i pdfToolbox under preflight.

Som synes möjliggör detta att man tar en variabel preflight-profil och
konfigurerar olika jobb, vilka vart och ett kommer att utföra en annan
preflight-baserad på de "setvariable" kommandon som man
lagt till i jobbdefinitionen.



• pdfToolbox CLI och pdfToolbox SDK
  

  Man kan faktiskt gå ännu längre när man använder
  pdfToolbox CLI eller pdfToolbox SDK.

  Eftersom man där utfärdar kommandon för preflight på varje fil kan man
  faktiskt ändra hur preflight skall göras för varje enskild preflight-körning.

  Om man har en webbportal som kan ange vad kunden beställt är
  det värdefullt om man då kan ändra varje preflight för att matcha
  kontrollerna till vad kunden faktiskt beställt.

Möjligheter med variabler

Variabler kan läggas till kontroller och korrigeringar.
Den enda begränsningen är att kontrollens eller korrigeringens egenskap
måste ha den lilla orange knappen bredvid sig för att man skall kunna
definiera en dynamisk variabel.

Det är även möjligt att välja en kontroll eller korrigering i en profil och
konfigurera en variabel som kommer att fungera som en switch:

• ställ den till "1" och kontrollen eller korrigeringen utförs under preflight,


• ställ den till "0" och den utförs ej.

Detta gör att man kan skapa profiler som innehåller valfria
kontroller eller korrigeringar enkelt.
Genom att ställa in värdet för variablerna man använder till korrekta värden
säkerställs att kontroller och korrigeringar utförs eller ej utförs...