Drop two dependencies and replace them with one that does the job of
both. Smells like progress.
mupdf does PDF file repair and rendering
poppler does rendering and page splitting
qpdf does PDF file repair and page splitting
ghostscript does PDF file repair, rendering, and page splitting (sort of)
So we use qpdf. Ghostscript's page splitting is supposed is less
efficient because it reprints the page (PDF -> Postscript -> PDF) and
possibly loses quality. qpdf's library could be used to improve
performance.
This causes a slight performance regression:
py.test tests/test_main.py::test_maximum_options went from 187 seconds
up to 192. This is likely due to O(n) serialized invocations of qpdf
compared to a single serialized call to pdfseparate. Could improve on
this situation by using the example code in qpdf: pdf-split-pages.cc
or create marker files in split_pages() and then write a new @transform
function that would split pages on each CPU. Probably not worth it,
overall, unless this causes problems on files with hundreds of pages.
Although the real issue was that the ruffus pipeline cannot be executed
twice in the same process due to its reliance on global variables.
The new OO pipeline in ruffus 2.6 would be one resolution that would
allow for more comprehensive testing as opposed to farming out the
execution to subprocess and inspecting the results, as is currently
done.
Specifically it trips over the need to reimport ocrmypdf.main. That in
turn raises questions about whether to make that function into an
external script that imports ocrmypdf... or something else. Would be
possible with a loop that manipulates sys_argv and then reloads
ocrmypdf.main; might need that anyway.
It's much better a rendering text baselines than hocr and seems to
produce small file sizes, so it's progress. Not available for
Tesseract 3.02 obviously, so both modes need to remove available.
Github supports both, and PyPI expects .rst files, so use .rst and make
everyone happy.
Auto-converted using pandoc
find . -name '*.md' | parallel pandoc --from=markdown --to=rst --output='{.}.rst' '{}'
http://bfroehle.com/2013/04/26/converting-md-to-rst/
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.
James R. Barlow
jbarlow83