fluid_fpdf for TYPO3

When PDFs are built from data rather than from the web page, you need fluid_fpdf

There are two fundamentally different ways to generate PDFs in TYPO3. The web page approach (web2pdf) converts the rendered web page into a PDF with the PHP library mPDF. It’s simple, but the result looks like a printed web page, complete with navigation, footer and responsive artifacts. The data-driven approach (fluid_fpdf) works differently: a Fluid template defines the PDF layout, TYPO3 data fills the placeholders, and the result is a clean document in your corporate design. Invoices, certificates, quotes, reports: anything that has to exist as a proper document needs the data-driven approach.

fluid_fpdf uses the FPDF library (a lean PHP class for generating PDFs) and connects it to TYPO3’s Fluid template engine. The upshot: developers write PDF layouts in the same template language they already use for HTML templates.

Typical use cases

Automated invoicing. An online shop or booking system built on TYPO3 creates an invoice for every order. The invoice data (line items, prices, customer details, taxes) comes from the database, the layout from a Fluid template. For one events company, fluid_fpdf generates 200-300 invoices a month without any manual intervention. Every invoice carries an invoice number, the company logo, bank details and all the mandatory details required by law.

Certificates of attendance and confirmations. Training providers, associations and companies issue certificates after training courses, workshops or exams. The participant’s name, the date, the course title and the trainer’s signature are pulled automatically from TYPO3 data. For a training provider with 5,000 participants a year, this automation saves around 250 working hours that previously went into building PDFs by hand in InDesign.

Quotes and property brochures. Real estate agencies, consultancies and agencies produce quotes with variable content: customer details, selected services, individual pricing. The PDF layout is fixed (corporate design), the content changes. fluid_fpdf fills the template with data from a TYPO3 form or a backend module.

Technical architecture

fluid_fpdf connects two systems: TYPO3’s Fluid template engine and the FPDF library. The architecture works in three steps.

First, the Fluid template defines the PDF structure. Instead of HTML tags, the template uses dedicated ViewHelpers for PDF elements: <fpdf:page> for a new page, <fpdf:cell> for a text cell, <fpdf:image> for an image, <fpdf:line> for a line. The syntax is Fluid, but the output is FPDF commands rather than HTML.

Second, TYPO3 provides the data. A controller or DataProcessor passes the required data (invoice line items, customer details, product information) to the template. This works exactly like data handling in HTML Fluid templates: {invoice.items}, {customer.name}, {order.total}.

Third, FPDF renders the PDF. The ViewHelpers translate the Fluid logic into FPDF method calls (SetFont, Cell, Image, Ln). FPDF produces the PDF as a binary file that is either sent straight to the browser (download) or stored in the file system (for example, to send it by email).

Font support is an important detail: out of the box, FPDF supports only 14 fonts (Helvetica, Times, Courier and their variants). For corporate fonts, TTF files have to be converted into FPDF font files. FPDF’s MakeFont tool handles the conversion.

Tables require manual positioning. FPDF has no HTML table model. Every cell is positioned either absolutely (X/Y coordinates) or relative to the previous cell. For complex tables with variable row heights, the developer has to implement the height calculation.

Common problems and solutions

UTF-8 characters don’t render correctly. Internally, FPDF works with Latin-1 encoding. German umlauts (ä, ö, ü), Polish characters (ą, ę, ł) or Cyrillic letters need UTF-8 support. Solution: use tFPDF (a UTF-8-capable variant of FPDF) instead of FPDF. fluid_fpdf supports tFPDF as its backend. Alternatively, use mPDF, which supports UTF-8 natively.

Page breaks with dynamic content. An invoice with 5 line items fits on one page, one with 50 line items needs 3 pages. FPDF does not break pages automatically when content runs past the page margin. Solution: check the remaining page height before each line item (GetY() + row height > end of page) and insert a new page when needed. Headers and footers repeat automatically on every page through the Header() and Footer() methods.

Layout development is time-consuming. Without a visual preview, the developer has to generate the PDF after every change to see the result. Solution: set up a preview route that displays the PDF in the browser (output mode “inline” instead of “download”). Every refresh regenerates the PDF, which speeds up the development cycle considerably.

Migration and version compatibility

fluid_fpdf supports TYPO3 v10 and v11. There is no official version for v12, but the porting effort is moderate (Extbase adjustments, ViewHelper registration).

The alternatives for TYPO3 v12/v13 are EXT:pdfviewhelpers (uses TCPDF instead of FPDF, more features, actively maintained, v12-compatible), a custom solution with mPDF as a Composer package (HTML/CSS as input, easier layout work than with FPDF) or a headless setup with an external PDF service (Gotenberg or wkhtmltopdf as a Docker container).

Migrating from fluid_fpdf to EXT:pdfviewhelpers is manageable: the template structure is similar (ViewHelper-based), but the ViewHelper names and parameters differ. For a project with 5 PDF templates, the migration takes 2-4 days. Gosign has implemented PDF generation in TYPO3 with all the common libraries and advises on the right solution for your specific requirements.