Howard,
> Thanks for any input,
Sorry for joining the discussion so late, and sorry for possibly
duplicating what others have said (I didn't have time to read their
responses).
chapter 2.:
There is no mention of IEEE 1394 devices. There should be, since
several of those are supported by SANE, and setup might not be
trivial. (See problems with LS-8000 with certain kernel versions.)
(Oh, I've just spotted "Firewire" in there -- please refer to it as
IEEE 1394, because that's the standard name, Firewire and i.Link are
proprietary names for the same thing by Apple and Sony.)
"Most USB devices are supported ... with the SANE application
programming interface." This is very confusing, I think you should
split that into two sentences. One thing is that they are supported by
SANE, the other is that SANE uses a homogeneous API throughout,
regardless of the hardware.
chapter 3.:
"IMPORTANT: You cannot have both kernel scanner support enabled (i.e.,
compiled in statically or the module loaded if a module) and libusb
installed and access the hardware at the same time, or nothing will
work." Why not? The only thing that won't work is sane-backends with a
USB scanner if it was built with libusb support. "nothing will work"
is a bit of an exaggeration. Also, libusb can safely be installed when
the kernel USB scanner module is loaded, even SANE will work as long
as sane-backend was built without libusb support.
I'd write "Directio" as "DirectIO" in the title, or even "Direct I/O",
to avoid confusion (directio can be mistaken as a typo, or a latin
word!).
chapter 4.:
There is no mention of libusb here -- you don't need any device files
outside /proc/bus/usb/ if you use libusb. Somewhere on the line, you
should also include instructions on how to use hotplug to modify
permissions to devices in /proc/bus/usb/ so that a regular user can
access the scanner.
"WARNING: If you enable 'devfs' without devfsd you will be left with
an unbootable system!" -- not true: this only applies if
CONFIG_DEVFS_MOUNT is also set.
chapter 5.:
saned section: there's no mention at all of the changes required to
net.conf. Also, what's the warning all about? I'd say it's advisable
to run saned as a dedicated user (I usually call it saned), but it's
not a group. Also, once saned is set up properly, _everyone_ has
access to the scanner without requiring root privileges, as long as
their computer is listed in saned.conf.
chapter 6.:
It would be very important to note here that sane-find-scanner isn't
related to any backends, therefore cannot tell whether the scanner is
supported or not. It only looks for devices which claim to be
scanners. BTW, it also works for IEEE 1394 devices (which essentially
behave as SCSI once SBP2 is set up).
chapter 7.:
"X-windows" is misleading and even wrong. Please use "X11" or "The X
Window System". "X-windows" sounds like a sci-fi version of M$
Windows.
"gtk+-1.2": version unnecessary, write "GTK+" (in capitals please)
It would be nice to elaborate on the GIMP-xsane relationship,
i.e. that xsane can be used as a GIMP plugin, and maybe even how. Most
people I know only ever scan with the GIMP plugin because they're used
to TWAIN scanners under Windows that only support scanning from within
an application.
"A more spartan solution (though technically a meta-backend) is
xscanimage, which is bundled with SANE": 1. it's not really spartan,
given the gamma adjustment capabilities which surpass those of xsane,
2. it's NOT a meta-backend but a frontend, 3. it's bundled with
sane-frontends, SANE is too general.
This was just a quick run through the document, hope it all makes
sense. I like the overall structure of the document.
Andras
===========================================================================
Major Andras
e-mail: and...@users.sourceforge.net
www: http://andras.webhop.org/
===========================================================================
