Watermarks i PDF (Re: Sv: Validering av filformater)

[Aamot Software]

Hei,

Både Adobe Acrobat og LibreOffice har en funksjon for å skrive 
Watermarks i PDF'er.

Se 
<URI:https://helpx.adobe.com/no/acrobat/using/add-watermarks-pdfs.html> 
og 
<https://www.libreofficehelp.com/how-to-add-watermark-in-libreoffice-writer/>

Se eksempel på et PDF-dokument med teksten ("GNOME Foundation") i grønn 
Watermarks skrevet fra LibreOffice på 
<URI:https://www.aamot.software/Aamot_CV_2023.pdf>

Aspose Java API har et programmertbart Java-grensesnitt for å skrive 
Watermarks i PDF'er.  Se 
<URI:https://blog.aspose.com/pdf/add-watermark-to-pdf-using-java/#Java-API-to-Add-Watermark-to-PDF>

Source (pom.xml):

<repository>
     <id>AsposeJavaAPI</id>
     <name>Aspose Java API</name>
     <url>https://repository.aspose.com/repo/</url>
</repository>

<dependency>
     <groupId>com.aspose</groupId>
     <artifactId>aspose-pdf</artifactId>
     <version>21.6</version>
</dependency>

Source (Watermarks.Java):

// Load PDF document
Document doc = new Document("Aamot_CV_2022.pdf");

// Create a formatted text
FormattedText formattedText = new FormattedText("GNOME Foundation", 
java.awt.Color.GREEN, FontStyle.Courier, EncodingType.Identity_h, true, 
40.0F);

// Create watermark artifact and set its properties
WatermarkArtifact artifact = new WatermarkArtifact();
artifact.setText(formattedText);
artifact.setArtifactHorizontalAlignment (HorizontalAlignment.Center);
artifact.setArtifactVerticalAlignment (VerticalAlignment.Center);
artifact.setRotation (90);
artifact.setOpacity (0.5);
artifact.setBackground (false);

// Add watermark to the first page of PDF
doc.getPages().get_Item(1).getArtifacts().add(artifact);

// Save watermarked PDF document
doc.save("Aamot_CV_2023.pdf");

Mvh,
Ole

Den 2022-12-19 11:41, skrev Thomas Sødring via nikita-noark:
> Hei,
> 
> Merk! Jeg kan ikke nok om PDF/A til å uttale med bastant. Ta det jeg
> sier med en
> klype salt. Jeg synes spørsmålet er interessant og kaster ut mine
> tanker
> og håper andre kan komme med innspill.
> 
> Når jeg leser om PDF/A og signaturer (overfladisk) så ville jeg
> trodd at dette
> ikke ville være et problem. Jeg forstod det slik at signaturer dekket
> et sett
> av innhold i dokumentet og selve signaturen ligger i en "lomme" i PDF
> filen.
> 
> I teorien skal det være mulig å flytte innholdet og signaturen inn i
> en PDF/A
> fil, men kun dersom det ikke ble gjort endringer til innhold feks et
> problem med
> en font / bilde. Det er vel avhengig av hvor mye konvertering som må
> skje.
> 
> En stund tilbake ble det sagt at signaturer er noe fagmiljøet ikke
> har tenkt over i det
> hele tatt. Det er ikke sant da signaturer er noe som er beskrevet i
> Noark og
> løsningen der er jeg delvis enig i.
> 
> Noark håndterer problemstillingen med at Noark velger at du kun skal
> dokumentere
> hvorvidt dokumentets signatur stemte under danningen. Noark sin
> XML/XSD gjør
> ikke plass for noe teknisk bevaring av PKI infrastrukturinformasjon.
> 
> <xs:complexType name="elektroniskSignatur">
>   <xs:sequence>
>     <xs:element name="elektroniskSignaturSikkerhetsnivaa"
> type="n5mdk:elektroniskSignaturSikkerhetsnivaa"/>
>     <xs:element name="elektroniskSignaturVerifisert"
> type="n5mdk:elektroniskSignaturVerifisert"/>
>     <xs:element name="verifisertDato" type="n5mdk:verifisertDato"/>
>     <xs:element name="verifisertAv" type="n5mdk:verifisertAv"/>
>   </xs:sequence>
> </xs:complexType>
> 
> (ref:
> https://github.com/arkivverket/schemas/blob/master/N5/v5.0/arkivstruktur.xsd#L566)
> 
> 
> Noark 5v4 hadde en restriksjon på elektroniskSignaturVerifisert som
> ble borte i
> Noark 5v5.
> 
> <xs:restriction base="xs:string">
>  <xs:enumeration value="Signatur påført, ikke verifisert"/>
>  <xs:enumeration value="Signatur påført og verifisert"/>
> </xs:restriction>
> 
> I teorien kan det i Noark 5v5 stå "Signatur påført, verifisert og
> ikke verifisert"!
> 
> Denne generelle tilnærmingen er noe jeg opplever som både positivt
> og negativt.
> Det er positivt at Noark har valgt hvordan signaturer skal håndteres
> og her er
> det en fiks ferdig tilnærming fagmiljøet kan diskutere for å komme
> fram til en
> best practice. Positivt også at det er så enkelt. Men den verdien i
> elektroniskSignaturVerifisert kan bli viktig senere.
> 
> Det vi tidligere har diskutert i nikita prosjektet er hvorvidt
> organisasjoner
> burde bevare den offentlig nøkkelen som ble brukt til å verifisere
> signaturen,
> eller ikke. Fra en etterprøvbarhetsperspektiv så er svaret til det
> JA. Depot
> burde bevare de offentlig nøklene som er brukt. Men slik er det ikke
> i Noark og
> den delen av en "chain-of-custody" skal bevist kastes. Jeg mistenker
> at grunnen
> Noark gjør det slikt er fordi Noark ikke skal styre for mye dette da
> det kan
> være noen uante kostnader her. Altså at depot ikke skal bry seg om
> autentisitet
> på dette nivået.
> 
> Tid vil være en utfordring dersom vi bevarer slike nøkler med
> dokumentet. Vi må
> også bevare hvilken algoritme og håpe at det fortsatt vil være en
> implementasjon
> tilgjengelig som gjør at vi kan verifisere signaturen på en
> uavhengig vis.
> 
> Dette med uavhengig vis er viktig synes jeg! Jeg mistenker at Norge
> vil bruke
> informasjonssiloer og bli mer og mer avhengig av leverandører for
> ting
>  som verifisering av signatur. Da vil depot ha et problem dersom det
> er viktig å
> sikre etterprøvbarheten til signaturen. Dersom etterprøvbarheten er
> viktig så
> må depot besitte kompetanse (enkelt) og infrastruktur, noe som ikke
> er enkelt
> om det er en proprietær tjeneste der ting er skjult.
> 
> Noark løser problemet ditt dersom du kan leve med at depot ikke
> trenger å
> senere verifisere signaturer på PDF/A variantene. Du trenger bare å
> verifisere
> at dokumentets signatur er gyldig og så konvertere til PDF/A.
> 
> Dersom vi ser litt mer på dette så er det vel slik at de PDF/A filer
> burde være
> identifisert med PUID fmt/476 (2a) eller fmt/477 (2b), men det du
> etterspør er
> egne PUID for PDF/A filer som inneholder en signatur som kan
> verifiseres.
> 
> https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1263
> 
> https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1264
> 
> 
> fmt/276 er danningsformatet for PDF 1.7 (slik jeg forstår det) så
> det er ingen
> forsøk på å få dette til PDF/A.
> 
> https://www.nationalarchives.gov.uk/PRONOM/Format/proFormatSearch.aspx?status=detailReport&id=1016
> 
> 
> Jeg husker jeg snakket med en leverandør en gang om mismatch i
> registrerte
> filformater i databasen og de fortalte at det var en nesten umulig
> oppgave å
> vite om ting faktisk var i PDF/A. Jeg ville håpet at vi er kommet
> videre siden
> da!
> 
> Når det gjelder spørsmål 1:
> 
> Først vil jeg trekke oppmerksomheten til en diskusjon i Noark på
> github
> 
> https://github.com/arkivverket/noark5-standard/pull/99#issuecomment-814962618
> 
> 
> der det framkommer at noen depot institusjoner ikke ønsker å beholde
> flere
> kopier av et dokument. Greit å ha en slik perspektiv i bakhodet når
> man
> diskuterer dette.
> 
> "Vil bruk av metadatafeltene elektroniskSignatur i Noark kunne
> erstatte
> bevaringen av en uendret versjon?"
> 
> Min forståelse er at du har et signert dokument i vanlig PDF, ikke
> PDF/A. Så
> denne produksjonsformat PDF filen kan inneholde fonter og annet
> informasjon som
> er lenket til operativsystemet som skapte PDF dokumentet. Dette er noe
> som vil
> ha utfordringer når det gjelder bevaring. Når du konverterer til
> PDF/A blir
> signaturen feil. Så du er nødt til å konvertere til PDF/A, men du
> mister
> signaturen. Da må du ivareta signaturen på en måte. Her kan Noark
> sin metadata
> brukes til å bekrefte at signaturen stemte. Men egentlig kan du vel
> bevare begge
> deler, men produksjonformat PDF'n vil miste noe av nytteverdien det
> øyeblikket det
> ikke er mulig å verifisere signaturen og dersom du er avhengig av en
> tjeneste
> for å verifisere så vil det skje når tjenesten legges ned  /
> nøkler ikke er
> tilgjengelig.
> 
> Merk! Jeg kan ikke nok om postens tjeneste for å vite om offentlig
> nøkler er fritt
> tilgjengelig for nedlasting, hva skjer dersom en privatnøkkel blir
> lekket og det
> er tilbakekalling osv.
> 
> Hva som vil gi best integritet over tid? Jeg tror etterprøvbarheten
> og mulighet
> til å verifisere dokumentet når som helst vil være det som gir best
> integritet.
> Dersom det ikke er mulig så vil det kanskje være en sporbar prosess
> på
> verifikasjonen som er best. At det registreres at signaturen er
> verifisert,
> av hvem og når. "Hvem" er vel bare et programvare.
> 
> Spørsmål 2:
> 
> Litt beslektet diskusjon fra arkade5:
> 
> https://github.com/arkivverket/arkade5/issues/97
> 
> At Pronom ikke er ønskelig i danning, det er en depot anliggende. I
> nikita ønsker
> jeg å bruke relevant verktøy for å identifisere pronomkoder så
> fort som mulig.
> Jo mer kontroll du har, jo bedre. Du er inn på det når du etterspør
> pronomkoder
> for å skille signert/ ikke signert PDF/A
> 
> Jeg vet at Petter Reinholdtsen jobbet med å få sosi koder inn i
> pronom listen
> og lagde en M701-verdikatalog for Noark 5 (Tjenestegrensesnitt)
> 
> https://gitlab.com/petterreinholdtsen/m701-noark5-katalog
> 
> Dette er vel et spørsmål som må løftes høyere. Jeg har ingen
> tillit at det
> finnes noen hos Arkivverket som har evnen eller kunnskap til å gjøre
> denne
> jobben så jeg er usikker hvem som er riktig instans.
> 
> Det må være mulig å gjøre dette, men er det så viktig å ha egen
> pronom kode for
> en PDF/A som er signert? Jeg tror JA, det er veldig viktig. Det er
> litt som
> pronomkoder for docx. Det er interessant og viktig å vite om du har
> docx filer med PUID fmt/494 fordi de er kryptert!
> 
> -------------------------
> 
> Fra: nikita-noark <nikita-noark-bounces at nuug.no> på vegne av Thomas
> Sødring via nikita-noark <nikita-noark at nuug.no>
> Sendt: torsdag 15. desember 2022 09:40
> Til: nikita-noark at nuug.no <nikita-noark at nuug.no>
> Emne: Vs: Validering av filformater
> 
> Hei,
> 
> Denne kom i innboksen min i går kveld fra Pål Mjørlund ved
> Innlandet fylkesarkiv og er et tematikk som jeg synes er interessant
> og relevant her på listen. Jeg har litt dårlig tid med sensur
> akkurat nå, men tenkte å svare her og la andre kommentere dersom de
> ønsker det.
> 
> -- start --
>  Mange har nå gått over til fullelektronisk arkivering av
> dokumenter. I en del tilfeller gjelder dette også avtaler som har
> blitt sendt til digital signering. Jeg oppfatter at de fleste
> kommunene benytter den nasjonale fellesløsningen til dette, og at det
> dermed er postens signeringsportal som blir brukt for selve
> signeringsprosessen. Jeg antar at du har kjennskap til løsningene og
> teknologien, men dokumentasjon på løsningen finnes her:
> https://signering-docs.readthedocs.io/en/latest/index.html [1] . Dette
> betyr at det allerede finnes en del dokumenter i sak/arkivløsningene
> som inneholder en digital signatur (basert på PAdES og XAdES).
> 
> Jeg har gjort noen kontroller i forhold til dokumenter som har blitt
> arkivert med avansert digital signatur, og oppdager at disse
> dokumentene heller ikke validerer som godkjent arkivformat. Dette har
> vært kjent hos Arkivverket og det ble på et møte sagt at dersom det
> kun er signaturen som avviker fra PDF/A-2, så godkjennes signerte
> PDF-dokumenter. Dette er imidlertid ikke helt enkelt. Dokumentene som
> jeg finner i sak/arkivløsningen fremstår dessverre ikke som PDF/A i
> det hele tatt, men som PDF 1.7 (pronom: fmt/276). Dette gjelder også
> dokumenter som var konvertert til PDF/A før de ble sendt til
> signering. Jeg har ikke funnet noen egen pronom-kode som viser at
> dette dokumentet inneholder en digital signatur, selv om det
> sannsynligvis burde være mulig å identifisere signaturen inne i
> dokumentet.
> 
> Bekymringen min er derfor i forhold til videre håndtering av disse
> dokumentene. Den digitale signaturen kan kun bekreftes så lenge filen
> er uendret. Dersom vi produserer PDF/A av et signert dokument vil det
> ikke være mulig å validere signeringen lenger. Denne utfordringen
> kan komme i forbindelse med produksjon av arkivuttrekk, men også i
> konverteringsprosesser som skjer i et arkivdepot for å vedlikeholde
> arkivdata.
> 
> Jeg har egentlig to hovedspørsmål:
> 
> Spørsmål 1:
> I Noark-løsninger kan det være flere måter å håndtere digitale
> signaturer. I de uttrekkene vi har mottatt, har jeg så langt ikke
> sett at metadatafeltet elektroniskSignatur har blitt benyttet (M507,
> M508, M622 og M623). I mitt hode kunne en slik kontroll være
> automatisert i en løsning som benytter signeringsportalen. Jeg har
> imidlertid ikke fått signaler om at noen løsninger støtter en slik
> kontroll.
> Flere opererer med flere varianter (eller bruker betegnelsen
> «versjoner») av dokumentet – slik at løsningen kan lagre både en
> arkivvariant og en signert variant. Det er imidlertid ikke praktisert
> å ta med flere av disse variantene i uttrekk. Vi ser at behovet for
> flere varianter er økende, ved at du gjerne skal ha en offentlig
> variant (i forhold til meroffentlighet og/eller publisering på
> postjournal hvor vi nå får krav om PDF/UA). Vil bruk av
> metadatafeltene elektroniskSignatur i Noark kunne erstatte bevaringen
> av en uendret versjon av det signerte dokumentet og hvilken løsning
> vil gi best integritet over tid?
> 
> Spørsmål 2:
>  Vi ønsker at en dokumentanalyse basert på PRONOM skal være
> grunnlaget for å gjennomføre en dokumentkonvertering. Vi oppfatter
> at filnavn og mime-type er mer utbredt grunnlagsdata i dag. Dersom
> signerte dokumenter hadde hatt egne PRONOM-koder ville det vært
> betydelig enklere å bevare originalversjonen av et signert dokument.
> Har du noen formening om hvor enkelt det er å få definert de
> signerte PDF-dokumentene inn som egne innføringer i
> PRONOM-registeret, og vil det egentlig være nødvendig?
> 
>  --  slutt --
> 
> Links:
> ------
> [1] 
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsignering-docs.readthedocs.io%2Fen%2Flatest%2Findex.html&data=05%7C01%7Ctsodring%40oslomet.no%7Cac65966482e246c1243008dade780d3a%7Cfec81f12628645508911f446fcdafa1f%7C0%7C0%7C638066905256161256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cYLBYsZydx55UDc1VEssaSQkWcPWQ%2FPmkkiBlfLf%2BnI%3D&reserved=0
> _______________________________________________
> nikita-noark mailing list
> nikita-noark at nuug.no
> https://lists.nuug.no/mailman/listinfo/nikita-noark