Hi Oliver...
Here are my responses to your last message...
>>> [regarding a generic TWAIN using SANE Source]
>>>
>>> This sounds very good because TWAIN on UNIX will be able to
>>> support all scanners / image acquiring devices that are supported by
>>> SANE. SANE will benefit from this because the scanner
>>> manufacturers will give better support to the SANE developers
>>> (e.g. documentation about their protocols, hardware for doing some
>>> tests).
>>> If TWAIN does support the generic source that talks to SANE drivers
>>> on Windows/Macintosh, we will be able to use a scanner that is
>>> connected on a UNIX system and the TWAIN-GUI runs on a
>>> Windows/Macintosh platform. That would be a benefit for a lot
>>> of users because they can share one scanner for
>>> UNIX/Windows/Mac.
I agree, there is definately value in being able
to use remote scanning. And as long as the TWAIN
Source is running on the local machine in this
model, there is no added burden from the existence
of the TWAIN GUI. TWAIN would pick up a nice new
feature merely by using SANE, with no changes to
either interface...
>>> [regarding a SANE driver using TWAIN]
>>>
>>> It would be nice if this would work one day.
>>>
>>> If I understand it right there are "generic" GUIs for TWAIN
>>> that are not positioned in the source driver level - right?
>>> Are these GUIs positioned in the Application layer or in the
>>> source managaer layer?
>>>
>>> Would it be necessary to write an own GUI for the generic
>>> SANE source driver?
Actually, it could be done today. The problem is
that many Source's do not offer the programmatic
control to make it as clean as one could hope.
In part this is because of TWAIN's success. We
are fully compatible from TWAIN 1.0 to TWAIN 1.8
on the Source and application sides. This means
that Sources written years ago are still quite
viable today. Still, there are a growing number
of Sources being written now that would probably
work quite well as backends to SANE, so it may be
worth considering a generic SANE using TWAIN driver...
As for the GUIs. TWAIN offers extremely minimal
advice on the design of the GUI. Which is why they
all look so different. There is no standard design
for a TWAIN GUI, and the only ones that exist
independent of a Source are in the applications, and
there are no standards driving them, either...
As for the TWAIN-using-SANE and SANE-using-TWAIN
generic drivers. In the first case there would be
a GUI provided in the TWAIN layer. This GUI would
be common to all devices for that Source. There
would be no device specific GUI from the SANE
layer (unless there is a mechanism for doing this
that I am unaware of). In the SANE-using-TWAIN
case the TWAIN GUI would be supressed (unless there
was a model allowing it to be raised which was
permitted and made sense). However, even though
the GUI would be supressed, TWAIN is driven by some
kind of windowing-system messaging loop. The generic
SANE driver would therefore require the presence of
a windowing system in order to run. This is not a
problem, of course, for running SANE on WIN32 or
Macintosh platforms, since the windowing system is
integral to the setup...
>>> [regarding SANE as a platform independent HAL communication layer]
>>>
>>> Normally there are no OS dependend #ifdef's in the backend sources.
>>> There is a common interface for scsi communication (sanei_scsi) used
>>> by all backends. In sanei-scsi there are the OS dependend #ifdef's
>>> that make sure that the backend authors do not have to care about
>>> the OS.
>>> The only machine dependant thing the backends have to care about
>>> is the endianess of the machine on which the backend is running.
>>>
>>> For parallel scanners there is no common interface because there are
>>> only a few parallel scanners supported due to missing documentation for
>>> parallel port scanners.
>>>
>>> The support for USB scanners is not so simple because there are no
>>> generic USB drivers for most UNIX platforms.
Adaptec's Advanced SCSI Programming Interface (ASPI) is the
de facto standard for SCSI communication on Windows platforms.
Microsoft has presented their Still Image Technology (STI)
as a replacement for ASPI. So there are no lack of standards
there. :) I would expect Macintosh to have a stanardized
mechanism for SCSI, so modifying the SANE backend to deal with
each of these alternatives should not be overly burdensome.
There is currently no standard for deal with parallel driven
scanner drivers. So tackling this area would most likely
continue to be a problem.
As for USB, it is well defined on WIN32 and Macintosh. It
would be nice to see some effort towards standardizing access
to it on UNIX, since it is the physical connection for small
scanners and digital cameras for the foreseeable future. The
fact that WIN32 and Macintosh have standardized ways of
accessing USB means that a SANE driver on those platforms
could leverage off that advantage today.
>>> I don`t know anything about scsi-communtication on Windows
>>> and Macintosh platforms, but I don`t see any problems to add
>>> support for them to sanei-scsi.
>>> SANE already works (at least a bit) with OS/2.
>>>
>>> May be we have to do some minor changes in some backends
>>> to make them work on Windows/Macintosh platforms, but that
>>> shall not make big problems.
Unfortunately my technical experience with SANE is very
limited at the moment. I have perused the website and
gathered some information on it. I would be very
interested in any recommended sample code that I could
see, as that would significantly increase my understanding
of SANE, as well as give me a better idea of how far away
we are at an engineering level from achieving some of the
ideas we've discussed these last two days...
Many thanks for your reply Oliver. And let me take a
moment to say thanks again to Andy and Petter for their
comments. I was not sure how this interaction between
our groups was going to develop, and while there is a
lot to learn and do, I appreciate the time you are all
taking to investigate this opportunity...
If you get a chance, could you describe to me please the
layout of the SANE group? Do its members ever meet? Is
it an official entity (in the legal sense) in any way
(that is, with elected officers, keepers of documents,
code, etc)?
The question is only to sate my curiousity (I've this
feeling that if these discussions proceed to their
potential outcome that I will be writing a SANE driver
eventually)... :)
The TWAIN Working Group is a consortium of companies. We
are a not-for-profit group. We meet quarterly and have
weekly conference calls. There are currently five
sub-committees: marketing, macintosh, technical, toolkit
and testing, and they each have their own tasks and
weekly conference calls.
Mark McLaughlin
Eastman Kodak Company
716 726 1352
mlm@kodak.com
Oliver Rauch <oliver.rauch@wolfsburg.de> on 08/11/99 06:08:32 PM
To: Mark McLaughlin/252353/EKC
cc: SANE-MAILLING-LIST <sane-devel@mostang.com>
Subject: Re: Discussion about SANE and TWAIN...
Hello Mark,
thanks for your answer.
252353N@knotes.kodak.com wrote:
> From: Mark McLaughlin
>
> Hi Oliver...
>
> Many thanks for your reply.
>
> I'm glad that you also see a benefit from this interaction between
> SANE and TWAIN. The fact that TWAIN's user base is expressing
> an interest in UNIX is a little daunting in some ways, since not many
> of the current TWAIN members are doing anything with UNIX.
> So one of the opportunities we see from working with SANE is a
> chance to draw on your experience and expertise.
>
> As stated in my first message, I believe the principle benefit from
> SANE and TWAIN working together is a chance to help app
> writers cross from one OS to the other with less effort than it takes
> today. So, TWAIN runs on UNIX, SANE runs on Windows, and
> application writers have one less component to worry about
> when trying to build their source code on an alternate platform.
>
> Bearing that in mind, I propose that on UNIX TWAIN runs in
> communication with a generic Source that talks to SANE drivers.
> We would have to make some minor changes to our Source
> Manager to allow this to work properly, but such a TWAIN Source
> would be able to communicate with any SANE supported image
> capture device.
This sounds very good because TWAIN on UNIX will be able to
support all scanners / image acquiring devices that are supported by
SANE. SANE will benefit from this because the scanner
manufacturers will give better support to the SANE developers
(e.g. documentation about their protocols, hardware for doing some
tests).
If TWAIN does support the generic source that talks to SANE drivers
on Windows/Macinthos, we will be able to use a scanner that is
connected on a UNIX system and the TAWIN-GUI runs on a
Windows/Macintosh platform. That would be a benefit for a lot
of users because they can share one scanner for
UNIX/Windows/Mac.
> At this time I don't believe there is much to be gained from having
> a generic SANE driver that talks to TWAIN. Technically it is very
> doable, but TWAIN Sources have a history of relying heavily or
> even exclusively on their internal GUIs, which doesn't fit well into
> SANE's programmatic design. We are working to change this
> behavior (and have been since TWAIN 1.7 -- 1997), so in the
> future it might be advantageous to do this.
It would be nice if this would work one day.
If I understand it right there are "generic" GUIs for TWAIN
that are not positioned in the source driver level - right?
Are these GUIs positioned in the Application layer or in the
source managaer layer?
Would it be necessary to write an own GUI for the generic
SANE source driver?
> One question I have regarding SANE has to do with writing drivers
> for mulitple UNIX platforms. Writing a 'single' device driver for
> Solaris and AIX and Linux, etc must be appealing to some device
> manufacterers (nobody wants to have write one driver per OS for
> their device). Has SANE investigated an abstraction between
> it's interface and the actual communication with the OS? I'm kind of
> looking for something like ASPI (though wire independent). The
> idea being that me, as a driver writer, would be able to write a
> SANE driver that with a minimum of #ifdef's would be buildable on
> UNIX or Macintosh or Windows platforms.
Normally there are no OS dependend #ifdef's in the backend sources.
There is a common interface for scsi communication (sanei_scsi) used
by all backends. In sanei-scsi there are the OS dependend #ifdef's
that make sure that the backend authors do not have to care about
the OS.
The only machine dependant thing the backends have to care about
is the endianess of the machine on which the backend is running.
For parallel scanners there is no common interface because there are
only a few parallel scanners supported due to missing documentation for
parallel port scanners.
The support for USB scanners is not so simple because there are no
generic USB drivers for most UNIX platforms.
> If such a mechanism could be created, I would have a very good
> reason for running SANE on Windows and Macintosh platforms...
I don`t know anything about scsi-communtication on Windows
and Macintosh platforms, but I don`t see any problems to add
support for them to sanei-scsi.
SANE already works (at least a bit) with OS/2.
May be we have to do some minor changes in some backends
to make them work on Windows/Macintosh platforms, but that
shall not make big problems.
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