Support for PDF/X-1a and X3 compatible PDF documents

[IbnSaeed]

Hello

are there any plans for supporting PDF/X-1a and X3 compatible PDF's for getting the final pdf Print Ready ?

[mojavelinux]

Could you expand what you mean by this. In other words, what is required and how do we test it?

I'll note that we are limited at the moment by what Prawn can support. So I'd first check to see if this is supported by Prawn. If so, then the answer is most certainly yes. If not, then we have to address it there first.

[mojavelinux]

https://github.com/prawnpdf/prawn

We are still using an older version of Prawn (1.2.1), but obviously we need to upgrade.

[mojavelinux]

Tracking means that this issue is dependent on or linked to an upstream issue. There's no other way to filter on that field in GitHub issues without that label.

[mojavelinux]

Looks like we're going to have to take this on in Asciidoctor PDF (or create another gem for it) as it was closed upstream (for no good reason).

Here's the code that implements this support (at least the essential parts).

https://gist.github.com/fidothe/32613b44a5b6588531d9

[mojavelinux]

You could try to weave the referenced code into Asciidoctor PDF. Ideally, we want to be able to include it from a module so it has minimal impact on the size of the converter class (which is already getting quite big).

Another solution is to create extensions to Prawn (even if it's overridding internal Prawn stuff) so we can isolate the code, maybe even into a gem. We need to demonstrate that this can easily be merged into Prawn. The more code you show up with, the more open the Prawn developers seem to actually integrate the code.

[jessedoyle]

@mojavelinux: It's looking like some PDF/X functionality is going to make its way into Prawn::Core. See here. I'd give it some time to see where this is headed before making dramatic changes.

[mojavelinux]

I really hope so. Of course, we can help be a part of making it happen :)

[mojavelinux]

What's good for Prawn is good for Asciidoctor PDF.

[mojavelinux]

FYI, there's an open pull request to add support in Prawn. See prawnpdf/prawn#1029.

[mojavelinux]

As is turns out, if you install rghost (a binding for GhostScript) and pass -a optimize=prepress when calling asciidoctor-pdf, you end up with a valid PDF/A document.

[mojavelinux]

We could add support for specifying the PDF variant, which maps to the -dPDF flag (either -dPDFX or -dPDFA). Something like pdf-device=A. See https://www.ghostscript.com/doc/current/VectorDevices.htm#PDFA

[mojavelinux]

Since we have limited control over the PDF library (Prawn), all we can offer is to add a switch to the optimizer to produce a PDF/X or PDF/A compliant file. The compliance setting must be specified in the value of the optimize attribute, separate from the quality by a comma. For example:

-a optimize=print,PDF/A

By configuring the optimizer to remove non-printable (hyperlink) annotations, it's able to produce a PDF/A-compliant file. However, it's not able to produce a PDF/X-compliant field because it says the TrimBox doesn't fit inside BleedBox. Please file that issue with Prawn.

[mojavelinux]

Beyond relying on the optimizer to distill the PDF into a PDF/A or PDF/X-compliant file, I won't be pursuing this issue any further. PDF spec compliance is not a concern of this library. It has to happen either upstream (Prawn / pdf-core) or downstream (GhostScript, hexapdf, etc). This library only uses the PDF-generation APIs that are available. We cannot get sidetracked trying to hack around the PDF that it generates as it only holds up progress in other areas where our time can make a real difference.