Hi Oliver...
First off, my apologies for slowing down the pace of the discussion.
Things at work have heated up and I've had to attend to other
stuff, which is causing me to fall behind in replying to all these
interesting messages...
Anywho, here are my comments for this message...
First off, a simplified view of the way TWAIN is organized...
+-------------+
| Application |
+-------------+
+--------------+
| TWAIN_32.DLL |
+--------------+
+--------+ +---------+
| abc.ds | | xyz.ds | ...
+--------+ +---------+
The application loads the TWAIN Source Manager
( TWAIN_32.DLL) into memory with a LoadLibrary()
call. It then gets a pointer to the DSM_Entry() function
inside of TWAIN_32.DLL using GetProcAddress().
All communication with TWAIN is done through
DSM_entry().
When the application requests it, the Source Manager
discovers the available Sources by searching for
any files with the extension ".ds" in either the
%windir%\TWAIN or %windir%\TWAIN_32 directory
(the search is recursive down the directory tree).
The ".ds" files are really DLL's. The Source Manager
loads each one in turn with LoadLibrary() and looks
for the DS_Entry() function. If uses that call to find out
the identifying information for the Source, which is
bubbled up to the application so that it can select
which Source it wants to use. Once a Source is
selected and opened, the Source Manager acts
primarily as a passthru until the application indicates
that it wants to close up the session.
Now, as for this sane.ds thingy. With a change to the
Source Manager, we can modify the diagram above
to look like...
+-------------+
| Application |
+-------------+
+--------------+
| TWAIN_32.DLL |
+--------------+
+--------+ +-------+ +------------------------------+
| aaa.ds | | bbb.ds| | 'sane.ds' [aaa.ds bbb.ds...] |
+--------+ +-------+ or +------------------------------+
+-----+ +-----+ +-----+ +-----+
| aaa | | bbb | | aaa | | bbb |
+-----+ +-----+ +-----+ +-----+
One way of connecting to a SANE driver is to write a
generic TWAIN Source and copy it, so we get
aaa.ds and bbb.ds which are identical code, but
which interface with two different SANE drivers. The
benefit of this is that no changes have to be made to
TWAIN as it stands to make this work...
The sane.ds notion involves the creation of a new
kind of Source, one that can enumerate a list of
identities. This would allow the one Source to show
a list of any number of SANE devices. I like this
model more, but it would require a change to the
TWAIN Source Manager to make it work. Since we
are targeting UNIX with this change, it shouldn't be
too much of a problem. And it should be possible to
craft this in such a way that only the Source Manager
is affected. Applications would never know the
difference.
Okay...last bit. I would like to be involved in any coding
effort. I've many years of UNIX and Windows programming
in my past, so I feel it's something that would be fun to do.
However, I'd be lying if I said I have a lot of time to play
with right now, so I'm not sure how much of my time I will
be able to commit at this point.
What I am going to do is look over the Windows version
of the TWAIN Source Manager and access how much
effort is needed to abstract out the WIN32 portions into
something that could run on UNIX. Once I have that
accessment in place, we can try to decide on who is
going to do it (and if I can scratch out the time, then I'll
do what I can).
As for the application, I would very much like to use some
third party package to see if we can build and run our
WIN32 test program on UNIX. I see this as a proof of
concept, that someone could move their WIN32 app to
UNIX with a minimum of effort. If this works out, then we'll
have our app without too much effort.
The only code remaining then is the SANE.DS (and I
would recommend going for the simple version of this
first). This would be a TWAIN Source this is capable
of negotiating a couple of image processing parametes
(like resolution and contrast) and transferring an image
from a SANE driver. Most of the work will be spent on
this code, I think...
Anywho, those are my ideas. I've not had enough time to
really dig into the SANE code the way I want to. If you
have some samples you can share they would be much
appreciated...
-- Mark
Oliver Rauch <oliver.rauch@wolfsburg.de> on 08/17/99 12:38:31 PM
To: Mark McLaughlin/252353/EKC
cc: SANE-MAILLING-LIST <sane-devel@mostang.com>, "Beck, Andreas"
<becka@sunserver1.rz.uni-duesseldorf.de>
Subject: Re: Starting a discussion about SANE and TWAIN...
252353N@knotes.kodak.com wrote:
Hi Mark,
> TWAIN doesn't really have any layers. At it's most
> abstract description TWAIN is nothing more than an
> elaborate conversion API between a standard name
> space to a set of arbitrary native commands for some
> given device.
Yes, but which parts are bonded together?
If I understand it right there is one source manager
on a system. If we have two different scanners with
two different drivers (sources), this source manager
gets contact to the one or the other driver.
I am able to select one source from one application
and the second source from another application.
Or is the source manager included into the application
and each application has its own sourcemanager?
How is the contact done, is the driver a library that is
loaded on runtime?
> This is why the notion of a sane.ds file is so appealing
> to me.
sane.DS? Did I miss a mail?
> In this model TWAIN becomes an application
> using SANE, and should therefore receive all the
> benefits that any application using SANE would expect
> to receive.
Yes, and I don`t think it is a problem to add a
TWAIN interface to an existing sane frontend.
> However, if the sane.ds has the intelligence
> to discover SANE devices on the network, then we gain
> remote scanning control with no change to the TWAIN
> spec (and more importantly, no changes to any TWAIN
> applications).
That is no problem, there is no difference for the frontend if
it connects to a local backend or to the network backend
that connects to a remote scanner.
> I guess that's fundimental to my current notion of the best
> implementation of a TWAIN using SANE and SANE
> using TWAIN system. How much can we do to enable
> applications access to more image capture devices
> across more platforms, and do it with the applications
> changing little or no code.
Are you interested in programming code for unix,
especally to implement the source manager and
a test application? Of course we will work together
but we need somone who is familiar with TWAIN.
Andreas Beck and me also need help for creating
the interface between the source selection manager
and the sane frontend.
Do you like to do this and do you have the time for it?
Andreas and I talked how the communication by
events between application and source can be
implemented on unix.
It looks like there are already differences between
Windows and Mac.
I have to read the TWAIN standard at first, but it will
take a while (>500 pages and less time).
Do you already have the sane standard and source code
example (you can download it from the sane homepage).
If you have problems to read the formats of the files/archieves,
let me now and I will convert them for you!
Bye
Oliver
-- EMAIL: Oliver.Rauch@Wolfsburg.DE WWW: http://www.wolfsburg.de/~rauch
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com