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