PDF XChange Forum

When I run the OcrDelphiExample sample project in Delphi 2007/Windows XP, I sometimes get an divide by zero exception raised for certain input PDF's. Other PDF input files OCR just fine. The Delphi EZeroDivide exception comes from ocrtool.dll when the OCR_MakeSearchable command is executed. Can you tell me why I sometimes get a divide by zero exception?

Thanks

Jerry Kashtan

Very hard to say - can you supply an example PDF and advise if this always happens with this sample - please note all files must be zipped to be attached to a post.

thanks

Attached is a zip with three PDF files that cause the OcrDelphiExample application to fail by raising a Divide by Zero Error exception or an Invalid Floating Point Operation exception.

Thanks,

Jerry Kashtan

Files removed by system admin ......

Thanks Jerry,

I will ask our OCR dev to investigate on Monday - thanks for your patience.

I have removed for the files from the forum for confidentiality

Hi,

We are working on reproducing this to track down the source of the bug. I am not yet sure whether it is a problem with the core OCR library or the delphi wrapper portion, but will sort that out shortly.

Meanwhile, can you give a little more information please?

1. Do these documents always reproduce this behaviour, or is it sporadic?
2. What were the specific OCR settings you used? Language, DPI, auto-rotation (deskew), etc?
3. Can you provide the DLL version number (find ocrtools.dll in windows explorer, right click and select "Properties" and then the "Details" tab, and report the version information in "File Version". Should be in the format 1.0.x.x, for example 1.0.9.0 or 1.0.10.0).

Thanks!
-Walter

Hi Walter,

1. Do these documents always reproduce this behaviour, or is it sporadic?
[It is consistent in Delphi at runtime with the files I supplied.]

2. What were the specific OCR settings you used? Language, DPI, auto-rotation (deskew), etc?
[Language is English. I am using all the defaults in the Delphi example program. I did tweek the dpi and for a short
while it seemed to make a difference. When the dpi was higher 300 or more dpi, it sometimes worked without an exception being generated. Lower dpi's caused other PDF's to raise an exception.]

3. Can you provide the DLL version number (find ocrtools.dll in windows explorer, right click and select "Properties" and then the "Details" tab, and report the version information in "File Version". Should be in the format 1.0.x.x, for example 1.0.9.0 or 1.0.10.0).
[The dll version I have installed has the file version = 1.0.0010.0002 and is 7,482 KB in size. It was from a zipped distribution I got from Tracker back in September 2012.]

I have been unable to reproduce this issue with C++ using the OCR library, so I have passed this on to our Delphi people and will have a response soon.

-Walter

Hi Walter, any progress from your Delphi developer on resolving this issue? I need to get OCR working in my Delphi app so it can be released this month.

Thanks,

Jerry

Hello Jerry,

I've passed the topic to Walter, and he should post back here a bit later today!

Cheers,
Stefan

Do you have step by step instructions to reproduce this issue? Are you using your own code or testing with the example we provide?

Can you check your progress callback function, if applicable, to ensure you aren't inadvertently dividing by zero in there (e.g. by improperly setting the maximum-stage for a progress indicator or something)?

I commented out the SetCallback method and still get the divide by zero unhandled exception while in OCR_MakeSearchable. The option list that is passed into OCR_MakeSearchable is as follows:

lang=0
RegionMode=1
whitelist=''
blacklist=''
DataPath=<valid path to the PDF>
ImageFlags=1
raster_dpi=200
accMode=0

Are you using your own code or testing with the example we provide?

I am using the Tracker Delphi OCR example code. No modifications other than I recently commented out the callback method.

Jerry

Thanks. No luck in C++ (using the same DLL as provided with the delphi package) so we are actively trying to reproduce this with the help of the delphi guys, since it seems to be an issue with the example or wrapper.

-Walter

Refer to my earlier email where I provided a few PDF's that were causing the mischief.

Jerry

TrackerUser99 wrote:Refer to my earlier email where I provided a few PDF's that were causing the mischief.

Jerry

Yup, that's what we are using. No luck reproducing it with the C++ code (using the same ocrtools DLL), so it seems to be some interoperability thing with delphi that we will have to sort out.

I guess in the delphi example there is a place in the callback function where a divide by zero error can occur.

I was told that the fix is:

if frmMainOCR.FMaxLevel > 0 then
prc := dwLevel / frmMainOCR.FMaxLevel;

Hi Walter, I am not using the callback when processing but still get the divide by zero exception raised in the Delphi example code Tracker provided. This exception happens when opening many but not all PDF files in my set of test PDF's using the English language and dpi set to 300. It is a consistent error that prevents me from using this product. Can your Delphi developer send me a Delphi sample program that he/she feels works consistently with the PDF's I sent you? This is really important that I get a working OCR PDF app running by the end of this month.

Does Tracker have an updated OCR product at this time that I can download and test with?

Thanks,

Jerry

Please email support@pdf-xchange.com, attn: walter, and I will provide you with a new build of the ocr DLLs.

As mentioned I was unable to reproduce the problem with the ocr libraries myself, so I suspect it is a delphi specific problem, and the guys who handle this are very busy preparing the release of our end user editor this week. However I have incorporated some fixes to return an error code on certain types of malformed input that could result in a /0 exception, and there are some other miscellaneous minor bug fixes in the core OCR code. Once you get the new build this may help identify the problem.

We have uncovered the bug responsible for this exception and will update the distribution on our website. It was caused by an obscure case triggered by the input document "image0001.pdf".

I will also email you directly with the fixed build.

-Walter

Just a quick update; the downloadable live OCR package is now updated with the fix.

Fixed DLL version numbers are:

1.0.12.x

We will update the trial version installer soon.

I would like to update this post with report of a new fix which better resolves this problem.

A little background: in some algorithms, for example some of the fundamental OCR algorithms we use, it is preferable (for performance, and sometimes mathematical reasons) to ignore some floating point exceptions (e.g. divide by zero) when the "bad" results of these operations do not negatively impact the algorithm. Default behaviour in MSVC++ is to ignore these hardware exceptions thrown by the FPU, but Delphi applications do not suppress them.

The newest DLLs explicitly disable the relevant FP exceptions during algorithms for which throwing these exceptions is not desirable, and then sets the previous exception handling state after execution (so that exceptions in your own Delphi code will be handled as normal).

This change has been made in version 1.0.13.x of the ocrtools DLLs available on our website shortly (likely within an hour or so after this post). The live DLLs will be updated first, and demo versions in the demo installer will be updated as soon as our installer gurus can get this done.

We apologize to any users (Delphi users, in particular) who have been inconvenienced by this behaviour.

-Walter