is there a static CLI binary?

Mar 11, 2011 at 1:32 PM

Hi,

 

I'd like to use Puma.NET from a Windows service to mass-process lots of images. For that I need a statically linked (no DLLs, no install needed) CLI version of Puma. I'm not able to compile that myself.

 

Great would be something like that:

pumacli -i infile -o outfile

with optional parameters for everything that Puma supports, like language setting.

 

Hope to hear from you soon,

 

best regards from Germany

 

Florian

Coordinator
Mar 11, 2011 at 1:45 PM

Unfortunately Puma.NET is not a pure managed library and has a strict dependency on COM server and unmanaged DLL. Until COM server is registered and dibapi,dll is put to folder where it can be found by application, consuming pumanet.dll assembly there's little use from Puma.NET.

Mar 11, 2011 at 2:25 PM

Tanks for the fast answer!

 

So let's suppose I manage to build a small CLI .net program which basically opens $args[0], OCRs that picture and saves the result als $args[1], which files do I need to run that program on another host? How do I deploy a program which uses Puma.NET?

Please excuse my stupid questions, but I'm a unix guy and have almost no idea how Windows works and what a "COM server" is.

 

best regards from Germany

 

Florian

Coordinator
Mar 11, 2011 at 2:42 PM

Let's have a look at it from a different side. As far as I understood you'd like to have a Windows service running in background and doing some OCR. You see the OCR part done via some console utility which is executed by the service. The util gets input and output file names as parameters, does recognition and saves results. If that's the case then that's what you need:

1. Create the console util referencing pumanet.dll assembly and having all the code needed

2. Prior to using the util Puma COM server to be registered and dibapi.dll to be put to the same directory as the util

After it's done the util can be executed via command line. More infor on COM execution and Puma.NEt itself can be found in the documentation tab. Also the source codes of the sample application  are quite straightforward (for .NET developer).

 

Mar 11, 2011 at 2:52 PM

Another question :-)

 

Which file format works best (currently: tif)? Which resolution (current: 300dpi)? Which color-depth (currently: 1bit)?

If your answer starts with "that depends on the source ...", my sources are:

- 1980's typewriter b/w

- scanned color magazines

lots of multipage PDFs converted to what ever ghostscript supports and you suggest works best, one image file per PDF page.

 

The programs looks like this:

using System;
using Puma.Net;

namespace PumaOCR
{
    class Program
    {
        static void Main(string[] args)
        {
            var pumaPage = new PumaPage(args[0]);
            pumaPage.FileFormat = PumaFileFormat.TxtIso;
            try
            {
                pumaPage.RecognizeToFile(args[1]);
            }
            catch (Exception e)
            {
                Console.Error.WriteLine(e.Message);
            }
        }
    }
}

Mar 15, 2011 at 9:03 AM

OK, with the help of expert on those matters (aka google) I managed to compile a CLI binary which seems to work well.

Recognition results are really impressive!

That still leaves the question of the optimal input format, though.

 

Best regards from Germany

Florian

May 9, 2015 at 6:50 AM