PDFlib
Sharpness Solutions GmbH in Oldenburg has been working with PDFlib for more than 15 years and builds professional PDFlib applications in PHP: ZUGFeRD e-invoices, catalogues and data sheets, mail-merge and transactional documents, print-ready files — fed from ERP, PIM, shop or database. The difference from a quick PDF export shows in day-to-day operation: with large volumes, with a printer who insists on an output profile, with an archive that checks for PDF/A, with a screen reader that needs structure. This page explains when PDFlib is the right choice and when a simpler tool will do, which PDFlib product fits and how a project runs. It all runs on our own servers in Germany, with maintenance and updates to new PDFlib versions; the current one is PDFlib 11.
A PDF project rarely starts with a blank page. There is usually an export that no longer copes, a requirement from outside — accounts, the printer, the archive, accessibility — or an old application nobody wants to touch. Six starting points come up again and again. What they share: the problem is seldom the PDF itself, but the standard it has to meet.
It started with an HTML template that a tool converts into a PDF. Now tables break badly across pages, fonts get substituted, and large runs take longer than the night. An export built for the odd document becomes a bottleneck once it has to produce documents in series.
Since 1 January 2025, businesses in Germany have had to be able to receive e-invoices in B2B trade, and anyone generating invoices from their own system is preparing for it. A PDF with an XML file next to it is not a ZUGFeRD invoice. What is required is a PDF/A-3 with the XML embedded — and its content has to match the visible invoice.
RGB images in a four-colour job, a missing output intent, fonts not embedded, spot colours approximated: what looks right on screen fails in prepress. Every query costs a day. Print-ready PDF/X files are not produced by repairing them afterwards, but at the moment they are generated.
The product data sits in the PIM or the shop, yet the catalogue is still built in a layout program — copied across by hand, one proof round after another. Every price change means another round. What is maintained in a database can also be typeset from it; the catalogue then becomes an output channel, just like the shop.
The pages have been audited, the downloads have not: invoices, official notices and data sheets without tags, without reading order, without alternative text. A screen reader then reads gibberish or nothing at all. For generated documents, accessibility is a property of the template — built correctly once, it applies to every document.
Built years ago on an old PHP and PDFlib version, and whoever wrote it is no longer around. The next PHP update on the server is due, and nobody knows whether document generation will still work afterwards. An application like this can be taken over, reviewed and brought up to PDFlib 11 — better as a plan than after an outage.
PDFlib is a developer library from PDFlib GmbH in Munich, on the market since 1997. It is neither a layout program nor a converter: the application describes each page — text, graphics, images, bookmarks, annotations — and PDFlib writes the PDF from that. The core is written in C and C++ and is called from PHP, Java, .NET, Python and other languages; in our case almost always from PHP, where PDFlib is loaded as an extension. That is more work than an HTML template that a tool converts into a PDF. In return, the result is predictable: every line sits where it should, on the first page as on the last.
Four characteristics point to PDFlib. Volume: many documents in a short time, as a background process on the server. Precision: text flowing into frames and shapes, hyphenation, tables spanning several pages, OpenType fonts with their layout features. Standards: PDF/A for archiving, PDF/X for prepress, PDF/UA-1 for accessibility, PDF/VT for variable data, ZUGFeRD and Factur-X for e-invoicing. Print quality: CMYK, ICC profiles, output intents, PANTONE and HKS spot colours. If one of these applies to your project, PDFlib is a serious option. If two apply, it is usually the right one.
The reverse also holds: if you produce a manageable number of documents a month with a simple layout, have no standard to meet and take the look from a web template anyway, you do not need a PDFlib licence. An open-source HTML-to-PDF solution will do — and we build that just as well, in the same PHP application, with the same tests. We say so in the first conversation, not after the purchase. If requirements are added later, such as e-invoicing or print data for a printer, generation moves to PDFlib while the data side of the application stays as it is. A licence that does nothing you need is not a mark of quality.
The base product, PDFlib, creates PDFs from scratch: pages, text, graphics, images from SVG, PNG, JPEG, TIFF and other formats, tables and text flow. PDFlib+PDI adds the PDF Import Library. It reads existing PDF pages and reuses them — letterhead as a background, a form, a supplier’s data sheet — combining, stamping and rearranging them without losing PDF/A, PDF/X or PDF/UA conformance along the way. From PDFlib+PDI upwards, pCOS is included as well, which lets an application query information from PDFs. If you assemble documents from existing PDFs, you need PDI. If you only create new ones, you do not.
The PDFlib Personalization Server, PPS for short, is PDFlib+PDI plus blocks for variable data. In a PDF template, the Block Plugin for Acrobat (macOS and Windows) is used to define areas that the application later fills with text, images, SVG or PDF pages; existing form fields can be converted into blocks. The advantage lies in the division of labour: the design lives in the template, the logic in the code. If the layout changes, the template is adjusted, not the application. For web-to-print, personalised marketing material and forms whose look changes more often than their data, PPS is therefore usually the better choice.
TET 6, the Text and Image Extraction Toolkit, works in the opposite direction: it reads text as Unicode, images and metadata from existing PDFs, recognises tables and lists and, if required, outputs the result as TETML, an XML format — for a search index, say, or for further processing in a business application. Each product is licensed commercially, per machine and operating system; development and test systems are included, and support from the manufacturer is available as an optional annual contract. You buy the licence from PDFlib GmbH in your company’s name. We recommend the smallest product that covers your requirements — if you only generate invoices, you do not need PPS.
Since 1 January 2025, businesses in Germany have had to be able to receive e-invoices in B2B trade. ZUGFeRD, the German hybrid e-invoice format, and Factur-X combine two invoices in one file: a human-readable one as PDF/A-3 and a machine-readable one as XML embedded in it. PDFlib supports ZUGFeRD 1.0, 2.0 and 2.1 as well as Factur-X — complete generation, attaching the XML to existing PDF/A documents and reading the XML from incoming invoices via pCOS. Which ZUGFeRD profile you need, up to and including the XRechnung profile, we settle with your accounts department. The real care goes into consistency: what is in the XML has to be in the visible invoice, amount for amount.
Catalogues and data sheets are generated from the data in which they are maintained anyway: PIM, shop, ERP or a database of your own. PDFlib sets text in frames or arbitrary shapes, hyphenates, flows text around images and builds tables that run over several pages — with cells holding text, images, SVG or entire PDF pages. Fonts come as TrueType or OpenType with layout features, as well as WOFF and WOFF2; fallback fonts catch characters missing from the house typeface. Arabic, Hebrew, Thai and Devanagari are covered. When a price changes, the catalogue is generated again, not corrected.
Mail-merge and transactional documents are the third large group: personalised letters, account and transaction statements, contracts, personalised marketing material. For variable print data there is PDF/VT-1, for archiving PDF/A-1, PDF/A-2 and PDF/A-3. Generation runs as a background process on the server, not when a user clicks a button: every run is logged, an interrupted run resumes where it stopped, and every document can be traced back to the record it came from. Anyone sending out a large run at the end of the month needs that traceability more urgently than a prettier layout.
For prepress, PDFlib generates PDF/X-3, PDF/X-4, PDF/X-4p and PDF/X-5n, with output intent and ICC profiles, in greyscale, RGB, CMYK or CIE L*a*b*, with PANTONE and HKS spot colours and with DeviceN. That is the basis for web-to-print: your customer designs a business card, flyer or sign in the browser, a PPS template takes the input, and preview and print file come from the same source. What was on screen ends up on the sheet. Which PDF/X flavour and which output profile apply is set by the printer — and that specification comes before the first line of code.
Accessible PDFs to PDF/UA-1 (ISO 14289-1) are tagged PDFs: headings, paragraphs, lists, tables and images are marked up as structure, the reading order is defined, images carry alternative text, the language is declared. PDFlib generates the tags for tables and for artefacts — content with no meaning when read aloud — automatically; the rest of the structure comes from the application. With generated documents that is an advantage: the structure is built once in the template and applies to every document, instead of each PDF being fixed individually. Whether a legal obligation applies to your documents — for instance under Germany’s Accessibility Strengthening Act (BFSG) or, for federal public bodies, under the accessible IT regulation BITV 2.0 — is for a lawyer to assess case by case.
Incoming PDFs are checked by the application with pCOS before it processes them: page count, metadata, fonts used, ICC profiles, embedded files. A print-data upload portal can thus reject an unsuitable file immediately instead of the problem surfacing in prepress; from incoming ZUGFeRD invoices, pCOS reads the XML. TET extracts text and images for search indexes and business applications. For everything we generate, one rule applies: every standard is validated with independent tools, not merely on the library’s word, and PDF/UA is also tested by hand with a screen reader. A PDF that only claims to meet a standard is caught at the first check — better by us than by the recipient.
In PHP, PDFlib is loaded as an extension that has to match the PHP version on the server. We build generation in where the data lives: into PHP applications of your own based on Symfony or Laminas, as a TYPO3 extension that produces data sheets from records, or as a Shopware plugin that typesets product data sheets or business documents straight from the shop. Generation gets a module of its own with a clear boundary — data in, PDF out — so that templates and logic can be tested separately. Large runs go into a queue and run in the background, not within a page request. The website stays fast while the monthly run is busy next door.
PDFlib runs on the server, which makes operation part of the project. At Sharpness, PDFlib applications run on our own Proxmox VE clusters in the Hetzner data centre in Falkenstein, Germany, each customer environment on its own; PHP version, PDFlib extension, fonts and ICC profiles are maintained there together. Maintenance runs under a service level agreement — with a response time of 24, 8 or 4 hours, billed as a flat monthly fee, net; without an agreement we deal with requests within 48 hours during our business hours, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). On-call cover outside those hours exists only with an SLA. Updates to new PDFlib versions such as PDFlib 11 are tested with the same data in the old and the new version, and the results are compared before we switch.
We calculate in person-days, with separate items for the sample document, templates, implementation, validation and operation. The PDFlib licence is not an item of ours: you buy it from the manufacturer. We give the hourly rate and a price on request and after the initial assessment, not on the phone. The source code is yours and sits in your Git repository, and the PDFlib licence is registered to your company. Existing PDFlib applications we take over with an inventory — PHP version, PDFlib version, templates, fonts, dependencies — and then bring them up to a current PHP version and PDFlib 11. Operation and further development are then in one hand.
Process
Send us an example of the document you need — as a PDF, a sketch or a few sentences: where the data comes from, how many documents, which standard, who receives them. You get an initial assessment of whether PDFlib fits, which product, and what the effort depends on — before the quote, not after it. Phone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). We work remotely across Germany, with meetings in Oldenburg and the north-west by arrangement.
You tell us which documents should be produced, where the data comes from, in what volume and which standard the recipients require. We tell you whether PDFlib fits and which product — or whether an HTML-to-PDF solution will do, which we then build just the same.
Using the fully functional evaluation version of PDFlib, we produce a real document from real data and check it against the target standard. You see the result before a licence is bought. The sample document is a separate, clearly bounded item in the quote.
Design and sample document turn into templates: as code or, with PPS, as a PDF template with blocks set up in the Block Plugin for Acrobat. This includes fonts licensed for embedding in PDFs and, for print data, the printer’s output profile.
We build into your PHP application, into Symfony, as a TYPO3 extension or as a Shopware plugin, on a test system you can reach at any time. Generation is a module of its own with logging; large runs go to the background. The code sits in a Git repository that belongs to you.
Every document type is validated: PDF/A, PDF/UA, PDF/X or ZUGFeRD with independent tools. Then comes the manual check — PDF/UA with a screen reader, print data with a proof from the printer, invoices by reconciling the XML with the visible content.
The application runs on our servers in Germany, maintained under a service level agreement. Updates to PHP and PDFlib, to PDFlib 11 for instance, are tested with the same data in the old and the new version before we switch. Operation and further development stay in one hand.
PDFlib is a developer library that lets applications generate PDFs directly from data — on the server, without a layout program and without a detour via HTML. It is made by PDFlib GmbH in Munich, on the market since 1997 and a founding member of the PDF Association in 2006. Typical uses are ZUGFeRD invoices, catalogues and data sheets from databases, mail-merge letters, account and transaction statements, personalised marketing material and PDF/X print data. The current version is PDFlib 11. Sharpness has been working with PDFlib for more than 15 years, almost always from PHP.
PDFlib is worth it as soon as volume, precision, standards or print quality matter — above all when several of them come together. If you generate many documents, have to meet PDF/A, PDF/X, PDF/UA or ZUGFeRD, set tables across many pages or work with spot colours and output profiles for a printer, PDFlib is the right tool. For a manageable number of simple documents with no standard to meet, an open-source HTML-to-PDF solution will do instead; we build that just as well, without PDFlib licence costs. We tell you which route fits in the first conversation.
That depends on whether you only generate, include existing PDFs, work with templates or want to extract content. PDFlib creates PDFs from scratch. PDFlib+PDI also imports existing PDF pages — letterhead, forms, third-party data sheets — and includes pCOS for querying information from PDFs. PPS adds blocks that are set up in a template with the Block Plugin for Acrobat and filled by the program; that suits web-to-print and personalised documents. TET 6 extracts text, images and metadata from existing PDFs. We recommend the smallest product that covers your requirements.
Yes: PDFlib generates invoices to ZUGFeRD 1.0, 2.0 and 2.1 and to Factur-X, each as PDF/A-3 with embedded XML. The XML can also be attached to an existing PDF/A document, and via pCOS an application reads the XML from incoming invoices. The invoice data comes from your system, such as ERP, shop or billing; the XML and the visible invoice are generated from the same data so that they match. Which profile you need, up to and including the XRechnung profile, we settle with your accounts department beforehand. Every invoice type is validated before go-live.
Accessible PDFs are produced when the application supplies the structure as it generates them: headings, paragraphs, lists, tables, reading order, alternative text for images and the document language. PDFlib turns that into a tagged PDF to PDF/UA-1 and generates the tags for tables and artefacts automatically. Because the structure sits in the template, it applies to every generated document — a clear advantage over tagging individual files after the fact. We validate with an independent tool and test by hand with a screen reader. Whether a legal obligation applies is for a lawyer to assess case by case.
Yes, print data is one of PDFlib’s strengths: PDF/X-3, PDF/X-4, PDF/X-4p and PDF/X-5n, with output intent, ICC profiles, CMYK and PANTONE and HKS spot colours. For web-to-print we usually use PPS. The design exists as a PDF template with blocks, your customers’ input fills them, and preview and print file come from the same source. The application checks incoming print data with pCOS before it goes into production. Which PDF/X flavour and which output profile apply is set by your printer.
Yes: in PHP, PDFlib is loaded as an extension and is therefore available to any PHP application, including Symfony, Laminas, TYPO3 and Shopware 6. We build generation as a module of its own with a clear interface — into your PHP application, as a TYPO3 extension that typesets data sheets from records, or as a Shopware plugin that produces documents straight from the shop. It needs a server on which the PDFlib extension matches the PHP version. That is why we run such applications on our own servers in Germany and keep PHP and PDFlib up to date there together.
You buy the licence directly from PDFlib GmbH, in your company’s name; it applies per machine and operating system, development and test systems are included, and manufacturer support can be added as an optional annual contract. We calculate development in person-days, with separate items for the sample document, templates, implementation, validation and operation. The effort depends on the number of document types, the data sources and the standard the documents have to meet — less on the page count. We give the hourly rate and a price on request, after assessing your project.
The application runs on our own servers in Germany, on Proxmox VE clusters in the Hetzner data centre in Falkenstein, and Sharpness maintains it under a service level agreement. The levels range from 24 through 8 to 4 hours’ response time, as a flat monthly fee, net; without an agreement we deal with requests within 48 hours during our business hours of Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). On-call cover exists only with an SLA. The source code is yours and sits in your Git repository, and the PDFlib licence is registered to your company.
Yes. It starts with an inventory: PHP version, PDFlib version, templates, fonts, data sources and the question of which documents the application actually produces today. We then bring it up to a current PHP version and to PDFlib 11, the version that is current today. So that nothing breaks unnoticed, the same test data runs through the old and the new version and the results are compared — page by page and, for standards such as PDF/A or ZUGFeRD, with validation on top. After that we take on operation and maintenance under an SLA on our servers in Germany.
Three things help most: a sample document, access to the data source and the requirements of the recipients. The sample can be an existing invoice, an extract from a catalogue or a sketch. The data source is the ERP, the PIM, the shop or a database — with a set of realistic test data, including the awkward cases such as long names or empty fields. Requirements are, for example, the ZUGFeRD profile your accounts department needs or the PDF/X flavour and output profile your printer specifies. Add your house fonts, with a licence that permits embedding in PDFs.
Enquiry
A few sentences are enough: which documents, from which data, for which recipients. We come back with questions and an initial assessment — before anyone talks about a quote.