kopia lustrzana https://gitlab.com/sane-project/website
176 wiersze
8.2 KiB
HTML
176 wiersze
8.2 KiB
HTML
<!-- received="Wed Aug 11 10:35:11 1999 PDT" -->
|
||
<!-- sent="Wed, 11 Aug 1999 19:31:25 +0200" -->
|
||
<!-- name="Andreas Beck" -->
|
||
<!-- email="becka@rz.uni-duesseldorf.de" -->
|
||
<!-- subject="Re: Starting a discussion about SANE and TWAIN..." -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="852567C9.006B9C36.00@knotes.kodak.com" -->
|
||
<title>sane-devel: Re: Starting a discussion about SANE and TWAIN...</title>
|
||
<h1>Re: Starting a discussion about SANE and TWAIN...</h1>
|
||
<b>Andreas Beck</b> (<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a>)<br>
|
||
<i>Wed, 11 Aug 1999 19:31:25 +0200</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#93">[ date ]</a><a href="index.html#93">[ thread ]</a><a href="subject.html#93">[ subject ]</a><a href="author.html#93">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0094.html">Hugo van der Kooij: "Re: a few questions"</a>
|
||
<li> <b>Previous message:</b> <a href="0092.html">Oliver Rauch: "Discussion about SANE and TWAIN..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
Hello,<br>
|
||
<p>
|
||
<i>> My name is Mark McLaughlin, and I am the current Chairperson</i><br>
|
||
<i>> on the TWAIN Working Group Technical Sub-committee. I am</i><br>
|
||
<i>> sending this message to the manager for the SANE website in</i><br>
|
||
<i>> the hope that it will reach the appropriate people.</i><br>
|
||
<p>
|
||
I think it did. Thank you for contacting us.<br>
|
||
<p>
|
||
<i>> There is growing interest (as viewed on our mailing list) for</i><br>
|
||
<i>> seeing TWAIN support on UNIX platforms, particularly on Linux.</i><br>
|
||
<i>> This interest has finally reached a level where the TWAIN</i><br>
|
||
<i>> Working Group feels it needs to investigate the possibility of</i><br>
|
||
<i>> adding support for UNIX.</i><br>
|
||
<p>
|
||
This is good news. The original reason for the development of SANE was the<br>
|
||
lack of commercial drivers for the various Unix platforms we cover.<br>
|
||
<p>
|
||
If TWAIN would start an effort in this direction, this would mean setting a<br>
|
||
signal towards the manufacturers, that this is an interesting market worth<br>
|
||
developing drivers for.<br>
|
||
<p>
|
||
<i>> We are interested in this because we believe there is an</i><br>
|
||
<i>> opportunity to help developers of image capture systems</i><br>
|
||
<i>> on UNIX, WIN32 and Macintosh platforms leverage their</i><br>
|
||
<i>> code run on one or more or the alternate platforms.</i><br>
|
||
<p>
|
||
Yes. The variety of platforms on which SANE runs shows, that it is possible<br>
|
||
to easily write code that is portable across platforms, if you have a decent<br>
|
||
abstraction layer towards the hardware and towards the frontend (windowing<br>
|
||
system).<br>
|
||
<p>
|
||
<i>> TWAIN has no intention of competing with SANE. Rather we</i><br>
|
||
<i>> wish to investigate a chance to employ the strengths of both</i><br>
|
||
<i>> standards. We are not against the idea of seeing SANE</i><br>
|
||
<i>> running on WIN32 or Macintosh platforms, and if there are</i><br>
|
||
<i>> ways we can help SANE achieve this we would be happy to</i><br>
|
||
<i>> discuss them. It is important that both groups benefit from any</i><br>
|
||
<i>> interaction.</i><br>
|
||
<p>
|
||
Yes. I in deed see quite some possibilities for interaction ...<br>
|
||
<p>
|
||
The advantages/disatvantages of Twain vs. SANE look to me like this:<br>
|
||
[please correct me on the Twain part, I am sure I am wrong in some places,<br>
|
||
as my knowledge is second hand on that.]<br>
|
||
<p>
|
||
SANE TWAIN<br>
|
||
separation of HW-driver (backend) usually monolithic driver<br>
|
||
and user interface (frontend)<br>
|
||
<p>
|
||
network transparent operation using normally not network transparent<br>
|
||
a special front- and backend<br>
|
||
<p>
|
||
User has choice of frontend only single frontend per driver<br>
|
||
<p>
|
||
portable across many platforms only Windows and MacOS<br>
|
||
<p>
|
||
API-internal hardware abstraction ?<br>
|
||
layers.<br>
|
||
<p>
|
||
only three well known frontends lots of colorful (though often<br>
|
||
scanner-tied) frontends<br>
|
||
<p>
|
||
not very widespread widespread, well known API<br>
|
||
<p>
|
||
small driver base complete driver base.<br>
|
||
<p>
|
||
no existing ability to process can transmit compressed data<br>
|
||
precompressed data.<br>
|
||
<p>
|
||
I think the best idea would be to take the good ideas from both standards<br>
|
||
and try to merge them in a way that ensures maximum interoperability.<br>
|
||
<p>
|
||
To achieve this I propose to:<br>
|
||
<p>
|
||
1. Enhance the functionality of the WinSANE package, which is trying to <br>
|
||
provide a SANE->Twain bridge in the sense, that it accesses a network-<br>
|
||
exported SANE device and presents it to the system as a TWAIN source.<br>
|
||
<p>
|
||
Using the cygwin tools and some minor hacking, this should allow SANE<br>
|
||
drivers to work on the Windows platform. I assume a similar solution could<br>
|
||
be worked out for the Mac.<br>
|
||
<p>
|
||
2. If my information is right, and a TWAIN driver does contain both the<br>
|
||
hardware driver and the GUI representation in one driver without a well<br>
|
||
defined interface between them, I propose that we work together on such an<br>
|
||
interface. I think SANE has shown a well working model (which can probably<br>
|
||
take a few enhancements), which could serve as a base.<br>
|
||
<p>
|
||
If we manage to assimilate our "intrafaces" that connect the HW driver to<br>
|
||
the GUI, we are pretty much set to mutually combine front- and backend<br>
|
||
drivers from both worlds, eventually using trivial glue layers, where things<br>
|
||
differ.<br>
|
||
<p>
|
||
I do see, that for most manufacturers there will not be a feel for needing<br>
|
||
to support multiple frontends for one single scanner. However I think it<br>
|
||
will both make writing drivers easier (as you can use a maybe not-so-pretty,<br>
|
||
but universal existing frontend while designing the backend, and then write <br>
|
||
the customized frontend), and allow for more flexibility for the user.<br>
|
||
<p>
|
||
Please do not take this personally, but I have seen a lot of TWAIN<br>
|
||
frontends, that are .. well very colorful, but pretty unuseable.<br>
|
||
While it might please some casual users to have the GUI designed like a<br>
|
||
car cockpit or a pinball game, it severely annoys me, when I have to wait<br>
|
||
for the bubble help over each button to pop up, as the only symbols you<br>
|
||
can guess what they are for are the brightness and contrast levers.<br>
|
||
For professional users that are interested in quick results rather than<br>
|
||
nifty look, a simple GUI is often more desireable.<br>
|
||
<p>
|
||
<p>
|
||
So I think the way to go would be to first make sure TWAIN gets an interface<br>
|
||
between frontend and backend, and we should as well define interfaces to<br>
|
||
well known transport layers like SCSI, parallel port, USB and serial port.<br>
|
||
<p>
|
||
This is what will make the drivers easily portable to Unixes. The main<br>
|
||
difference between OSes usually are the HAL and the GUI. The split driver<br>
|
||
model and the abovementioned interface-layers make sure that they are of no<br>
|
||
concern for the drivers themselves.<br>
|
||
<p>
|
||
Hardware driver layers for all OSes in questions need to be written, but<br>
|
||
that should be a minor effort.<br>
|
||
<p>
|
||
Frontend are GUI specific, so we expect the manufacturers to generally<br>
|
||
continue to only provide customized frontends for their main market only.<br>
|
||
However, as the above sketched scheme allows for arbitrary frontends, it<br>
|
||
will suffice to have backends available for all platforms, as the<br>
|
||
non-mainstream platforms can make use of generic frontends.<br>
|
||
<p>
|
||
3. While doing so enhance SANE with some lacking properties that can be done<br>
|
||
with TWAIN (like compressed data transfer).<br>
|
||
<p>
|
||
Comments, suggestions, questions, ... welcome.<br>
|
||
<p>
|
||
CU, ANdy<br>
|
||
<p>
|
||
<pre>
|
||
--
|
||
= Andreas Beck | Email : <<a href="mailto:andreas.beck@ggi-project.org">andreas.beck@ggi-project.org</a>> =
|
||
======== GGI - The Right Thing To Do : <a href="http://www.ggi-project.org/">http://www.ggi-project.org/</a> ========
|
||
<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="0094.html">Hugo van der Kooij: "Re: a few questions"</a>
|
||
<li> <b>Previous message:</b> <a href="0092.html">Oliver Rauch: "Discussion about SANE and TWAIN..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|