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