Only one OCR'd PDF is created when running the OCR workflow on an item with multiple PDFs

[andrewjbtw]

When we started working on the OCR workflow, we had not yet supported multiple PDF display in the viewer and unfortunately did not test that case. I recently tested it on a sample item in QA and learned that we have a few problems handling multiple PDF:

• the auto-generated filename pattern for the ABBYY-created PDF is too generic, making it impossible to store more than one OCR'd PDF
• the resource label that appears in the viewer is also generic and obscures which of the multiple "original" PDFs corresponds to the OCR'd PDF

In that example, the OCR'd PDF is the last resource in the list:

• label: PDF (with automated OCR)
• filename: zj915gz4357-generated.pdf

We need new strategies for both the filename and the resource label that can accommodate multiple PDFs. We also need to determine how to set the order in the file list. One option would be to alternate between the original file and the OCR'd PDF in the sequence, rather than put all the OCR'd PDFs below all the original PDFs.

[peetucket]

I'm trying to remind myself of how document type OCR works. Looking through the code, it appears to send to any and all PDFs to ABBYY, and then fetch the resulting PDFs from ABBYY for adding to the object. In that example object, the last single PDF with the name of the druid in it is a combination of all of the other PDFs, and I suspect it was created by ABBYY...which is why there is only ever one per object? Is there some configuration that ABBYY has with regards to how it handles PDFs? We do have some logic in our code around how it ignores the single large XML file produced and how it adds the final combined PDF to the object, but otherwise there aren't many assumptions in common-accessioning.

[andrewjbtw]

Good catch on that last PDF. I didn't realize it was all the PDFs and not just the first.

I'm now guessing that ABBYY actually combined all of them. I don't think that was a case we tested for PDF input, but the ABBYY settings we use for image input aggregate everything in the input folder, and probably that's the same for PDF.

It is possible to get one output file for each input file - the Goobi-ABBYY configuration does this currently - but then you have to aggregate all the files to get a single combined PDF. The one file per input and the one aggregated file options are mutually exclusive. One thing we could consider is having PDF input produce individual files and image input continue to produce an aggregated file.