mORMot Open Source

Hi Sven, hi Arnaud,

Sven, thank you, I gladly accept your offer, the PR as well as the further integration steps on your list. You know the trunk conventions far better than I do. I will review and test each step with Delphi 7, Delphi 2010, and FPC macOS and Linux. Thanks for spotting that mormot2.lpk shadows the fork's copy of mormot.lib.uniscribe.

The essential features are in now. If you both agree, I suggest a feature freeze until the migration into mORMot2 is done, so we don't work against each other.

Arnaud, agreed on mormot.lib.* and on no .inc files: the interfaces stay, and the FreeType and HarfBuzz imports move into their own mormot.lib.* units.

Splitting mormot.ui.pdf is welcome. A rough idea along the lines already inside the unit:

mormot.pdf.core: object model, writer, document, pages, metadata, PDF/A
mormot.pdf.font: TrueType, CMAP, font objects
mormot.pdf.canvas: drawing, text, tagged PDF
mormot.pdf.image: images, the only part needing the Graphics unit
mormot.pdf.crypt: encryption
mormot.pdf.emf: TPdfDocumentGdi, Windows only
on top: the TCanvas bridge, the report and its preview

This gives the VCL/LCL-free generator, and answers the HAS_UI_PDF question: only images, the bridge and the report need a UI framework, the Windows-only part gets its own flag. Part of it exists already; with Delphi on Linux and Android the unit builds without VCL, leaving out only the TBitmap image API. The exact boundaries will show during the work, since document, canvas and fonts reference each other. mormot.ui.pdf could stay as a thin unit of type aliases, so existing code keeps compiling.

TGDIPages as a TComponent felt right to me, but it must not break existing code. If replacing mormot.ui.report would do that, it could live next to it in the new folder, unless someone sees a more elegant way.

A PDF reader: yes, sounds interesting but challenging. A separate object model would be a good base for it. What scope do you have in mind: reading objects, metadata and attachments (e.g. the XML of a ZUGFeRD invoice), text extraction, or more?

Sven, on the invoice XML: as the author of an e-invoice library you are probably the best person to provide a sample invoice

Martin

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.

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.

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.

It looks like BatchAdd and BatchDelete update the Version field but BatchUpdate does not..

Please find the tests in https://gist.github.com/martin-doyle/00 … ceac4698fc.

Sorry again. I apologize for the inconvenience.
I tested on Linux with FPC. For Windows {$apptype console} is missing. Updated the files again. Hope it works now. Thank you for taking care.

 Replication test suite
  ------------------------


1. Test suite

 1.1. Replication simple:
  - Test add: 45 assertions passed  46.93ms
  - Test update: 97 assertions passed  14.95ms
  - Test delete: 72 assertions passed  13.42ms
  Total failed: 0 / 214  - Replication simple PASSED  80.92ms

 1.2. Replication batch:
  - Test batch add: 4,011 assertions passed  42.88ms
!  - Test batch update: 10 / 7,038 FAILED  55.69ms
  - Test batch delete: 6,968 assertions passed  56.58ms
  Total failed: 10 / 18,017  - Replication batch FAILED  159.90ms

 1.3. Replication special:
  - Test add ten and delete first record: 77 assertions passed  12.38ms
!  - Test add ten and delete last record: 3 / 77 FAILED  11.63ms
!  - Test add one and delete record: 1 / 13 FAILED  11.41ms
  Total failed: 4 / 167  - Replication special FAILED  39.53ms


Generated with: Delphi 11.3 Alexandria 32 bit Win compiler

Time elapsed for all tests: 282.22ms
Performed 2023-06-05 21:33:25 by mdoyle on WIN11

Total assertions failed for all test suits:  14 / 18,398
! Some tests FAILED: please correct the code.

I created some tests in https://gist.github.com/martin-doyle/00 … ceac4698fc.
Hope that helps finding the issue and a fix.

Not sure what you try to accomplish with the Version field. I use it for master slave replication without any issues. Never checked the numbers but the result of the replication.
It is difficult helping you with this fragment of code. Please provide a working example. But please follow the forum rules and do not copy long code directly into the forum.
I do not understand your batch approach. Please check the documentation 12.3. The batch process is pretty straightforward and works for me.

The same happens when using one of the Create functions with paramters.

Order := TOrmOrderBook.Create(TestClient.Orm, 'OrderNo = ?', ['Order1']);

The work around is currently using the Retrieve function like

Order := TOrmOrderBook.Create;
  try
    TestClient.Orm.Retrieve('OrderNo = ?', [], ['Order1'], Order); 

I updated the tests in https://gist.github.com/martin-doyle/6c … a26990e46e.

By the way, I like the idea of embedding detail data within the record (sharding). Would be interesting to know what other people use, just schemaless TDocVariant?

I kept testing on MacOS aarch64.

First, I compiled the newest sqlite3 3.37.2 and the installation worked without any problem. Then I thought, maybe compiling the static libraries works as well. I could compile armv8.c from the res directory. This made building the mormot2 package possible.
Compiling the sqlite3 library was a little trickier. I had to patch the amalgamation file on Linux since „sed“ works a little different on MacOS.

To make a long story short, I could compile and run the mormot tests with static libraries.
I had to disable a couple of tests which froze but it is a good start. https://gist.github.com/martin-doyle/0f … e9dacdc252

A first issue I found was a segmentation fault when creating the BloomFilter. ln(fFalsePositivePercent / 100) crashes. ln(0.01) works just fine. I created a little fpc test program in order to see if it is a fpc, type whatever issue. But no problem here - ln seems to work as expected but behaves strangely within the Create method of Bloomfilter.

Oops. My VM had only 2 cores with 4 GB RAM.
For 4 cores and 8GB it looks like this https://gist.github.com/martin-doyle/e0 … 22075e6de0.

cat /proc/cpuinfo does not give any information about the cpu details only some cryptic numbers. sysctl -a machdep.cpu only works on the macOS terminal. Let me further check.

I ran the tests several times. Please find the numbers here https://gist.github.com/martin-doyle/8b … c7d68cfd7c.

The failed tests starting at 2.1 ORM Core seem to have the same root cause. The InMemory storage reading existing data - i.e. TTestOrmCore._TRestServerFullMemory line 299 - fails due to duplicate entries. TRestStorageInMemory.LoadFromBinariy loads all entries correctly but in ComputeStateAfterLoad it seems that the PtrInt dup variable is not set in/after fValues.Hasher.ForceReHash(@dup).

OK. I checked again my setup. FPC is available for aarch64 only since version 3.2.2.
First I cross compiled from FPC 3.2.0  Debian X64 to aarch64 and I did not get the above error messages. All Variant tests were fine.
Second I reinstalled FPC fixes-3.2 and Lazarus fixes-2.2 on Debian aarch64 with FPCUPdeluxe 2.2.0h. The installed versions are now FPC 3.2.3-582-gdba65567f1 and Lazarus 2.2.0-64-gff329cf453. And guess what, no Variant test issues anymore.
There are a few tests left which fail and I will keep checking. Thanks ab and Alfred for the great job.