> From: Mark McLaughlin
>
> Hi Oliver...
>
> First off, my apologies for slowing down the pace of the discussion.
Hello Mark,
No probelm,
I also have to read and answer some of your mails because I do not have
always the time for it.
> 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.
Ok, now I understand it better.
>
> 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.
I think we really have to split this question into
Windows, Max and Unix questions.
For Windows and Mac I would suggest not to
change the TWAIN Source Manager. I think it is ok
if there are sane1.ds, sane2.ds,..., saneN.ds.
This way sane.ds also works with older
TWAIN versions!
For Unix we have to talk about the communication
(messages/events) between the apllication and the
source manager/driver at first.
Andreas and I already talked a bit about it, please could
you explain us a bit at first:
1) Are the events that are sent from the application to the
source manager and the driver only window events
(redraw window, button pressed, ...) or are there
any other TWAIN relevant events that are sent from
the application to the soruce manager or driver?
If the source manager and the driver run as an own
process that gets it own window events (for unix),
do we need the events from the application to the
source manager and driver any more?
2) The handling of the events from the driver to
the application are already handled different for
Windows/Mac. So it would not break a standard
if we define an own event system for unix?!
We do not want to froce the usage of one graphics toolkit
for the applications and we do not want to force the usage of
X if this is not really necessary. So we talked about the usage
of pipes for the message flow from the driver to the application.
> Okay...last bit. I would like to be involved in any coding
> effort.
That is very good.
> 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.
Do you have an application in mind that already is ported to unix
but without TWAIN support?
> 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...
If the question with the messages/events is solved,
I think it is not a great problem to do this.
> 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...
I do not have a sample backend code.
The small sources I know (e.g. pnm backend)
are not very good as a sample code.
The umax backend is very big (about 6000 lines)
but if you only take a look at the sane routines
(sane_start, sane_read and so on) it is better
than nothing.
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