ofdrw: Java OFD Generation, Signing, Conversion, and Packaging

OFDRW Targets Java Document and Compliance Workflows

OFDRW addresses the need to handle OFD as a structured document format rather than as a raster image. Its implementation follows GB/T 33190-2016, Electronic Document Storage and Exchange Format for Fixed-layout Documents, and the project says that bookmarks are supported. The intended users are Java developers building document generators, signing systems, archival compliance services, converters, or applications that need to manipulate OFD package contents.

The scope is wider than basic document creation. The repository separates parsing, layout, cryptographic support, digital signatures, conversion, packaging, and archive processing into Maven modules. This matters for server applications because a service that only creates documents does not necessarily need to depend on signing or conversion code. OFDRW also allows developers to use `ofdrw-core` data structures and build a different OFD-oriented library. That makes it a component library, not a complete reader, office suite, or graphical editor.

The distinction is important. OFDRW can produce and process OFD files, but the README points to separate projects such as `ofd.js`, `LiteOfd`, `XilouReader`, `OfdiumEx`, `ofd2html-python`, and `ofdbox` for browser preview, desktop viewing, HTML conversion, or image rendering. Projects that need an end-user reading interface should not treat this repository as an application ready for deployment.

Maven Modules Define the OFD Processing Boundaries

The module structure makes OFDRW's processing path concrete. `ofdrw-core` defines the basic data structures aligned with GB/T 33190-2016. `ofdrw-layout` builds and renders document content, while `ofdrw-font` handles font-related generation. `ofdrw-pkg` packages OFD files, and `ofdrw-reader` deserializes OFD documents and works with signatures and seals.

Other modules cover narrower responsibilities. `ofdrw-sign` provides OFD digital signing and sealing. `ofdrw-gm` contains the national cryptographic electronic-seal data structures needed by the signing module, and `ofrw-crypto` implements password-related functionality under GM/T 0099-2020. This module name is written as `ofrw-crypto` in the repository list, an inconsistency worth checking before configuring dependencies manually.

`ofdrw-converter` handles document conversion. `ofdrw-tool` provides operations such as merging, cropping, reorganization, and mixing. `ofdrw-archive` implements OFD-A archive checks and de-technical processing according to GB/T 42133-2022. `ofdrw-graphics2d` exposes an implementation of the AWT `Graphics2D` interface for content generation, and `ofdrw-full` aggregates the modules to simplify dependency management.

This separation allows dependency trimming, which the README explicitly recommends when program size matters. It also makes API ownership less obvious than in a single library. A team that begins with `ofdrw-full` may later need to determine which modules correspond to generation, parsing, conversion, or signing.

Maven Installation and First Java OFD File

The quick start requires Maven and Java. The repository states that the project can be built with JDK 1.8 or above. For an application that needs the full feature set, the documented dependency has group `org.ofdrw`, artifact `ofdrw-full`, and version `2.4.0`. Applications with narrower requirements should select modules from the repository rather than defaulting to the aggregate package.

Add the documented dependency to the application project's `pom.xml`:

<dependency>
  <groupId>org.ofdrw</groupId>
  <artifactId>ofdrw-full</artifactId>
  <version>2.4.0</version>
</dependency>

The repository's QuickStart example creates `HelloWorld.ofd`, opens an `OFDDoc`, adds one paragraph, and closes the document through try-with-resources:

public class HelloWorld {
    public static void main(String[] args) throws IOException {
        Path path = Paths.get("HelloWorld.ofd");
        try (OFDDoc ofdDoc = new OFDDoc(path)) {
            Paragraph p = new Paragraph("你好呀，OFD Reader&Writer！");
            ofdDoc.add(p);
        }
        System.out.println("生成文档位置: " + path.toAbsolutePath());
    }
}

After compilation and execution, the program prints the absolute location of `HelloWorld.ofd`. The README links this example to a rendered example image, but the minimal code does not demonstrate fonts, page sizing, graphics, tables, bookmarks, signatures, or conversion. Those capabilities require the module-specific examples and documentation listed by the project.

Building ofdrw from the Repository

Contributors can build the repository directly rather than consuming the Maven Central artifact. The documented build requires JDK 1.8 or above and runs Maven from the repository root:

mvn install

According to the README, this completes the build and packages the project into the local Maven repository. Because the repository uses Maven modules, this is the relevant path for checking all modules together or producing local artifacts during development. The README does not provide selective build commands, a prerequisite Maven version, or an example of running a particular test, so those details should be taken from `pom.xml` rather than guessed.

For non-Maven consumers, the README directs users to inspect the root `pom.xml` and resolve third-party dependencies manually. It also advises checking for package conflicts if a `NoClassFound` error appears. That recommendation reflects a practical concern for a modular Java library, but it does not identify a specific compatibility matrix for application frameworks, servlet containers, or Java distributions.

Generation, Parsing, Signing, and Conversion Paths

The documented HelloWorld flow is simple: construct `OFDDoc` for a filesystem path, add a `Paragraph`, close the document, and then locate the generated file. More complex workflows are delegated to specific modules and examples. Layout documentation covers custom elements, `Canvas` content, page events, attachments, watermarks, area-holder blocks, and table cells. The reader module includes a text-extraction example, while the signing module has a separate quick-start guide for digital signatures and seals.

For signing, the relevant path is not simply adding an element to `OFDDoc`. The repository divides ordinary document generation from signature and seal processing across `ofdrw-reader`, `ofdrw-sign`, and `ofdrw-gm`. Password protection is handled separately by `ofrw-crypto`. This separation gives applications explicit control over where signing and protection logic belong, but it also means that a basic generation dependency does not include the entire compliance workflow.

Conversion has its own module and documentation. The README states that the former `ofdbox` image solution has been merged into `ofdrw-converter`, and it links separate font-data and HTML conversion resources. It does not state that all OFD constructs convert identically across targets. Visual fidelity, font substitution, unsupported objects, and metadata handling must be checked in the converter documentation and with representative documents before conversion is treated as lossless.

OFD-A, Cryptography, and Compliance Boundaries

OFDRW includes functionality aimed at regulated or archival document workflows, but these features are bounded by specific standards. The `ofdrw-archive` module is described as implementing compliant checking and de-technical conversion for OFD-A according to GB/T 42133-2022. That is a defined archive-processing responsibility, not a general guarantee that every OFD file will pass every compliance rule.

The cryptographic module follows GM/T 0099-2020 for OFD password-related functions, and `ofdrw-gm` supports the national cryptographic electronic-seal data structures used by signing. The README links dedicated documentation for encryption and integrity protection and for signature setup. It does not publish a high-level support matrix for certificate types, trust stores, algorithms, timestamping, hardware security modules, or key storage. Those are adoption gates for applications handling signed documents, and the linked project documentation does not resolve them.

The README also directs users to read the project disclaimer before use. That is especially relevant when evaluating rendering behavior, standard coverage, document fidelity, or cryptographic claims. Apache-2.0 permits commercial use subject to the license conditions, but the project separately asks users to respect its notice and include the OFDRW open-source license. That is a licensing and attribution requirement to verify with counsel, not a technical feature of the library.

ofdrw Maintenance, Compatibility, and Upgrade Scope

The repository is not archived, and its last push was on 2026-10-12. Recent releases include version 2.4.0 on 2026-08-04, 2.3.9 on 2026-04-27, and 2.3.8 on 2026-01-21. These dates show recent release activity, although the README alone is not enough to establish compatibility with every JDK, framework, font, or document profile.

The README makes a forward-compatibility commitment, stating that OFDRW will continue to guarantee backward compatibility of its API and that users can upgrade to the latest library version. The contribution guide adds a related technical rule: public methods, classes, and interfaces should generally not be deleted. Existing exposed APIs are to be marked with `@Deprecated` and linked to a new implementation when an update is necessary.

That policy reduces the risk of ordinary API replacement, but dependency upgrades can still affect transitive libraries and runtime behavior. The README's warning about `NoClassFound` and package conflicts is therefore relevant during upgrades. Applications that only need one capability can reduce review scope by depending on the corresponding module, while applications using `ofdrw-full` must consider the aggregate package's larger change surface.

Editorial conclusion

OFDRW fits Java teams that must generate or process GB/T 33190-2016 OFD documents and can accept a library-based rendering workflow. It is less suitable for applications requiring a finished viewer, a visual editor, or a non-Java command-line tool. Before adoption, verify the required modules, conversion format, signature workflow, font coverage, and document fidelity against representative files. The README states an API compatibility commitment, but it also says to inspect module-specific documentation for signing, encryption, conversion, and layout behavior.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. ofdrw/ofdrw on GitHub
3. Project website
4. README
5. Releases