252353N@knotes.kodak.com wrote:
>
> 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.
That is the same with SANE. The backends define
the options(buttons, sliders, menus) and the frontend
has to display the options.
> 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...
Is it possible to create a GUI in the application
layer that supports all functions the driver supports in
its own GUI?
>
> 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).
I am working on a X/gtk-based frontend (GUI) for sane
that makes available all functions a good GUI should have.
May be it would be a good start to add the
TWAIN-driver<->source-selection interface
to my frontend. This way we already would have the driver
layer on unix machines.
If you like to take a look at the frontend (xsane)
take a look at
http://www.wolfsburg.de/~rauch/sane/sane-xsane.html
If it would be interesting to add different GUIs for different
sane devices, the best way would be to create different
"TWAIN uses SANE"-drivers with different GUIs and
the user could select the GUI by the TWAIN source selection.
Of course a sane frontend also could decide to support only one
backend, this way a device could get its own frontend.
> 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 think it is no problem to add an ASPI support to sanei_scsi
so the support for scsi scanners under windows is no problem.
It should also be no problem to add the scsi support for Mac.
As far as I know linux-2.4.x will have a generic USB driver.
I think most other unix system do not have a USB driver at all.
May be linux sets the standard for USB drivers on unix systems.
The low level communication over the parallel port is relative simple
so I think there will be no great problem with this when the scanner
manufacterers give us the parallel port protocol of their scanners.
> 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...
Do you have a unix machine or a program that can
decompress gnu-zip and tar files?
If not I will transform them for you ( (pk)zip-format?)
Can you display dvi or postscript files?
> 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...
I hope that we will not only discuss and investigate
the opportunity. We should go and make a working
TWAIN interface on unix machines as the first step
and we should do this soon!
> 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 sane group is not an offical entitiy. David Mosberger
is one of the initiators of the sane standard and if there
is something like a leader of our project, I would say that
David is it. He takes care about the SANE standard and
makes new source code releases of SANE.
The communication is done via the sane-devel mailling list.
In general there is one programmer for a backend (driver),
we have about 20 backends in the recent distribution.
There are more backens developed and available on the web, they
are in alpha state and not included into the official release.
> 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)... :)
I think it would make the discussions and the progress
to connect TWAIN and SANE more easy if one of our group
knows the TWAIN standard and one of the TWAIN
group (YOU) knows the SANE standard very well.
> 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.
As far as I see the in TWAIN Working Group there are
only the companies of the scanner manufacterers. Are there
also members of the application site?
Bye
Oliver
-- 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