LandNutzen.Anmelden

Produktionsnachweis: PDF-Mehrseiten-Viewer

Aussage dieses Nachweises

Feste Fixture-Eingaben bilden im produktiven Report-Renderer dieselben semantischen Free- und Premium-Mehrseitenprofile ab, deren Hintergrund in Poppler-, PDFium- und Apple-Viewern weiß bleibt. Die finalen PDF-Bytes enthalten laufbezogene Werte und sind daher bewusst keine reproduzierbaren Golden Hashes; die unten genannten SHA-256-Werte identifizieren jeweils exakt das manuell geprüfte Artefakt. Der Nachweis prüft nicht nur die erste Seite oder ein Komponenten-Snapshot, sondern den finalisierten PDF-Output einschließlich Textschicht, Linkannotationen, Metadaten, Dokumentensprache und lückenloser Seitenzahlen.

Vier voneinander unabhängige Ebenen sind belegt:

  1. feste, netzwerkfreie Free- und Premium-Fixture-Eingaben für den echten renderReportPdf-Pfad;
  2. ein verpflichtender Linux-CI-Job mit beiden Poppler-Backends;
  3. vollständige Sichtprüfungen in PDFium, Chromium und Apple Vorschau; und
  4. ein commitgenauer Readback eines aktuell in Produktion gerenderten PDFs.

Automatischer Free-/Premium-Vertrag

npm run qa:pdf:poppler erzeugt zwei feste, nicht personenbezogene Fixtures. Beide verwenden coordinate: null, blockieren jeden Netzwerkzugriff und enthalten ausschließlich erfundene QA-Daten:

Viewer-PrüfpfadProfilSeitenSHA-256 der konkret geprüften Fixture-Datei
PDFium direkt / Apple VorschauFree3242fcaf033ebc6db1993297e5c0db722d69da4f16d28c1c4f06a2205632a88e1
PDFium direkt / Apple VorschauPremium48468dc217e080c6fbd226ab2f19e3ded82b6db3847a0b4f55b498e2c92eddfe0
Chrome über temporäre HTTPS-PreviewFree3e97a3e41f9b9c6b84a918585204f953628b2e0ae7b79133b58c0d1568a2d6eab
Chrome über temporäre HTTPS-PreviewPremium48659f621b65064ab9a0dc730a3483aa40de327856de762c4f3d649b5c817441f

Für jedes Profil prüft das Harness:

  • alle physischen Seiten mit pdftoppm -gray und pdftocairo -gray -png;
  • weiße Außenränder, mittlere Helligkeit, sehr dunkle Pixel und die dunkelste Rasterzeile gegen explizite Fehlergrenzen;
  • sichtbaren Body-Ink im um Kopf, Fuß und Seitenrand beschnittenen Crop;
  • exakt eine nichtleere Rasterdatei pro PDF-Seite und Backend;
  • die vollständige Textschicht mit Seite X / Y; jede Seite muss mehrere seitenspezifische Body-Marker enthalten;
  • echte URI-Linkobjekte mit pdfinfo -url;
  • A4, Seitenzahl, Titel, Autor, Betreff, Schlüsselwörter, Creator, Producer, unverschlüsselten Output und Katalogsprache de-AT; sowie
  • die Abwesenheit von Premium-Inhalt im Free-Profil und seine Anwesenheit im Premium-Profil.

Die Marker-Map pinnt den gegenwärtigen Fixture-Aufbau bewusst auf Free 3 und Premium 4 Seiten. Eine fachlich beabsichtigte Umfangsänderung bleibt zulässig, muss aber ihre neue Seitenzuordnung und Body-Marker im selben Diff explizit aktualisieren; zusätzliche körperlose Seiten können dadurch nicht unbemerkt grün werden. Die negative Gegenprobe besteht ausschließlich aus den langen, wiederholten Kopf- und Fußzeilen: Sie hätte die frühere Textlängenprüfung bestanden und scheitert nun am fehlenden Body-Marker STANDORT.

Das zusätzliche Rastergate bewertet Pixel bis zur Helligkeit 220 als sichtbar und verlangt mindestens 0,150 % Body-Ink. In den echten Fixture-Rastern lagen alle Seiten zwischen 0,5742 und 11,5885 Prozent; selbst die hellste Seite hat damit die 3,83-fache Reserve. Eine zweite Gegenprobe zeichnet dunkle Kopf-, Fuß- und Seiten-Chrome bei vollständig weißem Body. Sie besteht die früheren Rand-, Helligkeits- und Dunkelflächen-Gates, scheitert aber gezielt mit 0,000 Prozent Body-Ink.

Der separate CI-Job PDF-Poppler-Regression lief im PR in 56 Sekunden mit Ubuntu 24.04 und poppler-utils 24.02.0-1ubuntu9.9. Free bestand mit 3/3, Premium mit 4/4 Seiten. Derselbe Job ist auf dem Produktionscommit in der Main-CI erneut grün. Die große verify-Suite bestand im PR zusätzlich in 9:39 Minuten einschließlich TypeScript, ESLint, 3.397 bestandenen Unit-Tests und sämtlichen PostgreSQL-/Release-Gates.

Das nach dem unabhängigen Abschlussreview ergänzte sichtbare Body-Ink- und seitenspezifische Semantikgate ist nicht rückwirkend diesen Läufen zugeordnet: Es lief separat auf Abschluss-PR-Commit 1dc24520982082217768f09f3046b2a0309931f3 im Job 98103713686 und bestand in 57 Sekunden erneut mit Free 3/3 und Premium 4/4 in beiden Backends.

Viewer-Matrix

ViewerVersionUmfangErgebnis
Poppler lokal26.08.0Free 3/3, Premium 4/4Beide Backends, alle Struktur- und Rastergrenzen bestanden
PDFium direkt152.0.7947.0Free 3/3, Premium 4/4Alle sieben Seiten eindeutig hell; Text und Seite X / Y auf jeder Seite
Google Chrome/PDFium151.0.7922.174Free 3/3, Premium 4/4; Produktion 12/12Jede Seite direkt angesprungen; Textauswahl und Linkinteraktion in beiden Fixtures; keine Schwarzfläche
Apple Vorschau11.0 auf macOS 26.5.1 (25F80)Free 3/3, Premium 4/4Alle Seiten weiß; Text, Links, Seitenzahlen und Dokumentinformationen vorhanden

Die direkte PDFium-Rasterung meldete für die sieben Fixture-Seiten mittlere Helligkeiten zwischen 243,04 und 254,05; der äußere Rand war vollständig hell. Apple Vorschau zeigte auf allen sieben Seiten konsistenten Seiten-Chrome und stellte Titel, Autor, Betreff, Creator und Producer in den Dokumentinformationen bereit.

Chrome lud beide nicht personenbezogenen Fixture-Dateien über eine temporäre, geschützte Vercel-HTTPS-Preview. Alle 3 Free- und 4 Premium-Seiten wurden über die Seitennavigation einzeln aufgerufen und waren inhaltsverschieden. Die mittlere Helligkeit lag zwischen 241,91 und 253,23, der sehr dunkle Pixelanteil zwischen 0,0007 und 0,0011 Prozent und die niedrigste gemessene Randhelligkeit bei 235,86. Strg+A markierte die Textschicht in beiden Profilen sichtbar; ein Klick auf den Report-Permalink löste jeweils die Linkannotation bis zum absichtlich ungültigen Ziel unter qa.landnutzen.invalid aus. Das temporäre Preview-Deployment wurde danach gelöscht.

Im echten Chrome-Viewer wurde das produktive zwölfseitige PDF auf Ganzseitenansicht gestellt und jede Seite über die Seitennavigation einzeln aufgerufen. Die zwölf Screenshots waren inhaltsverschieden. Innerhalb der weißen PDF-Seiten lagen die mittleren Helligkeiten zwischen 236,74 und 253,08, der sehr dunkle Pixelanteil zwischen 0 und 0,01 Prozent und die mittlere Randhelligkeit zwischen 246,08 und 246,13. Damit ist der ursprüngliche Viewerfehler nicht nur über eine PDFium-Bibliothek, sondern im realen Chromium-PDF-Viewer gegengeprüft.

Produktionsdeployment und Live-Readback

Vercel meldete Deployment dpl_DzPRbsRjNEY6xCMBhrP1X2L3ArBm als READY, target=production und band es an www.landnutzen.at, landnutzen.at sowie den Main-Alias. Die Deployment-Metadaten enthalten exakt den Merge-Commit 734f22f3b17de1593da72ef997f7f1eac5e38e50.

Der PDF-Endpunkt selbst sendet bewusst keinen X-Deploy-Commit-Header. Deshalb wurde der maschinelle PDF-Readback am 26. August 2026 um 07:22:25 UTC von zwei schreib- und quotenfreien 400 address_missing-Guards auf POST /api/v1/report umschlossen. Beide Guards lieferten den vollständigen Produktionscommit und Cache-Control: private, no-store.

Der dazwischen erneut gerenderte, bereits dokumentierte und nicht personenbezogene Rathaus-Report ergab:

PrüfungErgebnis
gespeicherter ReportHTTP 200
PDFHTTP 200, application/pdf, private, no-store, nosniff
Seiten12
Bytes310.467
SHA-25635bc580035778a02f95111dcbf7c2921b5181e9ae979dff3004d6903df1336d7
echte URI-Linkobjekte31
Sprache / Formatde-AT / A4
pdftoppm12/12 Seiten bestanden
pdftocairo12/12 Seiten bestanden
Commit-Guard nach dem PDFweiterhin exakt 734f22f3b17de1593da72ef997f7f1eac5e38e50

Textschicht und Seite X / Y waren auf allen zwölf Seiten vollständig. Beide Poppler-Renderer bestanden dieselben Schwarzflächen- und Randgrenzen wie die CI-Fixtures. Der davon getrennte Chrome-Check verwendete denselben Produktionsendpunkt und denselben gespeicherten Report; wegen laufbezogener PDF-Werte wird keine Bytegleichheit der beiden Antworten behauptet.

Datenschutz, Aufräumen und verbleibende Grenze

Für den Live-Nachweis wurde kein neuer Report, kein Konto und kein personenbezogener Datensatz erzeugt. Die bereits bestehende öffentliche Gemeindeadresse folgt unverändert ihrem regulären Report-Lifecycle; die zugriffserteilende Report-ID wird in diesem Nachweis nicht wiederholt. Der maschinelle Readback und der gezielte Aufruf im Chrome-Viewer nutzten jeweils den normalen PDF-Tageszähler; es gab keine automatische Retry-Schleife.

Fixture-PDFs, Live-PDF, Raster, Textauszüge und Browser-Screenshots wurden nicht eingecheckt oder als CI-Artefakt veröffentlicht. Das Harness entfernt sein mkdtemp-Verzeichnis im finally; die lokalen Live-QA-Verzeichnisse wurden nach der Prüfung aus den Arbeitsverzeichnissen in den recoverable macOS-Papierkorb verschoben. Das temporäre Preview-Deployment wurde entfernt; Browser-Tabs, Preview-URL und das flüchtige ID-Binding wurden anschließend geschlossen beziehungsweise gelöscht.

Dieser Nachweis belegt robuste Mehrseiten-Darstellung und erhaltene Dokumentsemantik, aber noch keine vollständige PDF/UA-Konformität. Semantischer Tag-Baum, Artefaktmarkierung, Alternativtexte, Validator und Screenreader- Abnahme bleiben getrennt in #333 offen.