kopia lustrzana https://gitlab.com/sane-project/website
279 wiersze
14 KiB
HTML
279 wiersze
14 KiB
HTML
<!-- received="Thu Aug 12 12:54:54 1999 PDT" -->
|
||
<!-- sent="Thu, 12 Aug 1999 20:55:52 +0200" -->
|
||
<!-- name="Andreas Beck" -->
|
||
<!-- email="becka@rz.uni-duesseldorf.de" -->
|
||
<!-- subject="Re: Starting a discussion about SANE and TWAIN..." -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="852567CA.007047E6.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>Thu, 12 Aug 1999 20:55:52 +0200</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#111">[ date ]</a><a href="index.html#111">[ thread ]</a><a href="subject.html#111">[ subject ]</a><a href="author.html#111">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0112.html">Petter Reinholdtsen: "Unexpected Win32 success story"</a>
|
||
<li> <b>Previous message:</b> <a href="0110.html">Andreas Beck: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
<i>> I agree with your first comment. Linux, especially, is attracting</i><br>
|
||
<i>> all kinds of attention, and while I think it is essential to support</i><br>
|
||
<i>> UNIX and not just Linux, I suspect that the best short term goal</i><br>
|
||
<i>> is getting TWAIN on Linux.</i><br>
|
||
<p>
|
||
Yes. Though all Unixes are more or less alike, it will be an almost zero<br>
|
||
effort to have it on all Unixes, then.<br>
|
||
<p>
|
||
<i>> Your comment about abstaction layers is of keen interest to</i><br>
|
||
<i>> me. I'm not just interested in seeing TWAIN on UNIX. I think</i><br>
|
||
<i>> there is an opportunity with SANE to create a driver development</i><br>
|
||
<i>> 'kit' that abstracts away the physical communication with the OS,</i><br>
|
||
<i>> rather like ASPI does, though I'd like to see something less wire</i><br>
|
||
<i>> dependent.</i><br>
|
||
<i>> </i><br>
|
||
<i>> Perhaps such an abstraction already exists, if not it needs to,</i><br>
|
||
<i>> since it would significantly reduce the effort of porting drivers from</i><br>
|
||
<i>> one OS to another, which is the main reason you see so many</i><br>
|
||
<i>> devices well supported on one platform and weakly supported</i><br>
|
||
<i>> or unsupported on others.</i><br>
|
||
<p>
|
||
Yes. This is exectly, why sane includes the sanei_* interfacing files that<br>
|
||
abstract the paths to the hardware.<br>
|
||
<p>
|
||
<i>> In this case it would then be highly desireable to see SANE</i><br>
|
||
<i>> on Macintosh and Windows platforms, since it would reduce</i><br>
|
||
<i>> the driver development effort.</i><br>
|
||
<p>
|
||
Yes. Adding an ASPI layer for SANE should IMHO be no big deal. Generic SCSI<br>
|
||
support is there for the Unixes in some flavours, so I assume adding in<br>
|
||
ASPI shouldn't be a big deal.<br>
|
||
<p>
|
||
I see more problems on the common "ad-hoc" interfaces that were invented,<br>
|
||
like using the parallel port, or the serial port in nonstandard ways.<br>
|
||
I have heard of at least one scanner that uses the serial port modem control<br>
|
||
lines instead of the data lines to transmit data.<br>
|
||
<p>
|
||
We should make up standard APIs for accessing:<br>
|
||
<p>
|
||
- the SCSI-buses of the host system<br>
|
||
- serial ports (used in the "normal" way).<br>
|
||
- parallel ports<br>
|
||
- USB<br>
|
||
<p>
|
||
Most other methods (homebrew interface cards and such) aren't in common use<br>
|
||
anymore these days.<br>
|
||
<p>
|
||
<i>> As for your comparison of SANE and TWAIN, here are some of</i><br>
|
||
<i>> my observations...</i><br>
|
||
<p>
|
||
<i>> - SANE is GUI-less to provide optimal support across networks</i><br>
|
||
<i>> and on systems were there is no Windowing system.</i><br>
|
||
<p>
|
||
Yes and no. SANE does have GUIs (two of the three existing SANE frontends<br>
|
||
are graphical), but the GUI is not tied to the scanner.<br>
|
||
<p>
|
||
It is possible to write customized GUIs that work with only one scanner<br>
|
||
and can be tweaked to the manufacturer's liking.<br>
|
||
<p>
|
||
<i>> - TWAIN assumes the presence of a Windowing system (which</i><br>
|
||
<i>> is pretty reasonable for Windows and Macintosh, and for a</i><br>
|
||
<i>> lot of UNIX systems). The reason for the GUI is that it takes</i><br>
|
||
<i>> away the burden of capability negotiation from the application</i><br>
|
||
<i>> writer. </i><br>
|
||
<p>
|
||
Yes. This is what we should add to SANE in a generic manner. The existing<br>
|
||
frontends are capable of interfacing with the most well known photo-retuche<br>
|
||
software for Unix, the GIMP, but not much else.<br>
|
||
<p>
|
||
Due to Unix' piping facilities, you can feed most software directly from a<br>
|
||
File-like stream, so not many people see too much need for other mechanisms.<br>
|
||
<p>
|
||
However it would be nice, if we could add an API to the frontends we have<br>
|
||
that will allow them to export a simple TWAIN-like "Acquire Image"<br>
|
||
interface.<br>
|
||
<p>
|
||
So it would look like this:<br>
|
||
<p>
|
||
application -> TWAIN-API -> TWAIN_2_SANE frontend remote control interface<br>
|
||
-> SANE frontend -> SANE backend.<br>
|
||
<p>
|
||
This gives the best of both worlds:<br>
|
||
<p>
|
||
The application uses the simple but small and efficient TWAIN API, which is<br>
|
||
well known and thus no problem to implement for most programmers.<br>
|
||
<p>
|
||
We write a TWAIN_2_SANE glue layer, that handles communication with the<br>
|
||
SANE frontend, which display the GUI, lets the user press his buttons and<br>
|
||
hands back image data to the application.<br>
|
||
<p>
|
||
The sane frontend communicates with its backend as usual.<br>
|
||
<p>
|
||
<i>> This means that an app writer can communicate with a</i><br>
|
||
<i>> Source with a minimum number of calls, without losing access</i><br>
|
||
<i>> to all the features of the device represented by the Source.</i><br>
|
||
<p>
|
||
Yes. However, tying the GUI into the driver itself means, that you have to<br>
|
||
heavily modify the driver for each GUI. GUIs differ very much in their<br>
|
||
method of communicating with their client programs, what often requires <br>
|
||
large source code changes to accomdate different programming methods that<br>
|
||
are to be preferred for the different GUIs.<br>
|
||
<p>
|
||
This is why I suggest that extra layer. The GUI gets insulated in the<br>
|
||
SANE frontend.<br>
|
||
<p>
|
||
This allows to - for starters - write one single X11 GUI and be done with<br>
|
||
it. All the manufacturer really needs to deliver is the backend.<br>
|
||
<p>
|
||
The application->TWAIN->frontend patch can be done with standard<br>
|
||
components.<br>
|
||
<p>
|
||
<i>> - I'm going to say that last bit again in a different way, since it is</i><br>
|
||
<i>> an important part of the TWAIN philosophy. When we are</i><br>
|
||
<i>> working on the TWAIN specification, we often ask the question</i><br>
|
||
<i>> "does this make things easier for the Source writer or for the</i><br>
|
||
<i>> application writer?" Whenever possible we try to make things</i><br>
|
||
<i>> easier for the application writer, since there are many apps for</i><br>
|
||
<i>> every Source.</i><br>
|
||
<p>
|
||
We have a somewhat different paradigm here, as compared to the number of<br>
|
||
available applications that want to handle scanners directly, the number of<br>
|
||
supported source sis rather big. However if we had a very simple API,<br>
|
||
like TWAIN is supposed to be, this could change.<br>
|
||
<p>
|
||
<i>> - And having said that, let me say that TWAIN has been and is</i><br>
|
||
<i>> continuing to emphasize the programmatic side of the interface.</i><br>
|
||
<i>> This is because some application writers really hate those</i><br>
|
||
<i>> internal TWAIN GUIs, and want to assume full control of the</i><br>
|
||
<i>> Source. It's an ongoing process to convince Source writers to</i><br>
|
||
<i>> take the time to fill out both interfaces.</i><br>
|
||
<p>
|
||
Yes. I see. Moving to a scheme like the one I propose above would very<br>
|
||
probably emphasize that need.<br>
|
||
<p>
|
||
The SANE API gives full control to the application programmer, while using<br>
|
||
some standard frontend we could also provide the simpler to use TWAIN API<br>
|
||
in one swoop.<br>
|
||
<p>
|
||
The SANE API enforces the complex, yet detailed interface between front- and<br>
|
||
backend. Using a frontend you can get a simple API from it, giving you both<br>
|
||
sides of the coin.<br>
|
||
<p>
|
||
<i>> As I've stated in my other mail messages today, I believe the</i><br>
|
||
<i>> immediate win from seeing SANE and TWAIN on UNIX, Windows</i><br>
|
||
<i>> and Macintosh platforms is that it removes an impediment from</i><br>
|
||
<i>> application writers who want to try their hand on another platform</i><br>
|
||
<i>> without massive code rewrites.</i><br>
|
||
<p>
|
||
Yes. I think this is most easily possible by separting out everything in<br>
|
||
which the different host OSes differ. To me that is:<br>
|
||
<p>
|
||
- hardware interfacing (handled by the sanei_* interfaces)<br>
|
||
- GUI (handled by the SANE frontends)<br>
|
||
- eventually inter-process-communication (handled by the TWAIN_2_SANE bit<br>
|
||
I mentioned earlier).<br>
|
||
<p>
|
||
<i>> In the case of TWAIN that means that a Windowing system must</i><br>
|
||
<i>> be present. </i><br>
|
||
<p>
|
||
Yes. <br>
|
||
<p>
|
||
<i>> And on UNIX that really points the finger at X-Windows.</i><br>
|
||
<p>
|
||
Yes, but please note, that there are other GUIs for Unix in existence.<br>
|
||
Berlin for example. Moreover, if we can separate out the GUI, this<br>
|
||
eases driver writing tremendously.<br>
|
||
<p>
|
||
<i>> Of course, the cool thing about X is that it can display windows</i><br>
|
||
<i>> across the net, so the fact that TWAIN requires a GUI does not</i><br>
|
||
<i>> preclude the use of remote capture devices.</i><br>
|
||
<p>
|
||
Yes. But doing so is no fun, even on the common connection I'd expect, which<br>
|
||
is 10Mbit Ethernet, i.e. the common LAN. Also note, that this means you need<br>
|
||
a shell account on the remote system, and you need you application software<br>
|
||
(that makes the TWAIN-request) running on the host.<br>
|
||
<p>
|
||
<i>> For the time being I recommend that we not worry about running</i><br>
|
||
<i>> TWAIN on console mode systems. TK/TCL could be used to</i><br>
|
||
<i>> accomodate this, but if my initial assumption is true, that the first</i><br>
|
||
<i>> targeted developer audience is application ports, then there</i><br>
|
||
<i>> won't be anyone interested in running TWAIN on a system that</i><br>
|
||
<i>> isn't also running X.</i><br>
|
||
<p>
|
||
Yes. For running console mode or doing stuff like a CGI Interface to the<br>
|
||
scanner (I have that running here for the Windows clients in the LAN), <br>
|
||
I suppose it would make sense to bypass the TWAIN layer and directly talk to<br>
|
||
SANE.<br>
|
||
<p>
|
||
<i>> There is nothing preventing us from looking</i><br>
|
||
<i>> into this later, if a real need is identified (I realize that some remote</i><br>
|
||
<i>> scanning solutions might be 'very' interested in this).</i><br>
|
||
<p>
|
||
Actually the most interesting thing in that area would be scanners that<br>
|
||
directly export the SANE network API. Or - more interesting than scanners:<br>
|
||
WebCams.<br>
|
||
<p>
|
||
<i>> As for the look of the different TWAIN GUIs...</i><br>
|
||
<i>> It is ideal in that it allows a hardware vendor to present their </i><br>
|
||
<i>> device the way they want (which presumably accesses all the features </i><br>
|
||
<i>> of the device). </i><br>
|
||
<p>
|
||
Yes. This is still possible, and IMHO even simplified using the split driver<br>
|
||
model, as you can then implement the frontend and the backend independently<br>
|
||
and in parallel using existing components as counterpart.<br>
|
||
<p>
|
||
<i>> We've discussed the notion of a single, standard interface that</i><br>
|
||
<i>> applications could invoke as an alternative to the Source's GUI</i><br>
|
||
<i>> and to writing a complete programmatic interface. This path</i><br>
|
||
<i>> looks nastier the longer one looks at it so we've shelved it for</i><br>
|
||
<i>> now, but if the SANE group has ideas on this, we're more than</i><br>
|
||
<i>> happy to dust off the issues and chat about them again...</i><br>
|
||
<p>
|
||
Yes. I think SANE is quite that. It basically solves that issue by seeing<br>
|
||
the device much like an electrical switchboard (which it more or less is<br>
|
||
from a theoretical point of view). Each control on that board has several<br>
|
||
possible states (like on/off, color/grey/lineart, 20-1200dpi, ...) and that<br>
|
||
states and the constraints imposed upon them are recorded in what we call<br>
|
||
option descriptors.<br>
|
||
<p>
|
||
Thus towards the GUI, we do not describe, how it should look like, but only<br>
|
||
what options it should offer and which possible values it can accept.<br>
|
||
<p>
|
||
The frontend then decides on how to render that information into a control<br>
|
||
panel. It will e.g. use sliders for continous controls, checkboxes for<br>
|
||
yes/no, radiobutton or dropdowns for one-out-of-many choices and the like.<br>
|
||
<p>
|
||
A custom GUI can of course just expect a certain set of options and map them<br>
|
||
arbitrarily, which allows to use the "stranger" controls some people like.<br>
|
||
<p>
|
||
<i>> I realize that I may not have addressed all the items in your</i><br>
|
||
<i>> message to me, but I also just noticed that I have to leave, so</i><br>
|
||
<i>> I'm sending this out now. Please let me know if I missed anything</i><br>
|
||
<i>> that you want to discuss more...</i><br>
|
||
<p>
|
||
O.K. - I think this mail also got pretty long by now ... comments as always<br>
|
||
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>> =
|
||
<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="0112.html">Petter Reinholdtsen: "Unexpected Win32 success story"</a>
|
||
<li> <b>Previous message:</b> <a href="0110.html">Andreas Beck: "Re: Starting a discussion about SANE and TWAIN..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|