Duplexscan zusammenführen — Vorder- und Rückseiten-PDF verbinden online

Wer einen Dokumentenstapel mit einem automatischen Dokumenteneinzug (ADE) scannt, bekommt zwei Dateien statt einer: im ersten Lauf alle Vorderseiten, im zweiten alle Rückseiten. Die meisten Online-Dienste verstehen diese Struktur nicht. Der Duplex-Scan-Organizer in pdfredX löst genau das — vollständig im Browser, ohne dass Ihre Dateien das Gerät verlassen.

Schritt 01. Dateien laden

Öffnen Sie pdfredX und ziehen Sie beide PDF-Dateien in den Upload-Bereich — oder wählen Sie sie über den Datei-Dialog. Laden Sie die Dateien in der richtigen Reihenfolge: zuerst Vorderseiten (ungerade Seiten, Stapel face-up), dann Rückseiten (gerade Seiten, umgekehrter Stapel). Die Reihenfolge ist entscheidend: Sie legt fest, welche Datei der Algorithmus als Ausgangspunkt verwendet.

Nach dem Upload zeigt die Galerie sofort eine Farbmarkierung: eine grüne Leiste auf Karten kennzeichnet Vorderseiten, eine blaue Rückseiten. Das ist kein Designelement, sondern spiegelt die internen Schlüssel pdfSrcKey: 'duplex:front:...' und 'duplex:back:...' im items[]-Array wider — exakt die Schlüssel, die der Verschachtelungsalgorithmus beim Zusammenführen liest. Sind die Farben vertauscht, wurden die Dateien in falscher Reihenfolge geladen: einfach entfernen und neu hochladen.

Schritt 02. Duplex-Modus konfigurieren

Klicken Sie auf die Schaltfläche „Duplex-Scan" in der Werkzeugleiste. Das öffnet das Seitenpanel #DM mit drei Steuerelementen.

Dateizuweisung. Zwei Dropdown-Menüs: Vorderseite und Rückseite. Wurden die Dateien in der richtigen Reihenfolge geladen, ist die Zuweisung bereits automatisch korrekt gesetzt. Falls nicht — manuell korrigieren, das dauert fünf Sekunden.

Rückseite umkehren (dmReverseBack). Der wichtigste Schalter. Die meisten ADE-Scanner kehren den Papierstapel nach dem ersten Lauf um — die Rückseiten werden in umgekehrter Reihenfolge gescannt: das letzte Blatt kommt zuerst heraus. Ohne diese Korrektur bricht die Verschachtelung: Vorne₁ → Hinten₅ → Vorne₂ → Hinten₄ statt Vorne₁ → Hinten₁ → Vorne₂ → Hinten₂.

Mit aktivierter Umkehrung liest der Algorithmus das Rückseiten-Array von rechts nach links: Index backLen - 1 - i statt i. Mathematisch eine einzige Zeile — aber der Unterschied zwischen einem unlesbaren Dokument und der richtigen Seitenfolge. Ob Ihr Scanner diesen Schalter benötigt: Aktivieren Sie ihn und scrollen Sie durch die Galerievorschau. Ist Seite 2 jetzt die Rückseite von Seite 1 — perfekt. Falls nicht — Schalter deaktivieren.

Live-Vorschau der Seitenreihenfolge. Die Galerie aktualisiert die Kartenreihenfolge in Echtzeit bei jeder Einstellungsänderung. Sie können alle Seiten durchscrollen und die Verschachtelung prüfen, bevor Sie die endgültige Zusammenführung anstoßen.

Schritt 03. Zusammenführen und exportieren

Klicken Sie auf „Anwenden". Der Algorithmus baut das items[]-Array in Millisekunden neu auf — reine Index-Umsortierung, kein erneutes Rendern. Die Galerie zeigt sofort die finale Reihenfolge: Vorne₁ / Hinten₁ / Vorne₂ / Hinten₂ / ...

Direktstart über die Feature-Seite. Sind Sie über die Duplex-Scan-Landingpage zu pdfredX gekommen, hat der Browser bereits einen Schritt für Sie erledigt. js/features-landing.js schreibt openTool=duplex in den sessionStorage und leitet zur Hauptseite weiter. Beim Laden liest die Anwendung diesen Parameter und öffnet automatisch das Duplex-Panel — ohne Suche in der Werkzeugleiste. Einfach Dateien hineinziehen und den Umkehr-Schalter einstellen.

Export. Klicken Sie auf „PDF herunterladen". jsPDF 2.5.1 iteriert über das neu sortierte items[]-Array: Pro Seite wird addImage(editUrl, ...) aufgerufen, die A4-Ausrichtung wird automatisch aus den Bildproportionen ermittelt. Die Datei wird vollständig im Browserspeicher zusammengestellt und direkt heruntergeladen — kein Server-Upload, keine Warteschlange, kein Warten auf eine externe Antwort.

So funktioniert es unter der Haube

Jedes hochgeladene PDF wird seitenweise durch PDF.js 3.11.174 gerendert. Jede Seite wird als gerasterte dataURL im Canvas gespeichert und ins items[]-Array mit Quellschlüssel eingetragen. Zwei PDFs erzeugen zwei getrennte Arrays mit unterschiedlichen pdfSrcKey-Werten.

Bei der Duplex-Zusammenführung wird nichts neu gerendert. Der Algorithmus baut ein neues Index-Array: abwechselnd items[i] aus dem Vorderseiten-Array und items[j] aus dem Rückseiten-Array — wobei j = i oder j = backLen - 1 - i je nach dmReverseBack-Flag. Die gesamte Operation ist JavaScript-Array-Manipulation ohne schwere Render-Pipeline. Bei einem 200-seitigen Dokument dauert das unter 100 Millisekunden.

Bekannte Einschränkungen

Nur gerasterte Ausgabe. PDF.js rendert Seiten in Canvas — das Ergebnis sind Rasterbilder, kein Vektor-Text. Text im fertigen PDF lässt sich nicht als Text markieren. Falls Sie eine aktive Textebene benötigen, nutzen Sie danach das OCR-Bereichswerkzeug auf den entsprechenden Seiten.

Performance auf Mobilgeräten. Dokumente mit mehr als 80–100 Seiten rendern auf schwachen Smartphones spürbar langsamer: PDF.js hält jede Seite als ImageData im Speicher. Auf dem Desktop ist das kaum merklich.

Unterschiedliche Scan-Auflösungen. Wurden Vorder- und Rückseiten mit unterschiedlichem DPI oder in verschiedener Ausrichtung gescannt, funktioniert die Verschachtelung korrekt — aber das Ergebnis wirkt optisch inkonsistent. Korrigieren Sie die Ausrichtung mit dem Drehen-Werkzeug vor der Duplex-Zusammenführung.

Browserspeicher-Limit. Praktische Obergrenze: etwa 200–300 Seiten pro Tab, je nach verfügbarem RAM. Darüber hinaus beginnt Chrome den Cache auszulagern, was das erneute Rendern verlangsamt.

Wenn Sie ein Buch im Aufklapp-Modus gescannt haben — jede Seite enthält zwei Blätter — ist das ein anderer Arbeitsablauf. Dafür gibt es eine separate Anleitung: PDF-Buchseiten aus Doppelseiten aufteilen.

Jetzt ausprobieren — pdfredx.com, ohne Registrierung, Ihre Dateien bleiben bei Ihnen.

Sie scannen einen Arbeitsvertrag, eine Personalakte mit Ausweiskopie oder einen Abtretungsvertrag mit vertraulichen Konditionen. Der Scanner liefert zwei Dateien — Vorderseiten und Rückseiten. Um daraus ein korrekt sortiertes Dokument zu machen, brauchen Sie ein Werkzeug. Sie öffnen den ersten Online-Dienst, den die Suche ausspuckt, klicken auf „Hochladen" — und in diesem Moment ist Ihr Dokument nicht mehr vollständig in Ihren Händen.

Was genau in diesem Moment passiert und warum die Verarbeitung von PDF-Dateien direkt im Browser kein Marketingversprechen ist, sondern eine architektonische Entscheidung mit konkreten datenschutzrechtlichen Konsequenzen — das beschreiben wir hier.

Wohin Ihre Dokumente bei Standard-Clouddiensten wirklich fliegen

Wenn Sie eine Datei bei einem typischen Online-PDF-Dienst hochladen, läuft Folgendes ab:

Die Datei verlässt Ihr Gerät und landet auf einem Fremdserver. Sie wird physisch in ein Rechenzentrum übertragen — möglicherweise in einem anderen Land, unter einer anderen Rechtsordnung, auf Infrastruktur, über die Sie keine Kontrolle haben. Nach Art. 5 Abs. 1 lit. f DSGVO muss die Verarbeitung personenbezogener Daten „angemessene Sicherheit" gewährleisten. Bei einer Übertragung an einen Drittdienst ohne geprüften Auftragsverarbeitungsvertrag (AVV) ist das schlicht nicht sichergestellt.

Die Datei wird für die Verarbeitung zwischengespeichert. Der Dienst schreibt Ihre Datei in temporären Speicher. Er verspricht, sie nach einer Stunde, einem Tag oder einer Woche zu löschen — aber Sie können das nicht überprüfen. Sie vertrauen einer Datenschutzerklärung, die die Juristen desselben Dienstes verfasst haben.

Metadaten landen in Serverprotokollen. Uhrzeit des Uploads, Ihre IP-Adresse, Dateiname, Dateigröße, Browser-Fingerprint — all das wird in serverseitigen Logs festgehalten. Logs werden deutlich länger aufbewahrt als die Dateien selbst und wandern durch Backup-Systeme, denen Sie nie zugestimmt haben.

Der Dienst kann Ihre Inhalte verwenden. Manche Plattformen behalten sich in ihren AGB ausdrücklich vor, hochgeladene Inhalte zur Produktverbesserung oder zum Training von Algorithmen zu nutzen. Wenn Sie die AGB nicht gelesen haben — haben Sie zugestimmt.

Eine Datenpanne legt Ihre Dokumente offen. Datenschutzvorfälle passieren regelmäßig. Wenn Ihre Datei zum Zeitpunkt eines Vorfalls im Cache des Dienstes lag, kann sie in einem Datendump auftauchen. Personalabteilungen, die mit Gehaltsabrechnungen, Arbeitsverträgen und Ausweiskopien arbeiten, tragen hier eine besondere Verantwortung gegenüber ihren Mitarbeitenden — und gegenüber der DSGVO.

Für Rechtsanwälte bedeutet das: Mandantengeheimnisse auf fremder Infrastruktur. Für HR-Fachkräfte: eine potenzielle Verletzung von Betroffenenrechten nach Art. 15–22 DSGVO. Für Steuerberater: vertrauliche Finanzdaten, die die Kanzlei nie verlassen sollten.

Vollständige Isolation im Browser: Wie pdfredX Ihre Dateien verarbeitet

pdfredX lädt Ihre Dateien auf keinen Server hoch. Das ist keine Aussage aus dem Impressum — es ist eine Konsequenz der Anwendungsarchitektur, die Sie selbst überprüfen können.

PDF.js rendert Ihre Datei direkt im Browser-Tab. Die Bibliothek PDF.js 3.11.174 läuft innerhalb Ihrer geöffneten Browser-Registerkarte und liest die PDF-Datei lokal über die FileReader API des Browsers. Dabei findet kein Netzwerkaufruf statt. Die Datei verlässt Ihr Gerät nicht.

Seitendaten bleiben im Arbeitsspeicher der Registerkarte. Jede gerenderte Seite wird als dataURL — eine kodierte Bildzeichenkette — im items[]-Array im RAM des Browsers gespeichert. Dieses Array existiert ausschließlich innerhalb Ihrer geöffneten Registerkarte. Schließen Sie die Registerkarte, sind die Daten weg.

sessionStorage enthält nur Interface-Zustand. Werkzeugeinstellungen, Panel-Konfiguration, der openTool-Parameter — all das liegt im sessionStorage, der im Browser isoliert ist und niemals an einen Server übertragen wird. Das ist ein Browser-Sicherheitsstandard, keine Eigenentwicklung unsererseits.

jsPDF erstellt das fertige Dokument auf dem Client. Wenn Sie auf „PDF herunterladen" klicken, setzt jsPDF 2.5.1 das Dokument im Speicher der Registerkarte zusammen und übergibt es direkt dem Browser zum Download. Es landet in Ihrem Download-Ordner — ohne Zwischenstopp auf einem Drittserver.

Die Anwendung funktioniert vollständig offline nach dem Seitenaufruf. Wenn Sie die Isolation selbst prüfen möchten: Öffnen Sie pdfredX, laden Sie Ihre Dateien, trennen Sie dann die Internetverbindung. Das Werkzeug läuft weiter, weil die gesamte Verarbeitung lokal stattfindet. Die Netzwerkverbindung wird nur zum initialen Laden der Anwendung benötigt.

Datenschutzkonforme Duplex-Verarbeitung: Schritt für Schritt

01. Dateien laden

Ziehen Sie beide PDFs — Vorderseiten und Rückseiten — in die Upload-Zone auf pdfredx.com. Die FileReader API des Browsers liest die Dateien lokal. Sie verlassen das Gerät weder in diesem noch in einem der folgenden Schritte. Die Seiten erscheinen sofort nach dem lokalen Rendering in der Galerie.

02. Seitenreihenfolge konfigurieren

Öffnen Sie das Duplex-Scan-Panel. Weisen Sie zu, welche Datei die Vorderseiten enthält und welche die Rückseiten. Aktivieren Sie bei Bedarf die Umkehrung der Rückseiten (dmReverseBack) — für ADE-Scanner, die den Stapel zwischen den Läufen umkehren. Die Galerie zeigt eine Live-Vorschau der resultierenden Seitenreihenfolge. Alles geschieht im Speicher der Registerkarte.

03. Exportieren und schließen

Klicken Sie auf „Anwenden", dann auf „PDF herunterladen". jsPDF erstellt das Dokument lokal und übergibt es dem Browser zum Download. Nach dem Schließen der Registerkarte werden alle Dateidaten automatisch vernichtet — im sessionStorage und im Browserspeicher bleibt nichts zurück.

Was wir nicht garantieren können — ein ehrlicher technischer Vorbehalt

Die clientseitige Architektur schützt Ihr Dokument davor, an externe Server übertragen zu werden. Sie ist jedoch kein vollständiger Schutz gegen alle denkbaren Bedrohungen — und das offen zu kommunizieren ist uns wichtiger als ein falsches Sicherheitsgefühl zu erzeugen.

Schadsoftware oder ein Keylogger auf Ihrem Gerät. Wenn Ihr Rechner bereits kompromittiert ist, kann die Schadsoftware Dateien vom Datenträger lesen oder Daten auf Betriebssystemebene abfangen. Eine Browser-Anwendung ist dagegen machtlos — sie hat keinen Einblick in das, was außerhalb der Browser-Sandbox läuft.

Browser-Erweiterungen mit weitreichenden Berechtigungen. Manche Erweiterungen fordern die Berechtigung, Inhalte aller Registerkarten zu lesen. Wenn eine solche Erweiterung aktiv ist, kann sie Daten im DOM der Seite einsehen. Arbeiten Sie mit vertraulichen Dokumenten in einem Browser-Profil ohne Dritterweiterungen oder im privaten Modus.

Die heruntergeladene Datei auf Ihrem lokalen Datenträger. Sobald das PDF in Ihrem Download-Ordner liegt, liegt seine Sicherheit in Ihrer Verantwortung: Festplattenverschlüsselung, Zugriffsrechte, Aufbewahrungsrichtlinien.

Der Verlauf des Browser-Besuchs. Ihr Browser protokolliert die aufgerufene URL. Das Dokument selbst wird nirgendwo außerhalb Ihres Geräts gespeichert, aber der Besuch der Seite schon. Nutzen Sie den privaten Modus, wenn das für Sie relevant ist.

Transparenz über diese Grenzen halten wir für einen Teil seriöser Software-Entwicklung — nicht für ein Argument gegen die Nutzung.

Verarbeiten Sie Ihre Duplex-Scans ohne Server-Upload — pdfredx.com, ohne Registrierung, ohne Abonnement.

Als ich das Duplex-Modul in pdfredX zu entwerfen begann, sah die Aufgabe täuschend einfach aus: zwei Arrays von Seiten nehmen und abwechselnd zusammenführen. In der Praxis steckt die eigentliche Ingenieursarbeit in den Details — im Format der Seitenspeicherung, im Speichermanagement, im Umgang mit dem nicht-standardisierten Verhalten von ADE-Scannern und den harten Grenzen des Browser-Runtimes.

Dieser Artikel analysiert die Architekturentscheidungen hinter dem duplex-Werkzeug von pdfredX: Warum wir uns für die PDF.js + jsPDF-Kombination entschieden haben, wie der Index-Permutationsalgorithmus aufgebaut ist, wie dmReverseBack den Traversierungsschritt von i zu backLen - 1 - i verändert — und wo die Performance auf echten Geräten tatsächlich an ihre Grenzen stößt.

Der Architekturelle Kernkonflikt: Was „Zwei PDFs zusammenführen" im Browser wirklich bedeutet

Serverseitig ist die Aufgabe trivial: Zwei Dateien per HTTP empfangen, ihre PDF-Struktur parsen, Seiten über eine Bibliothek wie PyMuPDF oder iTextSharp umsortieren, Ergebnis zurückgeben. Der Browser setzt andere Rahmenbedingungen.

Warum sich die PDF-Struktur im Client nicht direkt parsen lässt. Das PDF-Format ist ein komplexer Binär-Graph: Kreuzreferenztabellen (xref), komprimierte Objekt-Streams, Schriften mit Substitutions-Maps, ICC-Profile, die in ColorSpace-Dictionaries eingebettet sind. Diese Struktur in JavaScript ohne Server-Backend zu lesen bedeutet entweder, einen vollständigen PDF-Parser in den Browser zu laden — schwerfällig, fehleranfällig bei beschädigten Dateien — oder mit einer Rasterdarstellung zu arbeiten: Seiten zuerst in Canvas rendern, dann mit Pixeldaten und dataURL-Strings operieren.

Die Entscheidung für Raster ist ein bewusster Kompromiss. PDF.js 3.11.174 ist der Industriestandard für das Rendering von PDFs in Canvas. Es verarbeitet 99 % aller realen Dateien korrekt — einschließlich PDFs mit digitalen Signaturen, optionalen Inhaltsebenen und nicht standardkonformen Schriftcodierungen. Der Preis: Die Textebene des Originaldokuments geht verloren. Jede Seite wird zu einem Bild. Für den Duplex-Scan-Anwendungsfall — wo die Quelldateien bereits Scans und damit ab Beginn Raster sind — ist das ein akzeptabler Kompromiss.

Warum jsPDF statt pdf-lib. pdf-lib erlaubt die Arbeit mit der PDF-Struktur ohne Rasterisierung, was theoretisch die Textebene erhält. In der Praxis war die Stabilität auf realen gescannten Dateien mit nicht-standardisierten Metadaten niedriger als die der PDF.js → Canvas → jsPDF-Pipeline. Der zusätzliche Rasterisierungsschritt kostet, aber die Pipeline verhält sich für Dateien beliebiger Herkunft vorhersagbar.

Tiefenanalyse: Algorithmus-Implementierung

Seitenspeicherung: Das items[]-Array

Jede hochgeladene PDF wird seitenweise durch PDF.js gerendert. Das Rendering erfolgt in lowerCanvasEl — die untere Canvas-Schicht der Fabric.js-Instanz, die im unanotierten Modus als direkte Arbeitsoberfläche fungiert. Das Render-Ergebnis jeder Seite wird via canvas.toDataURL('image/jpeg', 0.92) in eine dataURL konvertiert und in das gemeinsame items[]-Array gepusht.

Jedes Element des Arrays enthält:

{
  id:        string,       // eindeutiger Bezeichner, z.B. 'pdf-001-page-3'
  editUrl:   string,       // dataURL des aktuellen Seitenzustands
  origUrl:   string,       // dataURL des Originals — mutiert nie
  pdfSrcKey: string,       // 'duplex:front:dateiname.pdf' oder 'duplex:back:dateiname.pdf'
  fromPdf:   true,
  isEdited:  boolean
}

Das Feld pdfSrcKey mit dem Präfix duplex:front: oder duplex:back: ermöglicht es dem Assembly-Algorithmus, die Herkunft jeder Seite eindeutig zu identifizieren und zwei separate Teilarrays für die Verschachtelung aufzubauen.

Der Index-Permutationsalgorithmus

Nach dem Laden beider PDFs liegen zwei Teilarrays vor. Wir nennen sie F (Vorderseiten, Länge fLen) und B (Rückseiten, Länge bLen). Der Algorithmus baut ein neues Ergebnis-Array R.

Basisfall — Umkehrung deaktiviert:

for (let i = 0; i < Math.max(fLen, bLen); i++) {
  if (i < fLen) R.push(F[i]);
  if (i < bLen) R.push(B[i]);
}
// Ergebnis: F[0], B[0], F[1], B[1], F[2], B[2], ...

Mit aktiviertem dmReverseBack:

for (let i = 0; i < Math.max(fLen, bLen); i++) {
  if (i < fLen) R.push(F[i]);
  const j = bLen - 1 - i;           // Rückseiten-Array von rechts nach links traversieren
  if (j >= 0) R.push(B[j]);
}
// Ergebnis: F[0], B[bLen-1], F[1], B[bLen-2], F[2], B[bLen-3], ...

Genau das passiert, wenn ein ADE den Papierstapel zwischen den Läufen umkehrt: Das physisch letzte Blatt im Stapel wird zur ersten gescannten Rückseite. Ohne die Indexumkehrung zu j = bLen - 1 - i wird jede Vorderseite der falschen Rückseite zugeordnet.

Zu beachten: die Schranke Math.max(fLen, bLen) — der Algorithmus behandelt korrekt asymmetrische Fälle, in denen Vorder- und Rückseiten-Arrays unterschiedlich viele Elemente enthalten: ein heruntergefallenes Blatt beim Scannen, ein einseitiges Dokument im Stapel. Seiten ohne Gegenstück aus dem längeren Array werden am Ende der Ergebnisliste ohne Partner angehängt.

Finale Assembly via jsPDF

Nach der Indexpermutation ist items[] umsortiert — aber es wurde nichts neu gerendert. Die Permutation war reine JavaScript-Referenzmanipulation. Die eigentlichen Seitenrenders fanden beim initialen Datei-Upload statt.

Wenn der Benutzer auf „PDF herunterladen" klickt, läuft makePDF():

const doc = new jsPDF({ orientation: 'portrait', unit: 'mm', format: 'a4' });
for (const [idx, item] of items.entries()) {
  const { w, h } = imgDims(item.editUrl);           // Bildproportionen auslesen
  const orient = w > h ? 'landscape' : 'portrait';  // Ausrichtung automatisch erkennen
  if (idx > 0) doc.addPage([210, 297], orient);
  doc.addImage(item.editUrl, 'JPEG', 0, 0, 210, 297);
}
doc.save('output.pdf');

Das entscheidende Detail: imgDims wird für jede Seite unabhängig aufgerufen. Das ist wichtig für Dokumente mit gemischter Ausrichtung — Vertragstext im Hochformat, Anhänge im Querformat — was in realen Scan-Workflows häufig vorkommt.

Performance-Kompromisse und Browser-Arbeitsspeichergrenzen

Warum Raster-Speicherung teuer ist

Jede Seite wird als JPEG-dataURL gespeichert. Für ein A4-Blatt, das mit 150 DPI gescannt wurde: - Auflösung: 1240 × 1754 Pixel - JPEG mit Quality 0.92: ~300–600 KB pro Seite, je nach Inhaltsdichte - Dekodiertes In-Memory-Bitmap für Canvas-Operationen: 1240 × 1754 × 4 Byte (RGBA) ≈ 8,7 MB pro Seite

Bei einem 100-seitigen Dokument können dekodierte Bitmaps allein ~870 MB belegen. Chrome begrenzt den Tab-Arbeitsspeicher auf ca. 2–4 GB, abhängig von Version und Systemressourcen. Nähert sich der Tab dieser Grenze, beginnt der Browser, inaktive Objekte aus dem Speicher auszulagern — was beim Zurückscrollen durch die Galerie Re-Renders auslöst.

In der Praxis ergeben sich drei Performance-Zonen:

Warum kein Web Worker für das Rendering

Der naheliegende nächste Schritt wäre, das PDF.js-Rendering in einen Web Worker auszulagern, um den Main Thread zu entlasten. Das Problem: Die Canvas API ist in einem Worker nicht direkt verfügbar — nur über OffscreenCanvas, dessen Safari-Unterstützung zum Implementierungszeitpunkt instabil war. ImageData zwischen Worker und Main Thread via postMessage mit Transferable-Objekten zu übertragen erzeugt Pro-Seite-Overhead, der den Threading-Vorteil teilweise aufhebt. Für die aktuellen Dokumentenvolumina rechtfertigt der UX-Gewinn nicht die Implementierungskomplexität. Das ist anerkannte technische Schuld.

Warum jsPDF das gesamte Dokument im Arbeitsspeicher hält

jsPDF assembliert das vollständige Dokument im Arbeitsspeicher, bevor doc.save() aufgerufen wird. Bei Dokumenten mit 200+ Seiten bedeutet das, dass im Spitzenlastmoment — während des Exports — gleichzeitig dekodierte Seiten-Bitmaps, jsPDFs interne Byte-Puffer und das finale PDF-Blob im Speicher liegen. Der Arbeitsspeicher-Peak beim Export kann 2–3× höher sein als beim Galerie-Browsing. Streaming-Export via WritableStream + TransformStream steht für die nächste Version auf dem Plan.

Was wir zu verbessern planen

OffscreenCanvas + Worker für das Rendering. Sobald Safaris Unterstützung stabil ist — das ist die erste Priorität, um den Main-Thread-Druck auf mobilen Geräten zu reduzieren.

Streaming-Export via WritableStream. Würde den Export von Dokumenten mit 500+ Seiten ohne den aktuellen Arbeitsspeicher-Spitzenlast-Spike ermöglichen.

LRU-Cache für dekodierte Bitmaps. Nur die letzten N Seiten vollständig dekodiert im Speicher halten; den Rest als komprimierte dataURL speichern. Würde den Peak-Speicherverbrauch um etwa eine Größenordnung reduzieren.

Wenn Sie die Duplex-Pipeline selbst unter Last testen möchten — laden Sie zwei echte mehrseitige Scans auf pdfredx.com. Keine Registrierung, kein Upload auf fremde Server.