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