search

utelle / wxpdfdoc

wxPdfDocument - Generation of PDF documents from wxWidgets applications
http://utelle.github.io/wxpdfdoc/
Other
71 stars 27 forks source link

Add PDF/A support #73

Closed utelle closed 3 years ago

utelle commented 3 years ago

It would be nice to be able to create PDF documents which conform to the PDF/A-1 standard.

utelle commented 3 years ago

Commit 20c77e3de76b1651526980f0335a311ff0c6eae4 adds a first implementation for PDF/A-1B conformance to wxPdfDocument. Information about output intent, color profile, and XMP data are added to the resulting PDF document, if PDF/A-1B conformance is enabled.

PDF/A-1B conformance can be enabled with method wxPdfDocument::SetPdfA1Conformance. However, it is the user's responsibility to use only PDF features allowed for PDF/A-1B conformance.

At least the following requirements have to be fulfilled:

For certain conditions (like using core fonts or trying to apply document protection) wxPdfDocument issues error messages. However, not all PDF/A-1B requirements are checked and verified. It is recommended to validate the resulting PDF documents. Free online services are available for this purpose.

vadz commented 3 years ago

Great work, thanks!

FWIW I believe veraPDF includes an open source PDF/A validator.

utelle commented 3 years ago

Yes, veraPDF includes an Open Source PDF/A validator implemented in Java. The problem with PDF/A validation is that even if no invalid feature is used and a document could be technically validated, it is usually necessary to visually inspect the result, because for example the lack of transparency may lead to visually corrupt documents. And there are other possible issues ...

There are several free online PDF/A validators available, like for example

@vadz: BTW, the CI for wxPdfDocument errored out partially. Namely for wxWidgets 2.8 and for macOS.

It would be very kind if you could take a look.

Additionally, I'd like to add CI for wxWidgets 3.1 somehow. Any hints how to accomplish that are welcome.

vadz commented 3 years ago

Sorry, I don't know how to add PI without using the new method. AFAIR it was added exactly because it wasn't supported without it, so I'm afraid you have no choice but to restrict PDF/A support to wx 3.0+.

Concerning macOS failure, I don't know what's going on here neither (it might be due to a change in Homebrew), but you could experiment with a newer Xcode, by adding e.g. osx_image: xcode11.4 to .travis.yml.

To use wx 3.1 in Linux builds you need to either check it out from Git or download a release archive and then build it. It's not difficult, but not as simple as apt get neither, of course... For the applications it's pretty convenient to just include wx as a submodule, as then you can upgrade it as you see fit and it gets checked out by the CI scripts together with the main repository contents. But I'm not sure if it's a good idea for a library, which would be often itself included as a Git submodule...

Surprisingly, cross-building for MSW is actually simpler because we provide binaries on the release pages, so you can just download them (and the matching headers) and unpack the archives.

In any case, I could try to set this up if you'd like, although I don't know when exactly.

utelle commented 3 years ago

Sorry, I don't know how to add PI without using the new method. AFAIR it was added exactly because it wasn't supported without it, so I'm afraid you have no choice but to restrict PDF/A support to wx 3.0+.

Another reason to eventually drop support for wxWidgets 2.8. Maybe I call the next release 1.0.0 instead of 0.9.9 and combine it with removing wx 2.8 support.

Concerning macOS failure, I don't know what's going on here neither (it might be due to a change in Homebrew), but you could experiment with a newer Xcode, by adding e.g. osx_image: xcode11.4 to .travis.yml.

I will try that.

To use wx 3.1 in Linux builds you need to either check it out from Git or download a release archive and then build it. It's not difficult, but not as simple as apt get neither, of course... For the applications it's pretty convenient to just include wx as a submodule, as then you can upgrade it as you see fit and it gets checked out by the CI scripts together with the main repository contents. But I'm not sure if it's a good idea for a library, which would be often itself included as a Git submodule...

I doubt that it would be a good idea to add wx as a submodule to a library project. Including steps to check out and build wx from scratch seems to be the better approach.

In any case, I could try to set this up if you'd like, although I don't know when exactly.

That would be really kind of you. TIA! And, of course, there is absolutely no hurry. Adding CI based on the latest wx version will be a useful addition, as it would allow to detect incompatibilities earlier.

utelle commented 3 years ago

Tests with various embedded fonts revealed deficiencies in the PDF/A support implementation. Work is in progress to resolve them.

utelle commented 3 years ago

Commit 73a2c94b4aa73b58b11bad0277a487d7e6df41fd adjusts the implementation of PDF/A-1B conformance, so that validators should no longer complain about missing font data (CDIToGDIMap and CIDSet). That is, well-formed TrueType Unicode and OpenType Unicode fonts should now be fully usable in PDF/A-1B mode, even if font subsets are used.

One (but not all) of the PDF/A-1B online validators complained about a specific non-Unicode TrueType font regarding multiple CMap encodings. At the moment, I don't know if and how I could do anything about that within wxPdfDocument. That is, most likely not all TrueType fonts are usable in PDF/A-1B mode.

utelle commented 3 years ago

@vadz

Concerning macOS failure, [...] you could experiment with a newer Xcode, by adding e.g. osx_image: xcode11.4 to .travis.yml.

Adding osx_image did the trick. Thanks for the hint.

utelle commented 3 years ago

This PDF/A-1B feature was now officially released in version 1.0.0. Closing this issue...