> From: Mark McLaughlin
>
> 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
-- 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