CartLog In

DevExpress Office & PDF File API — Year-End Roadmap (v26.2)

Office-Inspired Products
Office-Inspired Products
RSS
3 September 2026

In this blog post, I'll outline the DevExpress Office & PDF File API features and capabilities we expect to ship in our year-end release (v26.2 — December 2026). To discuss this roadmap in greater detail, or to share a business use case we have yet to address, please submit your feedback through the DevExpress Support Center. We are happy to follow up.

The information contained within this blog post details our current/projected development plans. Please note that this information is being shared for INFORMATIONAL PURPOSES ONLY and does not represent a binding commitment on the part of Developer Express Inc. This roadmap and the features/products listed within it are subject to change. You should not rely on or use this information to help make a purchase decision about Developer Express Inc products.

Roadmap Updates

Our roadmap will be updated regularly to reflect development progress. As we get closer to the release, we expect to add additional items and modify the status of planned features. Look for the following labels next to every feature:

  • Planned — Feature is scheduled but not yet in development.

  • In Development — Under active development.

  • Coming in EAP v26.2 — Will be available in our first v26.2 early access preview.

  • Coming in v26.2 — Will be included in the final v26.2 release.

  • Released in v26.2 — Fully implemented and available.

.NET 11 Support

DevExpress Office & PDF File API libraries will support .NET 11 (both v26.1 and v26.2) following Microsoft's official release.

Minimum Supported .NET and Visual Studio Versions

As you may know, .NET 8 and .NET 9 will reach end of support on November 10, 2026. We will therefore raise our minimum supported .NET version to .NET 10 once we release v26.2 in December. The minimum .NET Framework version will remain 4.6.2.
Visual Studio 2022 will be the minimum supported IDE version when v26.2 ships.

Automatically Re-target DevExpress-based Projects to .NET 10 and Update 3rd Party NuGet Packages

For .NET/.NET Core, we recommend using the DevExpress Project Converter to update all DevExpress-related and third-party project references, packages, and configurations automatically. See also a related Breaking Change notice.

Separate NuGet Packages for Different .NET Versions (.NET 10, .NET 11, etc.)

Today, third-party dependencies are automatically patched after a detected vulnerability (for example, a vulnerability in System.Security.Cryptography.Xml) only for the minimally supported .NET version (today it's .NET 8). Today (with v26.1, v25.2, v25.1, v24.2), manual version pinning (Solutions #1 or #2 from this article) may still be required for .NET 9/10-based projects depending on their exact TFM and project SDK. We will provide .NET-specific dependency groups in DevExpress NuGet packages, which will simplify use of v26.2.

Security — SBOMs and CRA Readiness

If you deliver software in the EU, the  Cyber Resilience Act (CRA) will require a Software Bill of Materials (SBOM – an inventory of every component inside your solution) as part of your conformity documentation. The CRA and its associated regulatory regime will go into effect on December 2027. Each software application/solution manufacturer must fulfil SBOM-related obligations. DevExpress-authored SBOMs will help customers document/inventory DevExpress libraries used within a DevExpress-powered app.

Most dependency scanners and SBOM generation tools read what a NuGet package declares (its dependencies on other NuGet packages) and stop there, which leaves two gaps we fill:
  • Components embedded inside a package. Some DevExpress NuGet packages bundle fonts and third-party JavaScript libraries. Package metadata has no way to declare them, so a scanner never reports them — even though their licenses and vulnerabilities are as real as those of any declared dependency.
  • Developer dependencies. Libraries we use to build our products never reach users, so we mark them with scope: "excluded". We list these libraries regardless, because all vulnerabilities should be documented.
We released a preview version of DevExpress-authored SBOMs in May 2026 (for our .NET NuGet packages). SBOMs for CRA Compliance in DevExpress-powered Apps describes what the files contain and how to feed them into tools such as Dependency-Track, Trivy, and Grype. With v26.2, we expect to extend coverage to NPM packages and DevExpress VCL libraries, take our SBOMs out of preview and make them available to every customer.

WCF Dependency Will Be Removed from XPO and Printing Core Libraries

These core libraries currently include references to WCF (Windows Communication Foundation), a standard library with a well-documented history of vulnerability disclosures in its dependencies ("thanks" to System.Security.Cryptography.Xml). We will remove these WCF references from DevExpress.Xpo core and DevExpress.Printing.Core libraries in v26.2. .NET Framework users will use the new DevExpress.Xpo.Services and DevExpress.Printing.Remote libraries instead (if you need this advanced and rarely used WCF functionality). The Project Converter will update project references automatically, so you should not encounter upgrade-related issues.

Product-Tailored AI Skill Updates

We expect to extend and update the DevExpress AI Agent Skills repository based on user feedback (for multiple implementation tasks and AI coding assistants, such as GitHub Copilot, Claude Code, Cursor, and JetBrains AI Assistant).

The repository includes folders for different DevExpress products. Navigate to the dx-office-file-api directory to locate AI Agent Skills for Office/PDF File API coding assistants with built-in knowledge of Office/PDF File API libraries, their capabilities, related APIs, best practices, and code examples.

New Document Processing Libraries for .NET and Java

As you may already know, our new PDF and Presentation APIs are object-based document processing libraries. In upcoming release cycles, we will extend the same object-based approach to our Word Processing and Spreadsheet APIs. Both APIs will share the same design objectives: a modern, idiomatic object model built upon concrete, cloneable objects, with a consistent developer experience for both .NET and Java. Moving forward, we expect to design future APIs from ground up for both platforms, so developers can use the same concepts and document workflows regardless of their technology stack.

New Word Processing Document API

.NET — In Development Java — Planned

The new Word Processing Document API will replace the current interface-based API with a concrete, tree-like object model. You will work directly with document objects that can be created, configured, and composed before they are added to a document. Built upon DevExpress.RichEdit.Core, it will be backend-oriented and run cross-platform on .NET 10+.
For the CTP (Community Technology Preview) version, we plan to address core document-generation and editing workflows:
  • Generate a complete document (an invoice, report, technical documentation) from scratch
  • Examine and edit the document object tree, including text runs, paragraphs, shapes, fields, and other elements
  • Apply styles and formatting
  • Insert tables and images
  • Replace placeholders, calculate fields, and initiate mail merge
  • Search, edit, and format document elements using an advanced range-based API
  • Convert documents across different Word-like formats, including HTML
  • Export documents to PDF
  • Encrypt or protect a document
  • And more
We expect to deliver the same feature set for our Java-based APIs. The new library will ship as a dedicated NuGet/JAR package — independent of DevExpress.Document.Processor.

New Spreadsheet Document API

.NET — In Development Java — Planned

The new Spreadsheet Document API will offer the same object-based design for workbook processing, built on the existing DevExpress.Spreadsheet engine and calculation infrastructure. You will work with concrete objects through a clean, range-based model. The same API and feature set will be available across both .NET and Java.
For the first release, we expect to support the following workbook usage scenarios:
  • Generate a workbook from scratch
  • Convert workbooks across formats, and split and merge workbooks
  • Edit worksheets, rows, columns, and cells
  • Apply styles and formatting
  • Insert tables, charts, and shapes
  • Read, write, and calculate formulas
  • Sort and filter data
  • Export to PDF
  • Encrypt or protect a workbook
  • And more
Like our new Word Processing API, this library will ship as a dedicated package.

Safer Document Processing API

Server-based applications increasingly process documents from untrusted sources, be they user uploads, email attachments, or third-party integrations. To help mitigate these risks, we are adding Safer Document Processing APIs to our PDF and Presentation libraries so you can protect your application against malicious input before processing begins. Both APIs will follow the same model: enforce loading limits, strip active or dangerous content on import, and sanitize sensitive data on demand.

PDF Document API — Secure Loading and Sanitization

Planned

The DevExpress PDF Document API will add a secure loading and sanitization layer for untrusted documents with three lines of defense:
  • Secure loading — reject dangerous documents before or during parsing. You will be able to set limits for file size, indirect-object count, and page count, and activate a strict loading mode that disables heuristic recovery for malformed PDFs.
  • Active content sanitization — remove executable and interactive content, including embedded JavaScript, document actions (JavaScript, Launch, URI, GoTo, and SubmitForm), and embedded files or attachments.
  • Privacy and data-leakage prevention — sanitize external links and annotations, strip document metadata, and inspect document content before removal, so sanitization remains under your control.

Presentation API — Security and Privacy

Coming in EAP v26.2

Our Presentation API will add its own Safer Document Processing API with three lines of defense against malicious or oversharing presentations:
  • Security loading limits — enforced during import to guard against decompression and resource-exhaustion attacks. You will be able to cap the slide count and the number of shapes per slide, along with file size and XML element count/nesting depth. When a limit is exceeded, the API will allow you to handle, log, or throw an error, based on your configuration.
  • Dangerous content removal — applied during import, before content is loaded into the document model. You will be able to strip external images, links, and chart-data references (removing these prevents tracking and IP leakage), macros, OLE objects, ActiveX controls, and custom XML parts.
  • Privacy sanitization — an Inspect/Sanitize API applied on demand to a loaded document. Inspect detects sensitive content; Sanitize removes or neutralizes it, covering document metadata (author, organization, description), hidden slides, unrecognizable text, speaker notes, and embedded objects.

New PDF Document API

We continue to expand our new, dedicated PDF Document API (DevExpress.Docs.Pdf) with the following features:

Bookmark API

Coming in EAP v26.2

Our PDF Document API will introduce a Bookmark API for the document outline. You will be able to create, read, and modify the bookmark tree that forms a document's navigation pane. Readers can then jump directly to sections in long or generated PDFs.

Incremental Updates — Research Stage

In Progress

We are researching broader incremental update support for the PDF Document API. Our goal is to save supported changes as revisions, without rewriting the entire file. We expect this approach to append only modified PDF objects and preserve the original bytes whenever possible.
Our current research focuses on change tracking for PDF objects and collections, and we plan to expand coverage in phases. The following changes are in scope:
  • Update document metadata
  • Apply digital signatures
  • Change page size, boxes, or rotation
  • Add, modify, or remove attachments
  • Insert pages or overlay content on existing pages
Final capabilities will depend on our ongoing research. If a particular change cannot be written as an incremental update, the API will fall back to the standard full-save workflow.

Digital Signature API

In Development

Our PDF Document API will allow you to digitally sign PDF documents natively using your own certificates. The API will cover the full signature-related workflow:
  • Create signature fields and customize associated appearance, including signer name, reason, location, date, labels, fonts, colors, and images.
  • Sign documents with a digital signature and associated metadata such as reason, location, contact information, and signing time, together with a certification level and change permissions.
  • Inspect existing signatures, including the signer, reason, location, signing time, certification level, and permitted document changes.
The API will choose the appropriate save mode automatically. When adding signatures, it will use incremental updates to preserve existing signatures whenever possible; otherwise, it will fall back to the standard full-save workflow.
You will also be able to add multiple signatures to a document, stored in their own signature field, and reuse the same certificate across signatures. A single signature field displayed on multiple pages will produce one signature that remains visible throughout the document.

Form Field and Annotation Flattening

Coming in EAP v26.2

You will be able to flatten interactive form fields and annotations. Flattening renders associated visual appearance directly into page content. Values remain visible but are no longer editable — useful when you finalize a completed form for distribution or archival.

PDF/A and PDF/UA Compliant API

Planned

Organizations subject to archival (PDF/A) or accessibility (PDF/UA) requirements will be able to produce compliant documents through a single, built-in API. We plan to address three compliance scenarios:
  • Generate PDF/A- and PDF/UA-compliant documents directly during document generation.
  • Convert loaded or newly generated documents to a target compliance standard.
  • Validate compliance before distributing a document.

OCR API

In Development

We will introduce a built-in OCR (Optical Character Recognition) for the PDF Document API so you can turn scanned documents and raster page content into searchable, extractable, and AI-ready text. Our scope centers on the core recognition workflow:
  • Recognize text in scanned pages, page regions, and multi-page documents.
  • Generate a searchable PDF text layer while preserving original page graphics.
  • Extract recognized text as a structured model of blocks, lines, and words, each with its own text, bounds, and confidence level.
  • Preserve page reading order and text positioning.
Our API will allow you to build a recognition pipeline that feeds directly into existing PDF text, search, and accessibility workflows.

Presentation API

Hyperlink Support

Planned

Our Presentation API will support hyperlinks for full compatibility with presentations created in Microsoft PowerPoint. You will be able to create, inspect, modify, and remove hyperlinks on both individual text runs and entire shapes (images, charts, text boxes, and more).
Hyperlinks will support the following targets:
  • External web URLs
  • Email addresses (mailto:)
  • Local files
  • Other slides within the same presentation
Existing hyperlinks will round-trip on import and export, and you will be able to inspect and edit every related property, including display text, target URI, and tooltips.

Word Document Processing

PDF Export / Rendering — Floating-Point Layout Calculation

In Development

The document layout engine will calculate positions using floating-point coordinates (System.Single, RectangleF, PointF, and SizeF) instead of integers. The change will start with font metrics and extend to the layout model. This shift will enhance positioning precision and fidelity for rendered and exported documents (PDF and image formats). You can expect more precise text and object positioning, improved table and paragraph accuracy, and closer compatibility with Microsoft Word's rendering engine.
A feature toggle will allow you to switch between float-based and integer-based rendering, so existing output that relies on integer layout continues to work as expected.

PDF/UA-2 Export — PDF Structure Destinations & Field Tagging

Coming in EAP v26.2

We will enhance the accessibility and navigation throughb PDF/UA-2 files generated from Word documents. Our Word Processing tools will resolve navigational targets to PDF structure destinations. Supported targets include those that map to bookmarks — explicit bookmarks, Table of Contents entries, and cross-reference fields. As a result, links and navigation in the exported PDF will point to the correct structural location rather than a raw page coordinate. The export will also tag AcroForm fields for PDF/UA-2, so Word documents that use content controls will convert to accessible PDF forms.

Spreadsheet Processing

ODS Format Support — Research Stage

In Progress

We are working towards OpenDocument Spreadsheet (ODS) format support and investigating available opportunities. Demand for OpenDocument Format (ODF) interoperability is rising sharply across the public sector. In March 2026, Germany's Deutschland-Stack mandated ODF — alongside PDF/UA — as a standard document format for federal public administration at every level of government. Implementation is planned by 2028, and suppliers to the German public sector will need ODF support. Other EU member states building compatible infrastructure may follow.
We are currently at the research stage, but we will evaluate how to load and save ODS documents while preserving worksheet structure, cell values and formulas, formatting, merged cells, named ranges, and document settings. We will prioritize complete implementation separately, based on the research results.

Your Feedback Counts

Have questions or suggestions about our year end DevExpress Office & PDF File API (.NET or Java) roadmap? Please share your thoughts in the survey below or submit a ticket through the DevExpress Support Center. Your feedback is always welcome.

v26.1 - What’s New

And before I let you go - If you have yet to review the features/capabilities introduced in our most recent major update, please visit the following webpage and let us know what you think of our June release by responding to our online survey: Explore Our Newest Features (v26.1).

Free DevExpress Products - Get Your Copy Today

The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the DevExpress Support Center at your convenience. We'll be happy to follow-up.
Maria Nikulina (DevExpress) Maria Nikulina (DevExpress)
.net Accessibility java Office Office File API PDF Document API presentation api Roadmap spreadsheet document api v26.2 Word Document API

Recent Posts

DevExpress Office & PDF File API for Java — Generate PDFs, PowerPoint Presentations, and Barcodes in Java Apps
Maria Nikulina (DevExpress)
DevExpress Office & PDF File API — Year-End Roadmap (v26.2)
Maria Nikulina (DevExpress)
Office File & PDF Document Processing APIs — June 2026 Roadmap (v26.1)
Maria Nikulina (DevExpress)
File & Document Processing APIs (Office/PDF File APIs) — Year-End Roadmap (v25.2)
Maria Nikulina (DevExpress)
File & Document Processing APIs — New PowerPoint Presentation API Library
Maria Nikulina (DevExpress)