mORMot PDF crossplatform

mdoyle · 2026-09-12 07:48:02

I’ve been a big fan of mORMot for a long time, and I’ve used the PDF engine extensively over the years. It’s a powerful library, and I really appreciate how much it can do.

Recently, with the move to Lazarus on macOS and Linux, I became especially interested in a cross-platform solution for PDF generation and reporting. That led me to build and refine a project that abstracts the platform-specific parts and works across those environments.

This is a very complex library, so I relied heavily on Claude to help with the porting and integration work. It has been extremely useful in navigating the complexity and getting the cross-platform pieces to fit together cleanly.

The project currently includes 6 example files that demonstrate the main use cases and APIs:

direct PDF generation,
TCanvas-style usage,
report generation,
markdown/export flow,
CJK support,
RTL/Arabic text handling.

You can find the project on https://github.com/martin-doyle/mORMot2 … ssPlatform.

I’d love to hear whether this kind of cross-platform mORMot PDF/reporting project is of interest to others in the community. If there is interest, I’d be happy to share more details and examples.

Martin

edwinsn · 2026-09-13 09:47:05

@Martin, thanks for sharing, it must be very helpful.

flydev · 2026-09-14 08:08:17

thanks! good timing, I've just been asked to add report generation and pdf export on our backend, and I never touched the pdf side of mormot until now. will give it a try this week.

JD · 2026-09-15 13:00:37

@mdoyle Thank you so much for sharing your work.

mdoyle · 2026-09-21 19:11:33

Besides the cross-platform support, creating accessible PDFs was a design goal. Since the European Accessibility Act came into force on 28 June 2025, accessibility is mandatory for many PDFs published online (and it has been required for public-sector bodies for even longer).

I've made a few adjustments so that most of the examples now pass an accessibility test, carried out with the German testing tool PAC. All demos except the Chinese and RTL ones now run through the tests without any errors.

EduardAppelhans · 2026-09-22 03:57:42

I‘m wondering if it might be reasonable to combine this solution with Sh17/Sven Harazim/ Landrix Zugpferd for Delphi solution.

The idea is to use it on top of an existing invoice generating mormot2 SOA Service with fast report to enhance it submitting cross platform PDF Zugpferd capabilities. Would this approach generally be advisable?

Last edited by EduardAppelhans (2026-09-22 04:51:39)

mdoyle · 2026-09-22 19:15:34

Thanks for the question, it touches on something I've been thinking about as well.

Short answer: invoice generation itself is out of scope for this project, but PDF/A-3 with file attachments is something I will look into.

A few thoughts on your setup:

- If FastReport renders your invoices, the PDF comes from FastReport's own exporter. Since this PDF engine can't modify existing PDFs, you would need to render the layout with TGDIPages instead, or check whether FastReport itself supports PDF/A-3 attachments.

- This library could provide the generic container: PDF/A-3 with embedded files like Landrix XML invoice library, combined with the existing PDF/UA tagging.

I'll put PDF/A-3 with attachments on the roadmap as a future item and validate it. By the way, a real-world invoice layout would make an excellent test case.

EduardAppelhans · 2026-09-22 20:16:55

Thanks for your answer!

sh17 · 2026-09-23 22:19:33

Oh, exciting. I'll keep an eye on it.

mdoyle · 2026-09-24 19:36:18

The engine now writes PDF/A-3U and PDF/UA-1 in one file.

The new example zugferd_demo builds a ZUGFeRD / Factur-X invoice (profile EN 16931): a tagged, accessible PDF with the invoice XML embedded. The invoice data is public KoSIT test data. The result passes veraPDF, the Mustang validator and PAC 2024 on Windows, Linux and macOS.

Feedback welcome, especially if you try it with your own validator or accounting software.

ab · 2026-09-24 23:00:00

Perhaps it could be worth considering integrating it back to the mormot trunk sooner or later.

We could define a new "src/pdf" folder for the units, not any more in "src/ui".
The mormot.pdf.xxxx.pas unit names just show this pattern.

sh17 · 2026-09-25 03:54:50

mdoyle wrote:

The engine now writes PDF/A-3U and PDF/UA-1 in one file.
The new example zugferd_demo builds a ZUGFeRD / Factur-X invoice (profile EN 16931): a tagged, accessible PDF with the invoice XML embedded. The invoice data is public KoSIT test data. The result passes veraPDF, the Mustang validator and PAC 2024 on Windows, Linux and macOS.
Feedback welcome, especially if you try it with your own validator or accounting software.

A dream is coming true. I'm going to take a look at it right away today.

mdoyle · 2026-09-25 11:04:11

ab wrote:

Perhaps it could be worth considering integrating it back to the mormot trunk sooner or later.
We could define a new "src/pdf" folder for the units, not any more in "src/ui".
The mormot.pdf.xxxx.pas unit names just show this pattern.

This is exactly what I was hoping for. It finally gives me a chance to give something back to the project.

I wasn't sure whether PDF still had enough relevance in 2026, or whether my changes were good enough to be accepted upstream.

I've been so focused on tackling cross-platform challenges like fonts, different libraries, and tagged PDF support that I kind of lost sight of other areas, such as Delphi.

And yes, integrating it with mORMot2 is definitely the way forward.

mdoyle · 2026-09-27 22:06:59

A busy day on the PDF cross-platform port. The main news: the TCanvas bridge and TGDIPages now build on Delphi 7 too. All the console demos and the --export mode of the two GUI demos run there and produce the same PDFs as FPC, still passing PAC and veraPDF.

Heads-up, there are breaking changes:
- preview and printing moved out of TGDIPages into their own unit (mormot.ui.reportpreview)
- TGDIPages takes RawUtf8 now, and GetReportFonts/GetExportFonts return RawUtf8
- the demo PDFs have new file names

Most code should compile as before, but please check the ROADMAP ("To Announce") before you update.

mdoyle · 2026-09-28 10:48:10

mORMot2 PDF cross-platform: now on Delphi 2010 too

After Delphi 7, today it was Delphi 2010's turn, our first Unicode Delphi. Good news: the engine didn't need a single fix. All tests pass on Delphi 2010, Delphi 7 and FPC, all eight demos give the same PDFs as with Delphi 7, and PAC and veraPDF are happy.

It wasn't completely painless: my UTF-8 string constants got encoded twice, and that shook out a small bug in the XMP header. Fixed.

I can't test a current Delphi or Delphi for Linux myself because I don't have those compilers. If you do, I'd love to hear how it goes.

Details in the Github repo.

mdoyle · Yesterday 19:28:20

mORMot2 PDF Cross-Platform: from correct to usable, starting with the ZUGFeRD demo

Until now the work went into the output: one PDF, the same on Windows, Linux and macOS and from FPC, Delphi 7 and Delphi 2010, and valid. That means tagged PDF/UA-1 and PDF/A-3U, checked with veraPDF, PAC 2024 and Mustang. That goal is reached for all eight demos.

Along the way it became clear that the calls were too complicated, and the demos showed it. So the next phase is usability, and it started with zugferd_demo. It is now a plain TGDIPages report, and the page is read from the factur-x.xml it embeds.

From here on, no more drastic changes to the calls or the demos should be needed. The other demos will be simplified the same way, without changing the API.

Details are in the repo, docs/ROADMAP.md.

ab · Today 08:40:45

Very good work!

sh17 · Today 12:59:39

Hi Martin, hi Arnaud,

following Arnaud's idea of bringing this into the trunk under src/pdf, I had a look at what it would take, and I would like to help with it.

A first step is done in my fork, branch mormot2-merge: landrix/mORMot2-PDF-CrossPlatform
It ports the trunk commits to mormot.ui.pdf.pas since the fork was started (among them the EMF PT_BEZIERTO fix and EMR_ALPHABLEND), and replaces the copies of mormot.ui.core, mormot.ui.gdiplus and mormot.lib.uniscribe by the trunk units. mormot2.lpk now contains mormot.lib.uniscribe itself, which shadowed the fork's copy, so GetGlyphIndicesW is now imported in mormot.ui.pdf directly. Tests are green with FPC on Windows aarch64 and Delphi 13 Win32/Win64. On Linux aarch64 the only failures are 5 checks that need CJK/Arabic fonts the machine does not have. Martin, I can send it as a PR whenever you like.

The rest looks mostly mechanical to me: licence headers, OSWINDOWS/OSDARWIN instead of MSWINDOWS/DARWIN, {$I ..\mormot.defines.inc}, the usual mORMot formatting, the roadmap references out of the source comments, ASCII-only sources, FreeType/HarfBuzz loaded via TSynLibrary, and the tests as test.pdf.*.pas in mormot2tests. I am happy to do this in small PRs. Martin, just tell me which parts you would rather do yourself, so we don't get in each other's way while you are still working on it.

Before touching the structure, three questions for Arnaud:

Platform backends: keep the interfaces that register themselves in initialization, or rather per-OS .inc files included by the unit?
The new TGDIPages is a TComponent, the trunk TGdiPages a TScrollBox with a much bigger API. Should the new one replace mormot.ui.report, or live next to it in src/pdf?
HAS_UI_PDF currently means Windows + VCL/LCL. Extend it to POSIX, with a separate flag for TPdfDocumentGdi and the metafile part?

One more thing: the invoice XML in zugferd_demo is Apache-2.0, which does not go well with the GPL option of the mORMot licence. We would need our own sample data there.

ab · Today 21:01:24

@Sven
Sounds like a rationale direction.
All libraries should be in mormot.lib.*.pas form I guess as much as possible. I am not sure the windows.inc / posix.inc include files are needed - and such include files are very badly supported by the Delphi IDE...

One remark/question...
Perhaps instead of one huge mormot.ui.pdf.pas unit we could put several smaller units. This was the main point of having a pdf/ folder with its own set of units. But we may define report/ or export/ or somethingelse/ folder in which to put not only pdf but reporting, etc... worth discussing.
If we could have a LCL/VCL free version of the raw pdf generator document it could be worth it.
We need to prepare a pdf reader feature too - it is a well demanded improvement.

mORMot Open Source

#1 2026-09-12 07:48:02

mORMot PDF crossplatform

#2 2026-09-13 09:47:05

Re: mORMot PDF crossplatform

#3 2026-09-14 08:08:17

Re: mORMot PDF crossplatform

#4 2026-09-15 13:00:37

Re: mORMot PDF crossplatform

#5 2026-09-21 19:11:33

Re: mORMot PDF crossplatform

#6 2026-09-22 03:57:42

Re: mORMot PDF crossplatform

#7 2026-09-22 19:15:34

Re: mORMot PDF crossplatform

#8 2026-09-22 20:16:55

Re: mORMot PDF crossplatform

#9 2026-09-23 22:19:33

Re: mORMot PDF crossplatform

#10 2026-09-24 19:36:18

Re: mORMot PDF crossplatform

#11 2026-09-24 23:00:00

Re: mORMot PDF crossplatform

#12 2026-09-25 03:54:50

Re: mORMot PDF crossplatform

#13 2026-09-25 11:04:11

Re: mORMot PDF crossplatform

#14 2026-09-27 22:06:59

Re: mORMot PDF crossplatform

#15 2026-09-28 10:48:10

Re: mORMot PDF crossplatform

#16 Yesterday 19:28:20

Re: mORMot PDF crossplatform

#17 Today 08:40:45

Re: mORMot PDF crossplatform

#18 Today 12:59:39

Re: mORMot PDF crossplatform

#19 Today 21:01:24

Re: mORMot PDF crossplatform

Board footer