PDFlib
Seit mehr als 15 Jahren arbeitet die Sharpness Solutions GmbH aus Oldenburg mit PDFlib und entwickelt damit professionelle PDFlib-Anwendungen in PHP: Rechnungen mit ZUGFeRD, Kataloge und Datenblätter, Serien- und Transaktionsdokumente, Druckdaten für die Druckerei — gespeist aus ERP, PIM, Shop oder Datenbank. Der Unterschied zu einem schnellen PDF-Export zeigt sich erst im Betrieb: bei großen Mengen, bei der Druckerei, die ein Ausgabeprofil verlangt, beim Archiv, das PDF/A prüft, beim Screenreader, der Struktur braucht. Diese Seite erklärt, wann PDFlib die richtige Wahl ist und wann ein einfacheres Werkzeug genügt, welches PDFlib-Produkt passt und wie ein Projekt abläuft. Betrieben wird auf unseren eigenen Servern in Deutschland, mit Wartung und Updates auf neue PDFlib-Versionen; aktuell ist PDFlib 11.
Selten beginnt ein PDF-Projekt auf dem leeren Blatt. Meist gibt es einen Export, der nicht mehr reicht, eine Vorgabe von außen — Buchhaltung, Druckerei, Archiv, Barrierefreiheit — oder eine alte Anwendung, die niemand mehr anfassen will. Sechs Ausgangslagen kehren dabei immer wieder. Gemeinsam ist ihnen: Das Problem ist selten das PDF selbst, sondern der Standard, den es erfüllen muss.
Angefangen hat es mit einer HTML-Vorlage, die ein Werkzeug in ein PDF umrechnet. Inzwischen brechen Tabellen falsch über die Seite, Schriften werden ersetzt, und große Läufe dauern länger als die Nacht. Ein Export, der für den Einzelfall gebaut wurde, wird im Serienbetrieb zum Engpass.
Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland im B2B-Geschäft E-Rechnungen empfangen können, und wer Rechnungen aus dem eigenen System erzeugt, stellt sich darauf ein. Ein PDF mit einer XML-Datei daneben ist keine ZUGFeRD-Rechnung. Gefordert ist ein PDF/A-3 mit eingebetteter XML — und deren Inhalt muss zur sichtbaren Rechnung passen.
RGB-Bilder im Vierfarbdruck, fehlender Output Intent, nicht eingebettete Schriften, Sonderfarben als Näherung: Was am Bildschirm stimmt, scheitert in der Druckvorstufe. Jede Rückfrage kostet einen Tag. Druckfähige Daten nach PDF/X entstehen nicht durch nachträgliches Reparieren, sondern beim Erzeugen.
Die Artikeldaten liegen im PIM oder im Shop, der Katalog entsteht trotzdem im Layoutprogramm — von Hand übertragen, Korrekturlauf für Korrekturlauf. Jede Preisänderung bedeutet eine neue Runde. Was in einer Datenbank gepflegt wird, lässt sich auch aus ihr setzen; der Katalog wird dann zum Ausgabekanal wie der Shop.
Die Seiten sind geprüft, die Downloads nicht: Rechnungen, Bescheide, Datenblätter ohne Tags, ohne Lesereihenfolge, ohne Alternativtexte. Ein Screenreader liest dann Zeichensalat oder gar nichts. Bei erzeugten Dokumenten ist Barrierefreiheit eine Eigenschaft der Vorlage — einmal richtig gebaut, gilt sie für jedes Dokument.
Vor Jahren gebaut, auf einem alten PHP- und PDFlib-Stand, und wer sie geschrieben hat, ist nicht mehr da. Das nächste PHP-Update auf dem Server steht an, und niemand weiß, ob die Erzeugung danach noch funktioniert. Eine solche Anwendung lässt sich übernehmen, prüfen und auf PDFlib 11 heben — besser geplant als nach dem Ausfall.
PDFlib ist eine Entwicklerbibliothek der PDFlib GmbH aus München, die seit 1997 am Markt ist. Sie ist weder Layoutprogramm noch Konverter: Die Anwendung beschreibt jede Seite — Text, Grafik, Bilder, Lesezeichen, Anmerkungen —, und PDFlib schreibt daraus das PDF. Der Kern ist in C und C++ geschrieben, angesprochen wird er aus PHP, Java, .NET, Python und weiteren Sprachen; bei uns fast immer aus PHP, wo PDFlib als Erweiterung geladen wird. Das bedeutet mehr Arbeit als eine HTML-Vorlage, die ein Werkzeug in ein PDF umrechnet. Dafür ist das Ergebnis vorhersehbar: Jede Zeile steht dort, wo sie stehen soll, auf der ersten Seite wie auf der letzten.
Vier Merkmale sprechen für PDFlib. Volumen: viele Dokumente in kurzer Zeit, als Hintergrundprozess auf dem Server. Präzision: Textfluss in Rahmen und Formen, Silbentrennung, Tabellen über mehrere Seiten, OpenType-Schriften mit ihren Layout-Funktionen. Standards: PDF/A für das Archiv, PDF/X für die Druckvorstufe, PDF/UA-1 für Barrierefreiheit, PDF/VT für variable Daten, ZUGFeRD und Factur-X für die E-Rechnung. Druckqualität: CMYK, ICC-Profile, Output Intents, Sonderfarben aus PANTONE und HKS. Trifft eines dieser Merkmale auf Ihr Vorhaben zu, ist PDFlib eine ernsthafte Option. Treffen zwei zu, ist es meist die richtige.
Umgekehrt gilt: Wer im Monat eine überschaubare Zahl Dokumente mit einfachem Layout erzeugt, keinen Standard erfüllen muss und das Aussehen ohnehin aus einer Web-Vorlage übernimmt, braucht keine PDFlib-Lizenz. Dann genügt eine quelloffene HTML-zu-PDF-Lösung — und die bauen wir genauso, in derselben PHP-Anwendung, mit denselben Tests. Das sagen wir im ersten Gespräch, nicht nach dem Kauf. Kommen später Anforderungen dazu, etwa die E-Rechnung oder Druckdaten für eine Druckerei, wechselt die Erzeugung auf PDFlib, und die Datenseite der Anwendung bleibt, wie sie ist. Eine Lizenz, die nichts leistet, was Sie brauchen, ist kein Qualitätsmerkmal.
Das Basisprodukt PDFlib erzeugt PDFs von Grund auf: Seiten, Text, Grafik, Bilder aus SVG, PNG, JPEG, TIFF und weiteren Formaten, Tabellen und Textfluss. PDFlib+PDI ergänzt die PDF Import Library. Damit lassen sich vorhandene PDF-Seiten einlesen und weiterverwenden — ein Briefpapier als Hintergrund, ein Formular, das Datenblatt eines Lieferanten —, zusammenstellen, bestempeln und neu anordnen, ohne dass dabei eine PDF/A-, PDF/X- oder PDF/UA-Konformität verloren geht. Ab PDFlib+PDI ist außerdem pCOS enthalten, mit dem eine Anwendung Informationen aus PDFs abfragt. Wer Dokumente aus vorhandenen PDFs zusammensetzt, braucht PDI. Wer nur neu erzeugt, braucht es nicht.
Der PDFlib Personalization Server, kurz PPS, ist PDFlib+PDI plus Blöcke für variable Daten. In einer PDF-Vorlage werden mit dem Block Plugin für Acrobat (macOS und Windows) Bereiche festgelegt, die die Anwendung später mit Text, Bildern, SVG oder PDF-Seiten füllt; vorhandene Formularfelder lassen sich in Blöcke umwandeln. Der Vorteil liegt in der Arbeitsteilung: Die Gestaltung lebt in der Vorlage, die Logik im Code. Ändert sich das Layout, wird die Vorlage angepasst, nicht die Anwendung. Für Web-to-Print, personalisierte Werbemittel und Formulare, deren Aussehen sich öfter ändert als ihre Daten, ist PPS deshalb meist die bessere Wahl.
TET 6, das Text and Image Extraction Toolkit, arbeitet in die Gegenrichtung: Es liest Text als Unicode, Bilder und Metadaten aus vorhandenen PDFs, erkennt Tabellen und Listen und gibt das Ergebnis auf Wunsch als TETML aus, einem XML-Format — etwa für einen Suchindex oder die Weiterverarbeitung in einer Fachanwendung. Lizenziert wird jedes Produkt kommerziell, je Rechner und Betriebssystem; Entwicklungs- und Testsysteme sind inbegriffen, Support beim Hersteller gibt es optional als Jahresvertrag. Die Lizenz kaufen Sie bei der PDFlib GmbH auf Ihr Unternehmen. Wir empfehlen das kleinste Produkt, das Ihre Anforderungen trägt — wer nur Rechnungen erzeugt, braucht kein PPS.
Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland im B2B-Geschäft E-Rechnungen empfangen können. ZUGFeRD und Factur-X verbinden zwei Rechnungen in einer Datei: eine lesbare als PDF/A-3 und eine maschinenlesbare als XML, die darin eingebettet ist. PDFlib unterstützt ZUGFeRD 1.0, 2.0 und 2.1 sowie Factur-X — die komplette Erzeugung, das Anhängen der XML an vorhandene PDF/A-Dokumente und das Auslesen der XML aus eingehenden Rechnungen über pCOS. Welches ZUGFeRD-Profil Sie brauchen, bis hin zum Profil XRechnung, klären wir mit Ihrer Buchhaltung. Die eigentliche Sorgfalt gilt der Übereinstimmung: Was in der XML steht, muss in der sichtbaren Rechnung stehen, Betrag für Betrag.
Kataloge und Datenblätter entstehen aus den Daten, in denen sie ohnehin gepflegt werden: PIM, Shop, ERP oder eine eigene Datenbank. PDFlib setzt Text in Rahmen oder beliebige Formen, trennt Silben, lässt Text um Bilder fließen und baut Tabellen, die über mehrere Seiten laufen — mit Zellen, die Text, Bilder, SVG oder ganze PDF-Seiten enthalten. Schriften kommen als TrueType oder OpenType mit Layout-Funktionen, auch als WOFF und WOFF2; Fallback-Schriften fangen Zeichen ab, die der Hausschrift fehlen. Arabisch, Hebräisch, Thai und Devanagari sind abgedeckt. Ändert sich ein Preis, wird der Katalog neu erzeugt, nicht korrigiert.
Serien- und Transaktionsdokumente sind die dritte große Gruppe: Serienbriefe, Konto- und Transaktionsauszüge, Verträge, personalisiertes Werbematerial. Für variable Druckdaten gibt es PDF/VT-1, für das Archiv PDF/A-1, PDF/A-2 und PDF/A-3. Erzeugt wird als Hintergrundprozess auf dem Server, nicht auf Knopfdruck im Browser: Jeder Lauf wird protokolliert, ein abgebrochener Lauf setzt dort wieder auf, wo er stand, und jedes Dokument lässt sich auf den Datensatz zurückführen, aus dem es entstanden ist. Wer zum Monatsende einen großen Lauf verschickt, braucht diese Nachvollziehbarkeit dringender als ein schöneres Layout.
Für die Druckvorstufe erzeugt PDFlib PDF/X-3, PDF/X-4, PDF/X-4p und PDF/X-5n, mit Output Intent und ICC-Profilen, in Graustufen, RGB, CMYK oder CIE L*a*b*, mit Sonderfarben aus PANTONE und HKS und mit DeviceN. Das ist die Grundlage für Web-to-Print: Ihre Kundin gestaltet Visitenkarte, Flyer oder Schild im Browser, eine PPS-Vorlage nimmt die Eingaben auf, und Vorschau und Druckdatei entstehen aus derselben Quelle. Was am Bildschirm zu sehen war, landet so auf dem Bogen. Welches PDF/X-Format und welches Ausgabeprofil gelten, gibt die Druckerei vor — diese Vorgabe steht vor der ersten Zeile Code.
Barrierefreie PDFs nach PDF/UA-1 (ISO 14289-1) sind getaggte PDFs: Überschriften, Absätze, Listen, Tabellen und Bilder sind als Struktur ausgezeichnet, die Lesereihenfolge ist festgelegt, Bilder tragen Alternativtexte, die Sprache ist angegeben. PDFlib erzeugt die Tags für Tabellen und für Artefakte, also Inhalte ohne Bedeutung für das Vorlesen, automatisch; die übrige Struktur liefert die Anwendung. Bei erzeugten Dokumenten ist das ein Vorteil: Die Struktur wird einmal in der Vorlage gebaut und gilt für jedes Dokument, statt jedes PDF einzeln nachzubessern. Ob für Ihre Dokumente eine gesetzliche Pflicht gilt — etwa aus dem Barrierefreiheitsstärkungsgesetz (BFSG) oder, für öffentliche Stellen des Bundes, aus der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) —, bewertet im Einzelfall eine Anwältin oder ein Anwalt.
Eingehende PDFs prüft eine Anwendung mit pCOS, bevor sie sie weiterverarbeitet: Seitenzahl, Metadaten, verwendete Schriften, ICC-Profile, eingebettete Dateien. Ein Upload-Portal für Druckdaten weist eine unpassende Datei so sofort zurück, statt dass der Fehler erst in der Druckvorstufe auffällt; aus eingehenden ZUGFeRD-Rechnungen liest pCOS die XML. TET extrahiert Text und Bilder für Suchindizes und Fachanwendungen. Für alles, was wir erzeugen, gilt eine Regel: Jeder Standard wird mit unabhängigen Prüfwerkzeugen validiert, nicht nur auf das Wort der Bibliothek hin, und PDF/UA zusätzlich von Hand mit einem Screenreader. Ein PDF, das einen Standard nur behauptet, fällt bei der ersten Prüfung auf — besser bei uns als beim Empfänger.
In PHP wird PDFlib als Erweiterung geladen, die zur PHP-Version auf dem Server passen muss. Wir bauen die Erzeugung dort ein, wo die Daten liegen: in eigene PHP-Anwendungen auf Symfony oder Laminas, als TYPO3-Extension, die Datenblätter aus Datensätzen erzeugt, oder als Shopware-Plugin, das Produktdatenblätter oder Geschäftsdokumente direkt aus dem Shop heraus setzt. Die Erzeugung bekommt dabei ein eigenes Modul mit klarer Grenze — Daten hinein, PDF heraus —, damit Vorlagen und Logik getrennt testbar bleiben. Große Läufe gehen in eine Warteschlange und laufen im Hintergrund, nicht im Seitenaufruf. So bleibt die Website schnell, während nebenan der Monatslauf rechnet.
PDFlib läuft serverseitig, und damit gehört der Betrieb zum Projekt. Bei Sharpness laufen PDFlib-Anwendungen auf eigenen Proxmox-PVE-Clustern im Hetzner-Rechenzentrum Falkenstein, jede Kundenumgebung für sich; PHP-Version, PDFlib-Erweiterung, Schriften und ICC-Profile werden dort gemeinsam gepflegt. Die Wartung läuft mit Service-Level-Vereinbarung — 24, 8 oder 4 Stunden Reaktionszeit, als Monatspauschale netto; ohne Vereinbarung bearbeiten wir Anfragen innerhalb von 48 Stunden in unseren Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Rufbereitschaft außerhalb dieser Zeiten gibt es nur mit SLA. Updates auf neue PDFlib-Versionen wie PDFlib 11 testen wir mit denselben Daten in alter und neuer Fassung und vergleichen die Ergebnisse, bevor umgestellt wird.
Kalkuliert wird in Personentagen, mit getrennten Posten für Musterdokument, Vorlagen, Implementierung, Validierung und Betrieb. Die PDFlib-Lizenz ist kein Posten von uns: Sie kaufen sie beim Hersteller. Den Stundensatz und einen Preis nennen wir auf Anfrage und nach der Einordnung, nicht am Telefon. Der Quellcode gehört Ihnen und liegt in Ihrem Git-Repository, die PDFlib-Lizenz läuft auf Ihr Unternehmen. Bestehende PDFlib-Anwendungen übernehmen wir mit einer Bestandsaufnahme — PHP-Stand, PDFlib-Version, Vorlagen, Schriften, Abhängigkeiten — und heben sie danach auf ein aktuelles PHP und PDFlib 11. Betrieb und Weiterentwicklung liegen dann in einer Hand.
Ablauf
Schicken Sie uns ein Beispiel des Dokuments, das entstehen soll — als PDF, Skizze oder in ein paar Sätzen: woher die Daten kommen, wie viele Dokumente, welcher Standard, wer sie empfängt. Sie bekommen eine erste Einordnung, ob PDFlib passt, welches Produkt und wovon der Aufwand abhängt — vor dem Angebot, nicht danach. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Wir arbeiten bundesweit remote, Termine in Oldenburg und im Nordwesten nach Absprache.
Sie schildern, welche Dokumente entstehen sollen, woher die Daten kommen, in welcher Menge und welchen Standard die Empfänger verlangen. Wir sagen, ob PDFlib passt und welches Produkt — oder ob eine HTML-zu-PDF-Lösung genügt, die wir dann ebenso bauen.
Mit der voll funktionsfähigen Evaluierungsversion von PDFlib entsteht ein echtes Dokument aus echten Daten, geprüft gegen den Zielstandard. So sehen Sie das Ergebnis, bevor eine Lizenz gekauft wird. Das Musterdokument ist ein eigener, abgegrenzter Posten im Angebot.
Aus Gestaltung und Musterdokument werden Vorlagen: als Code oder, mit PPS, als PDF-Vorlage mit Blöcken aus dem Block Plugin für Acrobat. Dazu gehören Schriften mit einer Lizenz, die das Einbetten in PDFs erlaubt, und bei Druckdaten das Ausgabeprofil der Druckerei.
Gebaut wird in Ihrer PHP-Anwendung, in Symfony, als TYPO3-Extension oder als Shopware-Plugin, auf einem Testsystem, das Sie jederzeit erreichen. Die Erzeugung ist ein eigenes Modul mit Protokoll, große Läufe gehen in den Hintergrund. Der Code liegt in einem Git-Repository, das Ihnen gehört.
Jeder Dokumenttyp wird validiert: PDF/A, PDF/UA, PDF/X oder ZUGFeRD mit unabhängigen Prüfwerkzeugen. Dazu kommt die Prüfung von Hand — PDF/UA mit dem Screenreader, Druckdaten mit einem Proof der Druckerei, Rechnungen mit dem Abgleich von XML und sichtbarem Inhalt.
Die Anwendung läuft auf unseren Servern in Deutschland, gewartet mit Service-Level-Vereinbarung. Updates von PHP und PDFlib, etwa auf PDFlib 11, testen wir mit denselben Daten in alter und neuer Fassung, bevor umgestellt wird. Betrieb und Weiterentwicklung bleiben in einer Hand.
PDFlib ist eine Entwicklerbibliothek, mit der Anwendungen PDFs direkt aus Daten erzeugen — auf dem Server, ohne Layoutprogramm und ohne Umweg über HTML. Hersteller ist die PDFlib GmbH aus München, seit 1997 am Markt und 2006 Gründungsmitglied der PDF Association. Typische Einsätze sind Rechnungen mit ZUGFeRD, Kataloge und Datenblätter aus Datenbanken, Serienbriefe, Konto- und Transaktionsauszüge, personalisierte Werbemittel und Druckdaten nach PDF/X. Aktuell ist PDFlib 11. Sharpness arbeitet seit mehr als 15 Jahren mit PDFlib, fast immer aus PHP heraus.
PDFlib lohnt sich, sobald Volumen, Präzision, Standards oder Druckqualität eine Rolle spielen — vor allem, wenn mehrere davon zusammenkommen. Wer viele Dokumente erzeugt, PDF/A, PDF/X, PDF/UA oder ZUGFeRD erfüllen muss, Tabellen über viele Seiten setzt oder für die Druckerei mit Sonderfarben und Ausgabeprofilen arbeitet, ist bei PDFlib richtig. Für eine überschaubare Zahl einfacher Dokumente ohne Standardvorgabe genügt dagegen eine quelloffene HTML-zu-PDF-Lösung; die bauen wir genauso, ohne Lizenzkosten für PDFlib. Welcher Weg passt, sagen wir im ersten Gespräch.
Das hängt davon ab, ob Sie nur erzeugen, vorhandene PDFs einbeziehen, mit Vorlagen arbeiten oder Inhalte auslesen wollen. PDFlib erzeugt PDFs von Grund auf. PDFlib+PDI importiert zusätzlich vorhandene PDF-Seiten — Briefpapier, Formulare, fremde Datenblätter — und enthält pCOS für die Abfrage von PDF-Informationen. PPS ergänzt Blöcke, die in einer Vorlage mit dem Block Plugin für Acrobat angelegt und per Programm gefüllt werden; das passt zu Web-to-Print und personalisierten Dokumenten. TET 6 extrahiert Text, Bilder und Metadaten aus vorhandenen PDFs. Wir empfehlen das kleinste Produkt, das Ihre Anforderungen trägt.
Ja: PDFlib erzeugt Rechnungen nach ZUGFeRD 1.0, 2.0 und 2.1 sowie nach Factur-X, jeweils als PDF/A-3 mit eingebetteter XML. Ebenso lässt sich die XML an ein vorhandenes PDF/A-Dokument anhängen, und über pCOS liest eine Anwendung die XML aus eingehenden Rechnungen aus. Die Rechnungsdaten liefert Ihr System, etwa ERP, Shop oder Fakturierung; XML und sichtbare Rechnung entstehen aus denselben Daten, damit sie übereinstimmen. Welches Profil Sie brauchen, bis hin zum Profil XRechnung, klären wir vorab mit Ihrer Buchhaltung. Jede Rechnungsart wird vor dem Start validiert.
Barrierefreie PDFs entstehen, wenn die Anwendung beim Erzeugen die Struktur mitliefert: Überschriften, Absätze, Listen, Tabellen, Lesereihenfolge, Alternativtexte für Bilder und die Sprache des Dokuments. PDFlib schreibt daraus ein getaggtes PDF nach PDF/UA-1 und erzeugt die Tags für Tabellen und Artefakte automatisch. Weil die Struktur in der Vorlage steckt, gilt sie für jedes erzeugte Dokument — ein klarer Vorteil gegenüber dem nachträglichen Taggen einzelner Dateien. Wir validieren mit einem unabhängigen Prüfwerkzeug und testen von Hand mit einem Screenreader. Ob eine gesetzliche Pflicht besteht, klärt im Einzelfall eine Anwältin oder ein Anwalt.
Ja, Druckdaten gehören zu den Stärken von PDFlib: PDF/X-3, PDF/X-4, PDF/X-4p und PDF/X-5n, mit Output Intent, ICC-Profilen, CMYK und Sonderfarben aus PANTONE und HKS. Für Web-to-Print setzen wir meist PPS ein. Die Gestaltung liegt als PDF-Vorlage mit Blöcken vor, die Eingaben Ihrer Kundinnen und Kunden füllen sie, und Vorschau und Druckdatei entstehen aus derselben Quelle. Eingehende Druckdaten prüft die Anwendung mit pCOS, bevor sie in die Produktion gehen. Welches PDF/X-Format und welches Ausgabeprofil gelten, gibt Ihre Druckerei vor.
Ja: PDFlib wird in PHP als Erweiterung geladen und steht damit jeder PHP-Anwendung zur Verfügung, also auch Symfony, Laminas, TYPO3 und Shopware 6. Wir bauen die Erzeugung als eigenes Modul mit klarer Schnittstelle — in Ihre PHP-Anwendung, als TYPO3-Extension, die Datenblätter aus Datensätzen setzt, oder als Shopware-Plugin, das Dokumente aus dem Shop heraus erzeugt. Voraussetzung ist ein Server, auf dem die PDFlib-Erweiterung zur PHP-Version passt. Deshalb betreiben wir solche Anwendungen auf unseren eigenen Servern in Deutschland und halten PHP und PDFlib dort gemeinsam aktuell.
Die Lizenz kaufen Sie direkt bei der PDFlib GmbH, auf Ihr Unternehmen; sie gilt je Rechner und Betriebssystem, Entwicklungs- und Testsysteme sind inbegriffen, Herstellersupport ist optional jährlich buchbar. Die Entwicklung kalkulieren wir in Personentagen, mit getrennten Posten für Musterdokument, Vorlagen, Implementierung, Validierung und Betrieb. Der Aufwand hängt an der Zahl der Dokumenttypen, an den Datenquellen und am Standard, den die Dokumente erfüllen müssen — weniger an der Seitenzahl. Den Stundensatz und einen Preis nennen wir auf Anfrage, nach der Einordnung Ihres Vorhabens.
Die Anwendung läuft auf unseren eigenen Servern in Deutschland, auf Proxmox-PVE-Clustern im Hetzner-Rechenzentrum Falkenstein, und Sharpness wartet sie mit Service-Level-Vereinbarung. Die Stufen reichen von 24 über 8 bis 4 Stunden Reaktionszeit, als Monatspauschale netto; ohne Vereinbarung bearbeiten wir Anfragen innerhalb von 48 Stunden in unseren Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Rufbereitschaft gibt es nur mit SLA. Der Quellcode gehört Ihnen und liegt in Ihrem Git-Repository, die PDFlib-Lizenz läuft auf Ihr Unternehmen.
Ja. Am Anfang steht eine Bestandsaufnahme: PHP-Stand, PDFlib-Version, Vorlagen, Schriften, Datenquellen und die Frage, welche Dokumente die Anwendung heute tatsächlich erzeugt. Danach heben wir sie auf eine aktuelle PHP-Version und auf PDFlib 11, die derzeit aktuelle Version. Damit dabei nichts unbemerkt kippt, laufen dieselben Testdaten durch alte und neue Fassung, und die Ergebnisse werden verglichen — Seite für Seite und bei Standards wie PDF/A oder ZUGFeRD zusätzlich mit Validierung. Anschließend übernehmen wir Betrieb und Wartung mit SLA auf unseren Servern in Deutschland.
Am meisten helfen drei Dinge: ein Beispieldokument, Zugriff auf die Datenquelle und die Vorgaben der Empfänger. Das Beispiel darf eine bisherige Rechnung, ein Katalogauszug oder eine Skizze sein. Die Datenquelle ist das ERP, das PIM, der Shop oder eine Datenbank — mit einem Satz realistischer Testdaten, einschließlich der unbequemen Fälle wie langer Namen oder leerer Felder. Vorgaben sind etwa das ZUGFeRD-Profil Ihrer Buchhaltung oder das PDF/X-Format und Ausgabeprofil Ihrer Druckerei. Dazu kommen Ihre Hausschriften, mit einer Lizenz, die das Einbetten in PDFs erlaubt.
Anfrage
Ein paar Sätze genügen: welche Dokumente, aus welchen Daten, für welche Empfänger. Wir melden uns mit Rückfragen und einer ersten Einordnung — bevor über ein Angebot gesprochen wird.