Each installer is complaining that the other application must be installed first and the installation stops
I have OmniPage 18 Professional. On the scanner tab under Options there is a box that is grayed out and has a check mark in it. It says "Display Scanner Dialog Box". I don't want to display my scanner dialog box because I want OmniPage to scan continuous without me having to stop and click the scan button on the scanner dialog box. How do I uncheck this box?
Is the Flexara Software Manager (appears when checking for any available OmniPage updates) required in order to update OmniPro 18 or is it bloatware that I can remove?
One of our users here reports that her OmniPage context menu (right click menu) has disappeared after installing Adobe Reader.
Just to be clear, that is Adobe Reader, not Adobe Acrobat.
Acrobat - for whatever reason - is a standard application in our organization.
Acrobat was installed prior to installing OmniPage.
Both products coexisted without issue, with their respective context menu options.
Instead of seeing a context menu like this:
We're seeing something like this:
I've tried the following with no positive change:
Removing Adobe Reader isn't an option as its a requirement for some of the third-party sites our organization relies on.
Although we're still on OmniPage 17 and upgrading to the latest & greatest is something we want to do, and will get to in time, change in most [large] Enterprise environments is like steering the Titanic. So "upgrade to OmniPage 19" on a dime can't be the answer. This is clearly a normal feature that works and surely easily fixed by importing some registry keys.
That said: How do we get the OmniPage context menu (right click menu) back?
I bought a new PC running Windows 8.1 Pro.
I installed my copy of Omnipage Ultimate on it and the installation went fine.
But when I try to lauch it, I always get the same error message: "OmniPage 19 is unable to start! Error code: 8007007E"
I tried to repair OmniPage.
I tried removing and reinstalint OmniPage.
I tried manually adding the 6 required C++ dependencies.
Nothing works. I always get the same error message.
Anybody can help?
Do the batches I put through Omnipage for OCR need to consist of only PDF files, or will the program skip the other files of different types (like videos and excel sheets, word docs, etc.). In other words, if I have a large drive of files, and some of them are pdfs, do I need to sort them out first into folders with only the pdf files or can I send through my files "as-is" for the OCR feature. I have about 2TB of files that I need to make searchable but not all are pdfs.
Also, will the output retain folder/subfolder format directory? This is very important. I looked on the discussion forum and saw a couple of posts on this topic and one found a solution for the subfolder creation by using certain settings but another did not.
Thank you for your assistance & advice.
I am trying to convert a batch of about 1,400 scan PDFs (i.e., output of scanner) to text PDFs (i.e., searchable). Each doc is max 120 pages.
So I configured a "Normal" job in DocuDirect and let it cook on my win7 64bit desktop - nothing fancy but has multiple cores, 8GB of RAM, plenty of disk free.
It ran for about 27 hours, then stopped emitting new output files. The size of the OpAgent process is 1.8GB; the "*32" in the TaskManager name column makes believe it's a 32 bit process, so that's probably very near the max size. The size of the JobRunner process is 1.6GB; also has "*32". The processes not frozen, the DocuDirect screen responds to mouse clicks (slowly), but no new converted file has appeared for 36+ hours.
This is completely unacceptable. I suspect memory leaks.
Anyone else see anything like this? Any ideas??
Hi. I'm new to this forum and would like to know if anyone has encountered problems when executing a conversion with Omnipage 19 Ultimate.
In my case I'm trying to convert a 142 page pdf file into an excel file, but it generates a corrupt file that when tried to open shows the following message "Excel found unreadable content in <filename>. Do you want to recover the contents of this workbook? If you trust the source of this workbook, click Yes". If I click Yes, nothing happens, it only shows a message that the file cannot be opened.
I've had this program for just a few months, and never had this issue before (I don't use it continuously, though).
Any help is greatly appreciated.
Trying to do batch conversion from scan PDF to searchable PDF using OmniPage Ultimate (v19) on Win7. The original files are in a directory tree, nested down about 3 levels.
I define a "normal" job, configure the load files step, configure the recognize images step. Then I hit trouble with the Save step, the option "Use input file names with subfolders" does NOT stick.
I configure “Save Step 3 of 3” exactly as follows:
a. Select radio button Save As Text.
b. The File options dropdown should say, “Create a new file for each image file” and be disabled.
c. For Naming options, pick Use input file names with subfolders (THIS IS THE PROBLEM)
d. For File type pick “PDF (*.pdf)”
e. Under Prompting clear any checkmark in the box “Prompt for file saving name and location”
f. Under Save automatically with a specific name and location, click the Specify Location button and browse to a folder, then click OK.
g. Click Next to move on to the next step.
c. Click Back to go back and view Step 3 settings. Note that the option "Use input file names with subfolders" has CHANGED to "Use input file names". BAFFLING.
And if I let the job run, it writes all output files to the specified output directory, discarding the original directory hierarchy. I guess this is consistent with the setting "Use input file names".
Anyone else try this, or see this?
Version: OmniPage 18.63
When creating a Word document, we are supplying metadata for Author, Subject, Title, etc.
These are created correctly for Word 97, 2000 formats, but not for DOCX.
The output converter is "Converters.Text.DOCX" the setting key we are using is "Converters.Text.DOCX.DocAuthor".
"Converters.Text.Word2000" successfully sets the metadata.
Is this a known issue? Should we be using a different key ?
Please help !