iText Add-ons

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

The reference material consulted while preparing these pages is listed in the section bibliography.

iText Core is the library that creates, reads and edits PDF files. Around it, iText publishes add-ons: separate artifacts that solve one bigger problem on top of Core, such as converting HTML, blacking out confidential text, recognising characters in scanned images, shaping complex scripts, flattening XFA forms, shrinking files, converting Office documents or rendering pages as images. This page lists the add-ons, says for each one whether it is open source under the AGPLv3 or sold only under a commercial licence, gives the Maven coordinates and the repository that serves them, and shows runnable Java 21 examples for the three families that are available as open source: pdfSweep, pdfOCR and pdfHTML. Versions are those published on 2026-10-09, with iText Core 9.8.0. The running scenario is the Bookshelf Billing back office: invoices that must have e-mail addresses and bank accounts removed before they are shared, and scanned supplier invoices that must become searchable.

The module structure of Core itself, and where each add-on fits in it, is in iText Architecture & Modules. The licence consequences for a hosted service are discussed in Introduction & Approaches; this page only states, for each add-on, which licences exist.

The add-on map

The table lists every add-on that this section knows about. "AGPLv3 or commercial" means that the source and binaries are published under the GNU Affero General Public License v3 and that a commercial licence can be bought to avoid its obligations (mainly offering the source of the whole application to its users, including users of a network service). "Commercial only" means that there is no open-source licence: the binaries are closed source, are downloaded from the iText Artifactory server and need a licence key at run time. Versions are the latest releases on the respective repository on 2026-10-09; always check the compatibility matrix for the add-on version that matches your Core version.

Add-on

Licence

Maven artifact

Repository

Latest version

pdfHTML converts HTML and CSS to PDF

AGPLv3 or commercial

com.itextpdf:html2pdf

Maven Central

6.3.4

pdfSweep redacts text, images and vector content

AGPLv3 or commercial

com.itextpdf:cleanup

Maven Central

5.0.8

pdfOCR turns scanned images into searchable PDF (Tesseract 4 and ONNX engines)

AGPLv3 or commercial

com.itextpdf:pdfocr-tesseract4 or com.itextpdf:pdfocr-onnx-cpu (both on top of pdfocr-api)

Maven Central

5.0.2

pdfCalligraph shapes complex and Indic scripts, Arabic ligatures and more

Commercial only

com.itextpdf:typography

iText Artifactory

5.1.1

pdfXFA flattens dynamic XFA forms

Commercial only

com.itextpdf:pdfxfa

iText Artifactory

5.0.8

pdfOptimizer reduces size and improves speed of existing PDFs

Commercial only

com.itextpdf:pdfoptimizer

iText Artifactory

4.1.5

pdfOffice converts Word, Excel and PowerPoint files to PDF

Commercial only

com.itextpdf:pdfoffice

iText Artifactory

2.0.5

pdfRender renders PDF pages as images

Commercial only

com.itextpdf:pdfrender

iText Artifactory

2.0.4

Apryse Fluent (formerly DITO) generates Word, PowerPoint, Excel and PDF documents from Office templates

Commercial only, sold by Apryse

Not an iText Core add-on; delivered as the Fluent SDK

Apryse

Product line outside iText Core

Two facts drive everything else on this page. First, only the first three rows can be pulled from Maven Central and used without a licence key under the AGPLv3. Second, the five commercial-only add-ons, and the commercial variants of the first three, come from https://repo.itextsupport.com/releases, a repository that you add to the build yourself, and need the iText licence key library plus a key file. A build that works on a laptop with only Maven Central configured will therefore fail for those add-ons, which is the first thing to check when a dependency "cannot be resolved". The repository URL, the artifact identifiers and the latest versions in the table were read from the Maven Central metadata and from the iText Artifactory server on 2026-10-09; the licence of every row is taken from the installation guide of the add-on in the iText Knowledge Base and from the product pages linked in the references.

The 2006 book iText in Action, consulted for the concept order of this section but not reproduced, describes a library with no add-ons at all: iText 1.4 was a single JAR under the MPL and LGPL licences, and every feature was in it. The split between a Core library and separately licensed products is a feature of iText 7 and later (finding O1 of this section’s source analysis), together with the change of the Core licence to AGPLv3 or commercial. If a team still has code on the old com.lowagie packages, the licence changes along with the API when moving to iText 9, and OpenPDF, the LGPL and MPL fork of the old API, is the alternative that keeps the older terms.

Using the examples (Java 21 idioms)

The books of that generation show Java 1.3 to 5 code: no generics, no var, explicit close() calls in finally blocks, string concatenation for text (finding O28). The examples on this page use the Java 21 idioms instead: var for local variables, try-with-resources so that streams and documents are closed even when an exception is thrown, text blocks for literal markup, immutable List.of collections and the Path and Files API instead of File streams where the add-on allows it. Every example sets maven.compiler.release to 21.

The two Maven coordinates that every example needs are shown once here and restated where they matter. The itext-core POM aggregates the Core modules (kernel, io, layout, forms, sign, barcodes, pdfa, pdfua, svg, styled-xml-parser, hyph, font-asian and the others) and is declared with <type>pom</type>. The bouncy-castle-adapter is needed only where signing or encryption is used, and none of the add-on examples below need it.

<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>itext-core</artifactId>
    <version>9.8.0</version>
    <type>pom</type>
</dependency>

Derived from the iText installation guide for Java.

pdfSweep: redaction

A PDF viewer can draw a black rectangle over a piece of text, but the text is still in the content stream: anyone can select it, copy it or extract it with a script. That is a "fake" redaction and the cause of regular leaks. pdfSweep removes the underlying content for real. It parses the content stream of the page, drops the text operators whose glyphs fall in the area, clips images and vector paths to leave out the area, and optionally paints a filled rectangle where the content used to be. Licence: AGPLv3 or commercial, the same as iText Core, so the open-source variant needs no licence key.

The artifact is com.itextpdf:cleanup (the product is called pdfSweep, the artifact and the Java package are not). The classes live in com.itextpdf.pdfcleanup. PdfCleanUpTool, the type that older tutorials use to drive a clean-up by hand, still exists in 5.0.8 as the lower-level API; the recommended entry point is the static PdfCleaner facade, which the Knowledge Base page linked below uses as well. The examples here were compiled against 5.0.8 and follow the current API.

<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>cleanup</artifactId>
    <version>5.0.8</version>
</dependency>
<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>itext-core</artifactId>
    <version>9.8.0</version>
    <type>pom</type>
</dependency>

Regex-based redaction with a composite strategy

The simplest use is to describe what to remove with regular expressions. RegexBasedCleanupStrategy extends the text-location strategy that Text Extraction & Parsing explains: it collects the position of every match while the page is processed. A CompositeCleanupStrategy combines several of them, and PdfCleaner.autoSweepCleanUp runs the whole thing over a document. The CommonRegex class provides ready-made patterns for dates, currencies, IP and MAC addresses, e-mail addresses, URLs and some national identifiers.

The example creates a small Bookshelf Billing invoice that contains a customer e-mail address and an example IBAN, redacts both, and then proves that the text is gone by extracting it again, instead of trusting the picture.

package billing;

import com.itextpdf.kernel.colors.ColorConstants;
import com.itextpdf.kernel.pdf.PdfDocument;
import com.itextpdf.kernel.pdf.PdfReader;
import com.itextpdf.kernel.pdf.PdfWriter;
import com.itextpdf.kernel.pdf.canvas.parser.PdfTextExtractor;
import com.itextpdf.layout.Document;
import com.itextpdf.layout.element.Paragraph;
import com.itextpdf.pdfcleanup.CleanUpProperties;
import com.itextpdf.pdfcleanup.PdfCleaner;
import com.itextpdf.pdfcleanup.autosweep.CompositeCleanupStrategy;
import com.itextpdf.pdfcleanup.autosweep.RegexBasedCleanupStrategy;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;

public class RedactInvoice {

    public static void main(String[] args) throws IOException {
        Path source = Path.of("invoice-with-pii.pdf");
        Path target = Path.of("invoice-redacted.pdf");

        createSample(source);

        // Every match of every strategy is removed from the page content.
        var strategy = new CompositeCleanupStrategy();
        strategy.add(new RegexBasedCleanupStrategy("[\\w.+-]+@[\\w-]+\\.[\\w.]+")
                .setRedactionColor(ColorConstants.BLACK));
        strategy.add(new RegexBasedCleanupStrategy("ES\\d{2}(\\s?\\d{4}){5}")
                .setRedactionColor(ColorConstants.BLACK));

        try (var in = Files.newInputStream(source);
             var out = Files.newOutputStream(target)) {
            PdfCleaner.autoSweepCleanUp(in, out, strategy, new CleanUpProperties());
        }

        // Verify with the text extractor: the redacted values must not be extractable any more.
        try (var pdf = new PdfDocument(new PdfReader(target.toFile()))) {
            String text = PdfTextExtractor.getTextFromPage(pdf.getPage(1));
            System.out.println(text);
            System.out.println("e-mail removed: " + !text.contains("@"));
            System.out.println("IBAN removed:   " + !text.contains("ES91"));
        }
    }

    private static void createSample(Path path) throws IOException {
        try (var doc = new Document(new PdfDocument(new PdfWriter(path.toFile())))) {
            doc.add(new Paragraph("Bookshelf Billing - Invoice 2026-0042"));
            doc.add(new Paragraph("Customer: Jane Reader, jane.reader@example.com"));
            doc.add(new Paragraph("IBAN: ES91 2100 0418 4502 0005 1332"));
            doc.add(new Paragraph("Total: 31.50 EUR"));
        }
    }
}

Run against cleanup 5.0.8 and Core 9.8.0 on Java 21, the extracted text of the output keeps the title and the total and shows empty text after "Customer: Jane Reader," and after "IBAN:", and both checks print true. The IBAN in the sample is the well-known example IBAN used in public documentation, not a real account. Derived from the iText Knowledge Base page on removing content with pdfSweep.

Two-step redaction with annotations

Real workflows often separate marking from burning: a person or a rule marks the areas, a reviewer approves them, and only then is the content destroyed. PDF has a standard annotation for that, the redaction annotation, which iText Core exposes as PdfRedactAnnotation. pdfSweep applies and removes such annotations with PdfCleaner.cleanUpRedactAnnotations. The example below finds the e-mail address with the same strategy as before, but instead of removing it writes one redaction annotation per match; a second pass, standing for the approval, applies them.

package billing;

import com.itextpdf.kernel.colors.ColorConstants;
import com.itextpdf.kernel.geom.Rectangle;
import com.itextpdf.kernel.pdf.PdfDocument;
import com.itextpdf.kernel.pdf.PdfReader;
import com.itextpdf.kernel.pdf.PdfWriter;
import com.itextpdf.kernel.pdf.annot.PdfRedactAnnotation;
import com.itextpdf.kernel.pdf.canvas.parser.PdfTextExtractor;
import com.itextpdf.pdfcleanup.PdfCleaner;
import com.itextpdf.pdfcleanup.autosweep.PdfAutoSweepTools;
import com.itextpdf.pdfcleanup.autosweep.RegexBasedCleanupStrategy;

import java.io.IOException;

public class RedactTwoStep {

    public static void main(String[] args) throws IOException {
        // Step 1: locate the sensitive text and mark it with standard redaction annotations for a reviewer.
        var strategy = new RegexBasedCleanupStrategy("[\\w.+-]+@[\\w-]+\\.[\\w.]+")
                .setRedactionColor(ColorConstants.BLACK);
        try (var pdf = new PdfDocument(new PdfReader("invoice-with-pii.pdf"), new PdfWriter("invoice-marked.pdf"))) {
            for (var location : new PdfAutoSweepTools(strategy).getPdfCleanUpLocations(pdf)) {
                Rectangle area = location.getRegion();
                var annotation = new PdfRedactAnnotation(area);
                annotation.setInteriorColor(new float[] {0, 0, 0});
                pdf.getPage(location.getPage()).addAnnotation(annotation);
            }
        }

        // Step 2: after approval, burn the marked areas in for real. The annotations are consumed.
        try (var pdf = new PdfDocument(new PdfReader("invoice-marked.pdf"), new PdfWriter("invoice-approved.pdf"))) {
            PdfCleaner.cleanUpRedactAnnotations(pdf);
        }

        try (var pdf = new PdfDocument(new PdfReader("invoice-approved.pdf"))) {
            System.out.println(PdfTextExtractor.getTextFromPage(pdf.getPage(1)));
            System.out.println("annotations left: " + pdf.getPage(1).getAnnotations().size());
        }
    }
}

Run on the file produced by the first example, the output shows the customer line without the e-mail address, the IBAN line unchanged (this strategy did not target it) and annotations left: 0. The marking pass uses the same PdfDocument(reader, writer) stamping mode that Manipulating Existing PDFs describes. Derived from the iText Knowledge Base page on creating and applying redactions.

What pdfSweep does not do

Three limits matter in practice, and each one is checked against the output rather than assumed.

  • Only content that is text, image or vector drawing is matched. A scanned page is one image: a regular expression finds nothing, so such a page must go through OCR first (next section). The recognised text is then an invisible text layer on the page and can be matched, but check that the removed area really covers the visible pixels of the scanned image.

  • Redacting a page does not sanitise the rest of the file. Document information, XMP metadata, attachments, form field values, outlines and annotations on other pages can carry the same secret. Test the finished file with the text extractor and with a search over the raw bytes, and remove the other places explicitly.

  • A redaction on a file that was digitally signed invalidates the signature, because the content changes; redact first and sign the result.

The product page is at pdfSweep on itextpdf.com.

pdfOCR: scanned images to searchable PDF

A scanner or a phone camera produces an image. Put into a PDF, it looks right but cannot be searched, selected or read by a screen reader. pdfOCR runs an OCR engine over the image, then builds a PDF page that shows the original image and puts the recognised text on top of it as an invisible layer at the right positions, which is how searchable scans work. It can also produce PDF/A-3u output. Licence: AGPLv3 or commercial. The open-source jars are on Maven Central; the commercial variants are on the iText Artifactory server together with the licence key library.

Since pdfOCR 5.0.0 (published with iText Suite 9.6.0) there are two families of engines, each in its own artifact:

  • Tesseract 4 (com.itextpdf:pdfocr-tesseract4): two engine classes, Tesseract4ExecutableOcrEngine, which launches the tesseract command-line program and needs it installed on the machine, and Tesseract4LibOcrEngine, which calls the library through the Tess4J binding. Both need Tesseract’s trained-data files (for example eng.traineddata) in a directory that you point the engine at.

  • ONNX (com.itextpdf:pdfocr-onnx-abstract, with com.itextpdf:pdfocr-onnx-cpu for CPU execution): OnnxOcrEngine runs neural-network text detection and recognition models in the ONNX format, with optional GPU acceleration, and supports several model families (docTR, PaddleOCR, EasyOCR). You download the model files yourself; their licences are those of the model authors, not of iText. These modules replace the earlier onnxTR module, which iText marks as deprecated and which stays at version 4.1.2 on Maven Central.

All the engines implement IOcrEngine, and OcrPdfCreator is the class that turns a list of image files into a PDF with any engine, so switching between Tesseract and ONNX is a change of one constructor.

<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>pdfocr-tesseract4</artifactId>
    <version>5.0.2</version>
</dependency>
<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>pdfocr-onnx-cpu</artifactId>
    <version>5.0.2</version>
</dependency>
<dependency>
    <groupId>com.itextpdf</groupId>
    <artifactId>itext-core</artifactId>
    <version>9.8.0</version>
    <type>pom</type>
</dependency>

Tesseract engine

The example reads one scanned supplier invoice page and writes a searchable PDF. TESSDATA_PREFIX is an environment variable that points at the trained-data directory; the path of the executable depends on the operating system and is a placeholder here.

package billing;

import com.itextpdf.pdfocr.OcrPdfCreator;
import com.itextpdf.pdfocr.OcrPdfCreatorProperties;
import com.itextpdf.pdfocr.tesseract4.Tesseract4ExecutableOcrEngine;
import com.itextpdf.pdfocr.tesseract4.Tesseract4OcrEngineProperties;

import java.io.File;
import java.io.IOException;
import java.util.List;

public class OcrScan {

    public static void main(String[] args) throws IOException {
        // Directory with eng.traineddata (from the tessdata project) and the tesseract binary.
        var engineProperties = new Tesseract4OcrEngineProperties();
        engineProperties.setPathToTessData(new File(System.getenv("TESSDATA_PREFIX")));
        engineProperties.setLanguages(List.of("eng"));
        var engine = new Tesseract4ExecutableOcrEngine("/usr/bin/tesseract", engineProperties);

        var creatorProperties = new OcrPdfCreatorProperties()
                .setPdfLang("en-US")
                .setTitle("Scanned supplier invoice");
        var creator = new OcrPdfCreator(engine, creatorProperties);

        creator.createPdfFile(List.of(new File("scan-page-1.png")), new File("scan-searchable.pdf"));
    }
}

Verification status. This example was compiled against pdfocr-tesseract4 5.0.2 and the artifacts resolve from Maven Central, but it was not executed: the machine used to prepare this page has no Tesseract installation and no trained data, so the recognition output was not inspected. Treat the run-time behaviour as unverified and check it on a machine with Tesseract 4. Two details of the API are worth knowing. The language setter is on the engine properties, not on the creator. And OcrPdfCreator.createPdfAFile is the variant that takes a PdfOutputIntent and produces the PDF/A-3u output mentioned above; the conformance rules it relies on are those of PDF Standards & Conformance.

Derived from the iText Knowledge Base page on OCR of an image to PDF and the pdfOCR installation guide.

ONNX engine

The ONNX variant needs no native OCR program, only the model files. The detection predictor finds the boxes that contain text, the recognition predictor reads each box. OnnxOcrEngine implements AutoCloseable because it owns the ONNX runtime sessions, so try-with-resources is the right way to use it. The model file names below are placeholders for the files you download.

package billing;

import com.itextpdf.pdfocr.OcrPdfCreator;
import com.itextpdf.pdfocr.onnx.OnnxOcrEngine;
import com.itextpdf.pdfocr.onnx.detection.OnnxDetectionPredictor;
import com.itextpdf.pdfocr.onnx.recognition.OnnxRecognitionPredictor;

import java.io.File;
import java.util.List;

public class OcrOnnx {

    public static void main(String[] args) throws Exception {
        // .onnx model files downloaded beforehand; the iText KB lists compatible models.
        var detection = OnnxDetectionPredictor.fast("models/fast_tiny.onnx");
        var recognition = OnnxRecognitionPredictor.crnnVgg16("models/crnn_vgg16_bn.onnx");

        try (var engine = new OnnxOcrEngine(detection, recognition)) {
            var creator = new OcrPdfCreator(engine);
            creator.createPdfFile(List.of(new File("scan-page-1.png")), new File("scan-onnx.pdf"));
        }
    }
}

Verification status. Compiled against pdfocr-onnx-cpu 5.0.2; not executed, because no model files were available on the preparation machine. The factory methods fast, dbNet, linkNet, paddleOcr and easyOcr for detection, and crnnVgg16, crnnMobileNetV3, master, parSeq, sar, viTstr, paddleOcr and easyOcr for recognition, exist in the 5.0.2 JAR; which pair gives acceptable accuracy for your scans must be measured on your own documents. The Knowledge Base page on the ONNX module shows the same pattern with the PaddleOCR models and explains how to run on a GPU.

Derived from the iText Knowledge Base page on the ONNX module.

OCR in a pipeline

OCR output is probabilistic: a "3" can be read as an "8". Treat the recognised text as a search aid for the scanned image, not as the source of truth for amounts or tax identifiers, and keep the image on the page, which is what the invisible text layer approach does. A realistic Bookshelf Billing pipeline OCRs a supplier invoice, extracts the candidate fields with the techniques of Text Extraction & Parsing, and routes anything with a low confidence to a person. Setting setPdfLang and tagging (OcrPdfCreatorProperties.setTagged) matters for accessibility; whether the result meets PDF/UA still has to be validated, as described in the standards page.

pdfHTML: a reference

pdfHTML, artifact com.itextpdf:html2pdf 6.3.4, converts HTML and CSS to PDF and is the add-on most projects meet first. Licence: AGPLv3 or commercial. It has its own page, HTML to PDF with pdfHTML, with the full treatment of ConverterProperties, paged media, custom tag workers and resource retrievers. This section only shows the smallest complete program, to show where the add-on sits next to the other two.

package billing;

import com.itextpdf.html2pdf.ConverterProperties;
import com.itextpdf.html2pdf.HtmlConverter;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;

public class InvoiceHtml {

    public static void main(String[] args) throws IOException {
        String html = """
                <html>
                  <body>
                    <h1>Invoice 2026-0042</h1>
                    <p>Customer: Jane Reader</p>
                    <table><tr><th>Item</th><th>Total</th></tr><tr><td>Book</td><td>31.50 EUR</td></tr></table>
                  </body>
                </html>
                """;
        try (var out = Files.newOutputStream(Path.of("invoice-html.pdf"))) {
            HtmlConverter.convertToPdf(html, out, new ConverterProperties());
        }
    }
}

Compiled and run against html2pdf 6.3.4 and Core 9.8.0: it writes a one-page PDF. The classic HTML tools of the book generation, HtmlWorker and the XML worker, were replaced by this add-on (finding O8); the Maven coordinate is the same one used in the dependency block of the dedicated page. Derived from the pdfHTML tutorial, chapter 1.

Commercial-only add-ons

None of the add-ons below can be resolved from Maven Central, and none has an AGPLv3 variant. They are mentioned with their purpose, artifact and licence so that a project can decide whether it needs them; this page deliberately gives no runnable example for them, because running one requires a purchased licence key and the closed-source jars. The one dependency fragment that all of them share is the Artifactory repository.

<repositories>
    <repository>
        <id>itext-releases</id>
        <name>iText Repository - releases</name>
        <url>https://repo.itextsupport.com/releases</url>
    </repository>
</repositories>

The licence key library is loaded once at start-up, before any other iText call, and reads the JSON key file that iText delivers with the commercial licence, with LicenseKey.loadLicenseFile(new File(...)). For iText 7.2 and later, including 9.x, it is com.itextpdf.licensing:licensing-base, plus licensing-remote for volume licences that report usage, on the same server; the older com.itextpdf:itext-licensekey artifact and its XML key file apply only to iText 7.1 and 5.5. Read the file location from configuration or from a secret store; do not commit it. The Knowledge Base guide Installing the iText license key and license key library describes the supported loading methods.

pdfCalligraph

pdfCalligraph (artifact com.itextpdf:typography, 5.1.1) adds the OpenType layout features that Core does not apply: shaping for Indic and other complex scripts, and Arabic contextual forms. Without it, text in those scripts is drawn glyph by glyph in logical order and looks wrong. The older font library of the 2006 book handled a few Asian encodings through a separate JAR; the current equivalent for Chinese, Japanese and Korean fonts is the font-asian module of Core, and pdfCalligraph is the commercial answer for complex scripts (finding O6, developed on Fonts & Unicode). Licence: commercial only. See the installation guide and the product page.

pdfXFA

pdfXFA (artifact com.itextpdf:pdfxfa, 5.0.8) flattens dynamic XFA forms into ordinary PDF pages so that they can be displayed and archived in a viewer that does not support XFA. XFA is deprecated since PDF 2.0, and the old book generation presented it as a current technology; new forms should be AcroForms. Licence: commercial only. See the installation guide and the product page.

pdfOptimizer

pdfOptimizer (artifact com.itextpdf:pdfoptimizer, 4.1.5) reduces the size and improves the opening speed of existing files: it gives fine-grained control over optimisations that reduce size or improve speed, according to the product description. It is the tool for the "the generated invoice archive is too large" problem. Core’s own writer options (full compression, object streams, immediate flush) cover part of this at creation time; pdfOptimizer works on files that already exist. Licence: commercial only. See the installation guide and the product page.

pdfOffice

pdfOffice (artifact com.itextpdf:pdfoffice, 2.0.5) converts Word, Excel and PowerPoint files to PDF. It is useful when users upload office documents that must be archived as PDF. Licence: commercial only. See the installation guide.

pdfRender

pdfRender (artifact com.itextpdf:pdfrender, 2.0.4) renders PDF pages as raster images, the reverse of the OCR input step: thumbnails, previews and image-based comparison. Licence: commercial only. See the installation guide.

Apryse Fluent (formerly DITO)

iText is part of Apryse, and the DITO document-generation product that iText once sold has since been renamed Apryse Fluent. It is a different kind of product from the add-ons above: instead of Java API calls, designers build templates inside Microsoft Word, PowerPoint or Excel with tags and conditional logic and bind them to data sources such as JSON, XML and SQL databases, and an SDK generates the final documents. It is not an artifact that extends iText Core, it is licensed commercially, and it competes with the template-report approach of JasperReports described elsewhere in this section. See the product page.

Choosing an add-on

  • A document that already exists as HTML and CSS: pdfHTML, with the AGPLv3 obligations or a commercial licence.

  • Confidential data in a PDF that will leave the company: pdfSweep, then verify the result by extracting text and by searching the raw file.

  • Scans that must be searched, indexed or made accessible: pdfOCR, with Tesseract when a native program is acceptable and ONNX models when it is not.

  • Indic or Arabic text and other complex scripts to be shaped correctly: pdfCalligraph, which is only available commercially. If that is unacceptable, check whether a different engine in the alternatives page of this section fits.

  • Old XFA forms, size reduction, Office conversion, page rendering: pdfXFA, pdfOptimizer, pdfOffice and pdfRender, all commercial only.

For a hosted service, the AGPLv3 variant of the three open-source add-ons has the same consequence as the AGPLv3 Core: users of the network service are entitled to the source of the service. If that is not acceptable, a commercial licence for Core and the add-ons is the route; the comparison with LGPL and Apache-licensed libraries is in Introduction & Approaches. Other pages of this section cover PDF/A & PDF/UA with iText, Encryption & Permissions and testing with CompareTool in Testing & Performance with iText.

References