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

Fri Nov 24 19:35:45 CET 2023

Hei igjen,

Her er motsatt funksjonene for å slette Watermarks ved hjelp av Aspose 
Java API fra 
<URI:https://gist.github.com/aspose-pdf/474c352a71ac9477aa0d604fd32e1c6a>:

     // Open source PDF document
     Document pdfDocument = new Document("input.pdf");

     // Delete all annotation
     pdfDocument.getPages().get_Item(1).getAnnotations().delete();

// Save the update document
pdfDocument.save("output.pdf");

Se forholdsvis

https://aamot.software/Aamot_CV_2022.pdf (med vannmerke)
https://aamot.software/Aamot_CV_2023.pdf (uten vannmerke)

Mvh,
Ole

> On Jan 3, 2023, at 7:39 AM, Aamot Software <ole at aamot.software> wrote:
> 
> 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
> _______________________________________________
> nikita-noark mailing list
> nikita-noark at nuug.no
> https://lists.nuug.no/mailman/listinfo/nikita-noark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nuug.no/pipermail/nikita-noark/attachments/20231124/4691c2a6/attachment-0001.htm>