arrow_back Hvordan unngå at PDF-konvertering i Decom via Word eller LibreOffice produserer filer med uleselig tekst?

Question

Har flere PDF-filer som KOST-Val mener ikke er på PDF/A-format:
Of the 122 characters in the document, 42 (34.43%) is unknown and 0 (0%) is undefined.

Filene kan åpnes i Word og LibreOffice uten feilmelding, men deler av innholdet er uleselig ved at tekst er erstattet med tekst uten mening - sannsynlig sammenfallende med antall tegn (characters) rapportert av KOST-Val.

Er det mulig for Decom (egentlig Word- eller LibeOffice-konverteringen) å sjekke at en PDF-fil inneholder ukjente tegn og ikke konverterer filer med denne feilen? Hvis ikke, risikerer man å sitte igjen med uleselige PDF-er i avleveringer .

Filene jeg har, kan åpnes fullt leselig i f.eks Adobe Acrobat Reader DC med en infotekst i toppen av dokumentet:
Filen samsvarer med PDF/A-standarden og er åpnet med skrivebeskyttelse for å hindre endringer

veraPDF validerer filene å være på PDF/A-format.

Oppdatert 17:03.21:
Utklippet viser et eksempel på en PDF-fil som KOST-Val har validert å ikke være på PDF/A-format. Øverst i utklippet vises filen i Adobe Acrobat Reader, på midten slik den vises i LibreOffice Draw og nederst hvordan utsnittet ser ut i Word.

Når verken LibreOffice eller Word viser fila korrekt før konvertering, vil den følgelig ikke bli korrekt etter konvertering dersom man bruker Word eller LibreOffice (soffice.bin --convert-to pdf) til dette.

Comments

Ved å bruke noe annet en Decom for konvertering.

Decom tillater ikke å kontrollere prosessen under noen omstendigheter. Decom er utviklet uten noen grad av oppmerksomhet til konverteringsprosessen. Dette kan nok virke merkelig siden DCM (modulen som konverterer) koster penger og bare benytter seg av programvare installert på maskinen til konverteringen, versjonen av LibreOffice eller MS Word kan ha noe å si her, men det er umulig å vite når Documaster hverken ønsker å snakke om hva som skjer under panseret eller virker særlig opptatt av å fikse problematikken.

Jeg anbefaler deg å se etter andre programvarer som kan håndtere filkonvertering. Jeg kan her nevne 4-heights Conversion Service eller PixEdit Server. Du må følgelig også lage et skript som henter ut bin filene fra siardfilene og kjøre droid for å analysere formater.

Berikelse av siard kan også gjøres på andre måter, men det er en helt annen diskusjon.

---

En utdyping av olealdric sin kommentar om Decom DCM (Document Converte Module):

Det er korrekt at Decom DCM benytter kall til enten LibreOffice eller MS Office for selve transformasjonen fra produksjonsformat til arkivformate PDF/A

Decom DCM gjør i tillegg følgende
- Mime analyse av alle LOBs i SIARD-uttrekket (BLOBs = Binære filer, CLOBs = tekstfiler inklusiv RTF i tekstfelter)
- Sjekker MIME til file extension liste
- Sjekker om file extension er aktiv kandidat for å lage arkivformat av
- Sjekker om ev. PDF-filer allerede er PDF/A
- Lar binære filer og ukjente MIME-formater forbli .bin for BLOBS og .txt for CLOBs
- Legger til korrekt filending for kjente filtyper (.bin => .bin.docx / .bin => .bin.pdf, .txt => .txt.txt / .txt => .txt.rtf
- Hvis .bin.pdf => Valider for PDF/A
- Hvis arkivforamat => ingen DCM
- Hvis produksjonsformat som ikke er i kjøreliste => ingen DCM
- Hvis produksjonsformat som er i kjøreliste => kjør DCM
- Hvis kjørt DCM => Valider for PDF/A
- Loggføring alt over (og logging må forbedres)
- Ved Decom Merge bruker Decom alle Decom DCM info over til å lage ny beriket SIARD med alle beskrivelser gjenom DCM-prosessen og alle dokumenter etter jobbene over, der table[n].xml for alle tabeller med BLOBs eller CLOBs er oppdatert hver rad med endrede file="path", length="lengde" og digest="sjekksum" atributter for radens kolonne med LOB

Forøverig er det mange veier til rom - detaljert beskrivelse av Decom loggene og alle kjente pattern for arbeidet over kommer når jeg får tid til å skrive svaret!

---

Se ny info i mitt opprinnelige spørsmål.