PDF OCR from LabVIEW?

[Bryan]

Hey guys/gals.  Long time member/infrequent poster here with a PDF challenge to share.

I'm working on modifying some old LabVIEW code for an internal customer where reports generated by the compiled EXE are essentially LabVIEW FPs that are printed to a PDF printer.  I've been asked to streamline the process by preventing the prompt for filename/location for each report that is "printed", (and there are many) as well auto-generate the PDF filenames. 

The problem I've run into is that in using the LabVIEW PDF toolkits that I've found on VIPM and NI's website - the FPs are added to the PDF files as images whereas by using a PDF "printer" to print the FP, it appears that an OCR engine is used to break up the FP image into images and searchable text.  Having searchable text is what the customer wants to keep if possible. However, with the level of control they're requesting for PDF generation, I'm having a difficult time finding a solution that can be done in LabVIEW and meet all of the requests without changing the report generation scheme from FP "printing" to an actual proper report scheme... which they don't want me to do. 

I could dig into finding out more details about programmatically controlling their "PDF Printer" from LabVIEW, but I would prefer the application not to be coupled too tightly to a 3rd party application that could change or disappear at any time. (Gov't Contractor).

Anyone have any ideas?  It would be nice if the available PDF toolkits out there had some sort of OCR function for images if they contained text.

If this is too much of a pain to do, I may just have to tell them it will have to be one way or the other.   I love LabVIEW programming, so if I can do it I will.

[ned]

Sorry I don't have an answer for you, but I do want to clarify that there's no OCR happening. Instead, when LabVIEW prints the front panel, it sends the text portion to the printer driver as text, with coordinates as to where that text should go on the page. This allows the printer to use information from the font to take advantage of the full printer resolution, making the text look cleaner. It also allows a printer driver such as for PDFs to include text as text rather than as part of an image. LabVIEW also provides a "Get Front Panel Image" method which is what I assume is used by the LabVIEW-specific PDF drivers, and in that case it's retrieving the entire front panel as a single image which includes all the text.

While I understand your desire not to be tied to a single PDF printer driver, the best route is probably to research the available PDF printer drivers and find one that provides the features you want.

[Bryan]

Thanks for the clarification!  It's nice to know more of what's going on under the hood when LabVIEW sends a FP to a printer.  I just assumed that it was automatically doing some sort of OCR.  Thinking back, when I generated a PDF with a FP as an image, the OCR wasn't very reliable.  That should have clued me that something else was going on instead of OCR.

This is really the first time I've had to deal with PDFs and LabVIEW together. I've always wanted to mess with the PDF toolkits for LabVIEW, but in the applications I'm dealing with at work, I haven't really had the opportunity to date.

[hooovahh]

For PDF generation I've been using this toolkit for several years and love it.

https://decibel.ni.com/content/docs/DOC-10952

It has the ability to paste in front panels, and individual controls, but it also can just add a table, or text, as normal PDF tables and texts, that can be selected.  No PDF printer needed.

[Bryan]

I checked out the Exaprom toolkit a bit last week.  I agree, it has a lot of really neat features.  If I can convince the customer for more time and budget for a better PDF solution than just printing the FPs to a virtual printer to maintain the separation of text and images, I may use the Exaprom kit to do so.  Thanks!