DOCSEARCHbyAlgolia
Submit Docs

OpenPDF Documentation

repository·master·Indexed 26 days ago

https://github.com/librepdf/openpdf

A suite of PDF libraries including OpenPDF-html for HTML5/CSS3 to PDF rendering via ITextRenderer and htmlunit-neko, OpenPDF-Kotlin for programmatic PDF creation using a DSL and HtmlPdfBuilder, and OpenPDF-renderer for converting PDF pages to images using OpenPdfCoreRenderer.

Tokens
10.9K
Snippets
15
Records
69
Agent score
88%

What's inside OpenPDF

  1. Overview of OpenPDF-Kotlin

    master

    OpenPDF-Kotlin is a Kotlin extension module for OpenPDF. It provides Kotlin-specific APIs, utilities, and builder-style functionality to make PDF manipulation more expressive for Kotlin developers. Key features include:

    • Extension functions for common PDF tasks.
    • A lightweight PdfBuilder for programmatic document creation.
    • HtmlPdfBuilder for generating PDFs from HTML content.
    • DSL-inspired syntax for document generation.

  2. Understand the LGPL-2.1 License for OpenPDF

    master

    OpenPDF is distributed under the GNU Lesser General Public License (LGPL) version 2.1.

    This license allows you to link the library with non-free (proprietary) programs. A 'work that uses the Library' (a program designed to work with the library by being compiled or linked with it) is not considered a derivative work of the library itself, provided certain conditions are met regarding how the library is linked and how notices are provided.

    **Key requirements for users:

    • Linking with proprietary software: You may combine a 'work that uses the Library' with the Library to produce a work containing portions of the Library and distribute it under terms of your choice, provided those terms allow modification of the work for the customer's own use and reverse engineering for debugging such modifications.
    • Notice requirements: You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must also supply a copy of the LGPL license.
    • Shared Library mechanism: If you distribute an executable, using a suitable shared library mechanism (where the library is already present on the user's system and is interface-compatible) is a valid way to satisfy the requirement to allow users to relink with a modified version of the library.
    • No Warranty: The library is provided "AS IS" without warranty of any kind.

  5. Migrate to OpenPDF 2.4.0 core modules

    master

    Starting with version 2.4.0, the project has undergone a major package rename and module split. Developers should migrate from the legacy com.lowagie package to the new org.openpdf package.

    There are two available modules:

    1. openpdf-core-modern (Recommended): Uses the org.openpdf.* package namespace. This is the preferred module for all new development.
    2. openpdf (Legacy): Uses the com.lowagie.* package namespace. This module is deprecated and will be removed in a future release.

    To migrate, update your dependency management (e.g., Maven or Gradle) to use openpdf-core-modern and perform a global find-and-replace on your import statements from com.lowagie to org.openpdf.

  6. Distribute modifications to the Library (Work based on the Library)

    master

    If you modify the Library itself or create a derivative work, you must follow these conditions:

    1. Library Status: The modified work must itself be a software library.
    2. Modification Notices: You must cause the modified files to carry prominent notices stating that you changed the files and the date of the change.
    3. License Terms: You must license the entire modified work at no charge to all third parties under the terms of the LGPL.
    4. Interface Integrity: If a facility in the modified Library refers to a function or table of data supplied by an application program (other than as an argument), you must make a good faith effort to ensure the facility still operates (performing its meaningful purpose) even if the application does not supply that function or table.

  7. Migrate to OpenPDF 2.0.0

    master

    Upgrading to version 2.0.0 involves two major breaking changes:

    1. Java Version Requirement: OpenPDF 2.0.0 requires Java 17 or higher. Ensure your build environment and runtime are updated accordingly.
    2. API Cleanup: 108 deprecated methods and fields (previously marked as deprecated in version 1.3.40) have been removed. You must replace these with the new recommended methods. Refer to the official JavaDoc to identify the correct replacements for your specific use case.

  11. Install OpenPDF-renderer via Maven

    master

    Add the following dependency to your Maven pom.xml to use the OpenPDF-renderer library for converting PDF files to images using Java2D.

    <dependency>
    <groupId>com.github.librepdf</groupId>
    <artifactId>openpdf-renderer</artifactId>
    <version>3.0.1-SNAPSHOT</version>
</dependency>

  12. Migrate from legacy PDFFile/PDFPage API to OpenPdfCoreRenderer

    master

    The legacy PDFFile and PDFPage APIs (located in org.openpdf.renderer) are deprecated and scheduled for removal. Use OpenPdfCoreRenderer instead. Note that the legacy API may still be useful for pages requiring advanced PDF features not yet supported by the core renderer (e.g., extended graphics state gs, CMYK/pattern/shading colors, XObject Do, inline images, marked content, or clipping).

    | Legacy API | Replacement on `OpenPdfCoreRenderer` |
|---|---|
| `new PDFFile(ByteBuffer)` | `new OpenPdfCoreRenderer(File \| Path \| InputStream \| byte[])` |
| `pdf.getNumPages()` | `renderer.getNumPages()` |
| `pdf.getPage(n).getBBox()` | `renderer.getPageSize(n)` |
| `page.getImage(w, h, rect, ...)` | `renderer.renderPage(n, dpi)` |
| Manual DPI scaling via `getBBox()` | Pass `dpi` directly to `renderPage` |
| (no equivalent) | `renderer.getMetadata()`, `renderer.getTextFromPage(n)`, `renderer.getContentOperators(n)` |