#15 Direct Use of a Scanner

[Alan Pierce]

It would be cool if STIHRS was able to directly use a
scanner and recognize text from that image. This would
make it so the user doesn't have to open up a separate
application in order to use scanner data. It also would
make the scripting system included in STIHRS much more
powerful.

[oldspammer]

Logged In: YES
user_id=1602727

http://www.codeproject.com/audio/twaintest.asp?print=true

Twain sources come in two flavors: 16-bit and 32-bit.
Carrying the data between these involves thunking. Lots of
the older, cheap, used scanners used a Win98 compatible 16-
bit Twain source.

Twain sources are a combination of Acquiring UI and scanner
drivers that usually fetch a bitmap into memory for your
own app to process somehow--save to a file, edit it,
recognize, whatever.

These Acquiring UI / driver combinations CAN and DO crash
in non-gracious ways.

Twain scanner access selects the twain source, and also an
Acquire function is triggered from "your application."

During Acquire, your application hands over all of the MS-
Windows messages (nearly) to the activated Scanner Acquire
user interface application as a called DLL function within
your process space.

Should the Acquire UI / scanner driver cause a Segmentation-
fault / crash, it will bring down your application too.

In order to circumvent these troubles, I wrote one
application that performs the Acquire and saves the
acquired image files as packbits / RLE (lossless compressed
color) TIFF files in a pre-determined directory. The other
application is the main one. The main application that I
did not want to crash only does a CreateProcess( ) Win32
function call to activate the image acquire application
that could crash. If the return code was good--OK, but if
the return code was bad or the process ID of the acquiring
application died/was killed, etc, then the main application
would know. The main app would go to sleep for 1/2 second
intervals and then check the other process' health, then go
back to sleep if all was well. To confirm that your
acquire application is actually getting a nice image, I
suggest that you use the CPictureHolderEx( ) class or
similar.

http://www.google.com/search?
num=20&hl=en&lr=&newwindow=1&q=CPictureHolderEx Resizable
Image display control.
http://www.google.com/search?
num=20&hl=en&lr=&newwindow=1&q=site%
3Awww.codeguru.com+twaintest Twain Acquire sample source
code.
http://www.codeproject.com/bitmap/cximage.asp?
df=100&forumid=2472&exp=0&fr=51&select=1217075 Graphics
file format support for reading, writing, conversion, etc?

The CPictueHolderEx( ) class can display a dynamically
resizable image in your acquire image application so that
you can see what you're getting in. When all is working,
you can have this acquire application minimize itself while
it automatically operates / interacts with the twain
source's UI GUI / scanner driver.

I found it best to presume that the scanner acquire
CreateProcess( ) was always a 16-bit application, even if
it was not since that method works universally on both 16
and 32 bit CreateProcess( ) Win32 function calls.

The sequence of calls to perform the actual scanning
activation I did via a sequence of Timer call back function
invocations that would call twain functions in the
appropriate sequence to setup then do the scan / acquire.

Multiple image files had to be automatically given names.
I created a filename creation function based on the login
user's name / domain and a date time stamp that was
accurate to the millisecond (a double long value) both
halves of which I sprintf( )'d converted into hexadecimal
into the file's name.

Should a crash happen, all of these scanned files would not
have to be redone and their ownership and date/time
sequence would be preserved by the filenames nicely
assigned to them.

Libtiff is useful. It is also possible to use a primitive
BMP saving program too, but the disk can get pretty full if
dealing with uncompressed 24-bit color BMP files
accumulating. If you want, PNG is also another nice format
with better compression. Zip-compressed TIF files are
currently less likely to be opened or thumbnailed by
Windows or a third-party graphics program, so use PNG if
you want Zip-deflation compression. The new JPEG-2000
lossy or lossless format would be fine too depending on
your need for disk economy versus speed of saving.

Once the scanning is completed successfully, the Acquiring
application closes itself gracefully and returns a zero (no
errors happened) status code. The main application will
get this return status code, and find all kinds of nice
acquired files on the disk done by the current user name
person. Because of the nice naming convention, it is
possible to use the disk space of a huge file server shared
with other users since name conflicts should never happen.
The directory default name could be stored as part of an
INI or a system or user registration database null
terminated string entry.

As each file is used in the main application, it can be
renamed, erased, converted to another file format, sent to
the recycle bin using the shell API functions or moved to
some kind of done directory / folder (so that the user can
re-process the same image without having to re-scan /
acquire it again).

When I downloaded the code project MFC C++ source code
application, I found that one of its critical functions
returned 0 or a 1 when it should have done the opposite.
If I recall correctly, this makes the acquire quit
prematurely? I think that someone in the comments on the
project says as much, but I don't remember the details
because I dealt with this in 2001-2002 time frame.