What a pain getting Unicode right, but there it is.
I cannot find anything to confirm that it is acceptable to put the PDF/A
definition file at the end of the Ghostscript inputs. I did this because
Ghostscript seems to copy document info from the last document on the
list so reportlab's information "wins" in normal order, so it fixes that
issue, and reportlab 'helpfully' fills in all of those fields even if it
does not have information.
It could also work to pass document information along to reportlab, and
set it in each output PDF: .debug.pdf, .rendered.pdf, and .page.pdf to
ensure that whatever page is last in the pipeline has the right
information. Or perhaps it's possible to write a Postscript trailer that
overwrites any previous docinfo with no side effects, but I can't find
any information on how to do that. I don't think it's worth pursuing
unless this arrangement causes some problem with PDF/A generation.
On a minor note, Jhove misreads the way I have encoded the strings in
producing its validation log. It reads them as UTF-16 little endian, so
will tend to produce a string of Asian characters in place of the real
data.
Little point to this feature - on most platforms the environment
variable can be overridden if desired to set a new root location.
At the same time, this change removes the ability to resume a partially
executed pipeline by deleting all of the results on failure. If -k is
provided then the temporary files will survive but there's no way to
resume from them. Because resuming doesn't really work away and would
only be useful to users experiencing very specific problems, this is
probably not worth it, so no major loss. The intent of -k is to assist
debugging.
Ghostscript is more reliable than Poppler's pdftoppm renderer. gs is
also a hard dependency, as the only open source tool that can produce
a PDF/A file, while Poppler could be removed. pdftoppm has awkward
syntax with some special handling needed for different versions. I have
found isolated rendering bugs with pdftoppm as well.
With that, I'm removing supporting for multiple rasterizers.
A minor advantage of pdftoppm is that its code produced JPEGs where
possible, but this can be achieved with gs.
James R. Barlow