5/26/2023 0 Comments Pdfkit problems![]() Lookup was unsuccessful because: a) text selection through force-click/three-finger tapping/double clicking on a word failed because there was no text that could be intelligently identified as word.Copying and pasting did not produce any text, or produced results that were garbled.Searching the document for any string returned no results (reproduced in several PDF applications).They were initially done in purest of my usual daily tasks.)Īfter I made an annotation that resulted in DTPO saving the file, in addition to the Log warning: (these are all more or less typical aspects of my day-to-day PDF workflow, so they were not initially done as a troubleshooting thing. using macOS’s “Lookup” feature, which correctly selected both the image and the text layer and produced appropriate results.copying and pasting text which produced pasted text that was accurate to the image of the text.searching to for text which returned results that indicated accurate OCR.I confirmed that the OCR Layer was initially in tact by: Is this just part of the ongoing PDFkit issues? Is this a new Did you confirm the contents of the image layer by converting the PDF to plain text or just visually deduce it was fine by selecting text? I can’t trust DTPO as a PDF viewer if it, or the frameworks it relies upon, can corrupt OCR layers! Thankfully opening files in an external application is easy, but its all-too-easy to, on a whim, quickly open a PDF, modify it in some way that causes it to auto-save, and BAM, OCR gone. I had to restore the document from a backup to retrieve an un-corrupted version. The document could not be searched, anything selected was just blank characters, etc. Indeed, I confirmed using all of the above applications that the OCR layer was now toast. After making the first highlight, the application hung (beachball), then the Log window appeared with row indicating “No Text” for the presently-open file. I had confirmed that the OCR layer was present and accurate (using PDF Expert, Safari, and finally, in DTPO, but NEVER preview). ![]() ![]() The PDF in question was a scan that had been made and OCRd by someone other than me (I don’t know the provenance). The issue occurred on macOS 10.13.4 with DPTO 2.9.17. I know that PDFkit has been a mess, and I’ve lost track of whether DTPO is, or is not, relying on PDFkit by default these days.
0 Comments
Leave a Reply. |