Hi, On Mon, Aug 22, 2005 at 09:22:42AM -0700, alanco...@yahoo.com wrote: > I persisted, on a rainy day, and got my Astra 2200 > working with sane-backends-1.0.16 and libusb-0.1.10a.
Ah, very fine. > The first thing I found, on the libusb site in the > mailing list area, was a patch by Robert Heller for > FreeBSD. [...] I propose to send this to the libusb mailing list (or if they have a bug tracker, to taht one). > I had to force sane-backends-1.0.16 to use libusb by > doing > configure --enable-libusb > because it still claimed to not be able to find usb.h > My usb.h is where it's supposed to be: > cpia# ls -la /usr/local/include/usb.h > -rw-r--r-- 1 root wheel 8321 Aug 20 11:34 > /usr/local/include/usb.h > OpenBSD also has a /usr/include/dev/usb/usb.h, I don't > know if that might be causing the problem by maybe > being found first. I don't think so. Maybe on OpenBSD the compiler/preprocessor just doesn't look for headers in /usr/local/include/ by default? The autoconfig scripts look in the default paths only. Something like this may help: CPPFLAGS="-I/usr/local/include/" ./configure > When I looked I found that the versions were 1.16 > instead of 1, so I copied the umax one to > libsane-umax.so.1 and it worked. I think I've seen > some installs that symlink the current version to an > earlier standard one like .1 but nothing like that > happened here. This seems to be a real problem on OpenBSD. The links are created by libtool automatically on all other platforms i can test (including FreeBSD and NetBSD). So maybe there is a problem with libtool on OpenBSD? SANE used to create these links itsself (still commented in backend/Makefile.in). But this created other trouble so it was removed some years ago. Maybe the dll backend should be more flexible in which extensions it looks for. > Lamp control under xscanimage doesn't seem to work, > although I've got it enabled in umax.conf and the > description from scanimage -L says the capability > exists. The Umax Windows driver can do it, but only > if you keep the silly thing running in your tray. > A really useful feature in xsane would be an option to > turn off the scanner lamp when the program closes, if > the current device supports it. This is backend-dependent. Some of "my" backends just turn off the lamp at "sane_close()", others provide an option for the user to decide. > And another that may be a typo: when looking at a > newly-scanned grayscale image, in the size statement > at the lower left corner, it tells me the image is 1 > *bit* per color instead of 1 byte. Scared me. When I > do a color scan it still says 1 bit per color. It also says 1 buit per color in 1 and in 16 bit mode so this one seems to be fixed (?). Also for Oliver. > Enabling TIFF and JPEG in sane-backends doesn't seem > to work. I did > ./configure --enable-tiff --enable-jpeg > but looking at the config.log it seems like it > couldn't find the libraries. They are there, and show > up if I do ldcofig -r. I'm not sure what versions > it's looking for. tiff and jpeg are enabled by default. Maybe the header file is not found if it's in /usr/local? CPPFLAGS may help, also CFLAGS="-L..." if the lib is in an unusual directory. As above, the configure script just looks in the default directories. > XSane's default pnm format doesn't > seem to be very universally supported, pnm is the standard interchange format if nothing else works. If a viewer or image manipulation program can't handle this it's broken in my opinion. > and totally uncompressed. This is intentional. > Gimp knows it, but qiv, Mozilla, Photoshop don't. qiv can display pnm (just tested). Mozilla opens display (ImageMagick) here to show it. I can't test photoshop. > IrfanView does, so I suppose I can batch convert scans in that. For batch conversion, imagemagick is the right tool. But xsane can save as png, jpeg or tiff :-) Bye, Henning
