[sane-devel] (no subject)
I recently posted on this list about a Xerox 4800 flatbed scanner. After a little investigation it would seem that Xerox have simply rebranded the Visioneer 4800 scanner. If the Visioneer 4800 one touch is ever supported I assume the Xerox will be as well. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060108/7b7dd185/attachment.htm From photopi...@interia.pl Sat Jan 7 23:48:00 2006 From: photopi...@interia.pl (Radek Rurarz) Date: Sun Jan 8 00:53:06 2006 Subject: [sane-devel] Microtek Film Scan 35 In-Reply-To: Pine.LNX.4.64.0601071938170.3964@localhost.localdomain References: Pine.LNX.4.64.0601071938170.3964@localhost.localdomain Message-ID: 20060108004800.33ed9dd5.photopi...@interia.pl On Sat, 7 Jan 2006 19:48:32 +0300 (MSK) Andrei V. Toutoukine t...@isuct.ru wrote: Dear SANE developers, I've got six years old Microtek Film Scan 35 which nobody cares of at my work. Unfortunately I seen the mark unsupported at SANE web site. I have a Microtek 35t/35t+ (I'm not sure which one, the plate on the device is confusing). It's well discovered by sane, unfortunately it hangs the SCSI bus. On the other hand the vuescan does a good job with it (too bad it's not free and not open source). My regards. -- Rados?aw Rurarz Warsaw Poland GG: 7249330 JID (Jabber): rrur...@jabber.wp.pl -- Kliknij po wiecej! http://link.interia.pl/f18ed
[sane-devel] Microtek Film Scan 35
hangs the SCSI bus. On the other hand the vuescan does a good job with it (too bad it's not free and not open source). Hm, vuescan is reasonably priced, has a user interface, supports it8 targets, process calibration and reasonably good infrared cleaning, and most importantly, actually works... Most annoying that it doesn't work with SCSI scanners on 64bit machines, something a recompile would fix. Hence my recent question about write() encapsulation in sanei_scsi.c (which no-one replied to :( ). Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
[sane-devel] dell1600n-net backend
Jon Chambers j...@jon.demon.co.uk wrote: Hi, 1. Hopefully trivial: I have written a dummy backend and sym-linked it to /usr/lib/sane/libsane-dell1600n-net.so. How can I get a SANE frontend to find it? Add dell1600n to /etc/sane.d/dll.conf. 2. The Dell 1600n sends data back in CCITT Fax Group 4 or JPEG formats (for monochrome or colour scans respectively). To convert this to an array of RGB data will require converstion via an external library (eg: libjpeg). Is this extra link dependency acceptable for the SANE backends build? Yes, see the Makefile in backend/, some backends already link with external libraries (libgphoto2, libjpeg, libtiff are some examples IIRC). JB. -- Julien BLACHE http://www.jblache.org j...@jblache.org GPG KeyID 0xF5D65169
[sane-devel] dell1600n-net backend
Hi, On 2006-01-08 10:16, Julien BLACHE wrote: 2. The Dell 1600n sends data back in CCITT Fax Group 4 or JPEG formats (for monochrome or colour scans respectively). To convert this to an array of RGB data will require converstion via an external library (eg: libjpeg). Is this extra link dependency acceptable for the SANE backends build? Yes, see the Makefile in backend/, some backends already link with external libraries (libgphoto2, libjpeg, libtiff are some examples IIRC). For jpeg, SANE also comes with some header files in sanei (sanei_jpeg.h, sanei_cderror.h, sanei_jinclude.h) which are used by some backends. Bye, Henning
[sane-devel] Microtek Film Scan 35
Hi, On 2006-01-08 14:27, Volker Kuhlmann wrote: Most annoying that it doesn't work with SCSI scanners on 64bit machines, something a recompile would fix. Hence my recent question about write() encapsulation in sanei_scsi.c (which no-one replied to :( ). I didn't answer because I'm not really sure about SCSI and 64bit systems. As far as I know there is no special handling for 64bit systems in our SCSI code. If somebody else needs such a special handling because of the binary-only nature of his software, it's up to him to fix the problems caused by this. If there are general problems with sanei_scsi/SANE on 64 bit systems, I'd like to know about this. As far as I know, this is not the case, however. Bye, Henning
[sane-devel] (no subject)
Hi, On 2006-01-08 00:05, Ben Tasker wrote: I recently posted on this list about a Xerox 4800 flatbed scanner. After a little investigation it would seem that Xerox have simply rebranded the Visioneer 4800 scanner. If the Visioneer 4800 one touch is ever supported I assume the Xerox will be as well. So it has the same vendor and product ids? If this is not the case, please send the output of sane-find-scanner -v -v. Bye, Henning
[sane-devel] Re: sane-devel Digest, Vol 7, Issue 12
Hi Parag, Am Sonntag 08 Januar 2006 01:53 schrieb sane-devel-requ...@lists.alioth.debian.org: Message: 1 Date: Sat, 7 Jan 2006 18:09:16 +0530 From: Parag N() panem...@gmail.com Subject: [sane-devel] require Hp2300C linux debug messages To: sane-devel@lists.alioth.debian.org Message-ID: f4586a2e0601070439g73c3c4a7jaa66aea8b6b00...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hello, Is there anybody here with HP2300c? If anybody have it can you please send me debug messages log that will come when you scan a document. Please send me that output of debug messages by enabling them by exporting first environment variables export SANE_DEBUG_GENESYS=255 export SANE_DEBUG_GENESYS_GL646=255 I made one for you. Details will follow via mail. Greets, Torsten
[sane-devel] Microtek Film Scan 35
On Sat, 7 Jan 2006, Henning Meier-Geinitz wrote: of creating (or extending) the SANE back-end? See SANE website, section Contributing. See also the archive of this mailing list for similar questions about writing backends. OK, I'd like to try. Should I contact the manufacturer for protocol details or maybe someone has these already? With the best regards, Andrei.
[sane-devel] Re: sane-devel Digest, Vol 7, Issue 12
Hi Torsten, waiting for linux log for Hp2300c from you. if you got it please send me it to my email. Regards, Parag. On 1/8/06, Torsten Evers tev...@onlinehome.de wrote: Hi Parag, Am Sonntag 08 Januar 2006 01:53 schrieb sane-devel-requ...@lists.alioth.debian.org: Message: 1 Date: Sat, 7 Jan 2006 18:09:16 +0530 From: Parag N() panem...@gmail.com Subject: [sane-devel] require Hp2300C linux debug messages To: sane-devel@lists.alioth.debian.org Message-ID: f4586a2e0601070439g73c3c4a7jaa66aea8b6b00...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hello, Is there anybody here with HP2300c? If anybody have it can you please send me debug messages log that will come when you scan a document. Please send me that output of debug messages by enabling them by exporting first environment variables export SANE_DEBUG_GENESYS=255 export SANE_DEBUG_GENESYS_GL646=255 I made one for you. Details will follow via mail. Greets, Torsten -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-requ...@lists.alioth.debian.org
[sane-devel] (no subject)
Sorry should have mentioned that in the previous post. The Xerox 4800 One touch does indeed have the same Product and Vendor ID as the Visioneer 4800 One touch -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20060108/1f2cbc07/attachment.htm From henn...@meier-geinitz.de Sun Jan 8 12:46:22 2006 From: henn...@meier-geinitz.de (Henning Meier-Geinitz) Date: Sun Jan 8 12:47:24 2006 Subject: [sane-devel] (no subject) In-Reply-To: 6b8aa2ee0601080405s33bb5e7u35fe1414fda82...@mail.gmail.com References: 6b8aa2ee0601071605y8fd4e16hfc923974ce64c...@mail.gmail.com 6b8aa2ee0601080405s33bb5e7u35fe1414fda82...@mail.gmail.com Message-ID: 20060108124622.gf4...@meier-geinitz.de Hi, On 2006-01-08 12:05, Ben Tasker wrote: Sorry should have mentioned that in the previous post. The Xerox 4800 One touch does indeed have the same Product and Vendor ID as the Visioneer 4800 One touch Thanks, I'll add it to our lists. As the Visioneer 4800 is already quite long in our lists and nobody has written a backend yet I guess it's still up to you to write one :-) The chipset seems to be Realtek RTS8801B. I don't know how similar this is compared to which is supported by the hp3500 backend http://projects.troy.rollo.name/rt-scanners/ but it may help nevertheless. Bye, Henning
[sane-devel] [PATCH] undefined symbols in the qcam backend on GNU/kFreeBSD
Hi, On 2006-01-07 05:15, Aurelien Jarno wrote: -#if defined(__linux__) || defined (HAVE_SYS_HW_H) +#if defined(__GLIBC__) || defined (HAVE_SYS_HW_H) But this means that Linux without glibc won' work, which is the reason for this one: #elif HAVE_ASM_IO_H # include asm/io.h /* older Linux */ #elif HAVE_SYS_HW_H Granted, not many pre-glibc linux systems will exist and use SANE but I guess this should be made more intelligent nevertheless. Or do I miss something? Bye, Henning
[sane-devel] dell1600n-net backend
On Sat, 7 Jan 2006 22:31:05 + (GMT) Jon Chambers j...@jon.demon.co.uk wrote: I have written a driver for network scanning using a Dell 1600n MFP. It is implemented as a perl script and can be found here: http://www.jon.demon.co.uk/dell1600n-net-scan/ I am currently in the process of figuring out how to write an equivalent SANE backend. I have a couple of problems: 1. Hopefully trivial: I have written a dummy backend and sym-linked it to /usr/lib/sane/libsane-dell1600n-net.so. How can I get a SANE frontend to find it? Hello, SANE actually misses a network transport and, since I'm dealing with a network capable MFP too, we can maybe coordinate the efforts to create and test one. Let me know if you're interested. -- Best regards, Alessandro Zummo, Tower Technologies - Turin, Italy http://www.towertech.it
[sane-devel] Microtek Film Scan 35
Hi, On 2006-01-08 14:17, Andrei V. Toutoukine wrote: OK, I'd like to try. Should I contact the manufacturer for protocol details or maybe someone has these already? Asking is always a good idea. If they don't have a protocol description, maybe they can give you the source code of the windows driver. The PIE 1800 seems to be the same scanner: http://www.sane-project.org/unsupported/pie-1800u.html Bye, Henning
[sane-devel] Vendor and product ids in description files
Hi developers, The format of the SANE description files (.desc) has been changed to allow the addition of USB vendor and product ids to each model entry. These ids will be shown in the HTML lists (and all other output formats) and therefore help to identify a USB scanner exactly. The second reason for adding these ids to the description files is to generate the lists for hotplug/udev events (e.g. libsane.usermap) automatically from the description files. This is not yet implemented but work in progress. Now the USB ids for all USB device should be added to the description files,. Backend authors please start as soon as possible so we have a complete list soon. I'll take care for external and unsupported backends as well for scanners listed in libsane.usermap but not in one of the .desc files. Also I'll try to add the ids to unsupported devices. Once most description files are updated, I'll add a warning message to sane-desc.c which will be printed if it finds a USB device without vendor and product ids given. This is the format (form doc/descriptions.txt): `:usbid' defines the USB vendor and product ids of the device. It has two arguments which must be lower case hexadecimal (4 digits). The first one is the USB vendor id, the second one the USB ?product id. The keyword refers to the previous `:model', is optional, and applicable for devices with :interface USB only, and should be used only once per model. Example: `:usbid 0x1234 0x4321' As an example, the gt68xx.desc file has already been updated with USB ids. The HTML output looks like this: http://www.sane-project.org/lists/sane-backends-cvs.html#S-GT68XX Bye, Henning
[sane-devel] dell1600n-net backend
Hi Alessandro, On Sun, 8 Jan 2006, Alessandro Zummo wrote: SANE actually misses a network transport and, since I'm dealing with a network capable MFP too, we can maybe coordinate the efforts to create and test one. Let me know if you're interested. This could be useful. What scanner are you working on and what stage are you at? Do you know the network protocol? Do you have a working prototype? Have you made a start on a SANE backend? From my side, I have a working prototype (a standalone perl script). No backend as yet (just a dummy one to experiment with the API). I foresee that the main problems will be: 1. Platform independent networking code. Perl does a pretty good job of hiding this. C headers could potentially be more problematic. (Certainly Linux and Win32 BSD socket functions differ - I don't know much about other platforms). A poke around the existing net backend would probably be instructive. 2. The app does not know how many pages will be received or their parameters until the scanned pages arrive (ie: it can specify resolution and format but the user may override these on the scanner front panel before pressing scan). I have yet to figure out whether the SANE API will be happy with this (eg: maybe it needs to allocate storage space for the scan data before the scan starts). 3. The scan data arrives as either CCITT Fax Group 4 or JPEG format and so will need converting to RGB in order to pass through the API. How does this compare with your situation? cheers, Jon == Jon Chambers = http://www.jon.demon.co.uk, 020 8575 7097, 07969 956575 =
[sane-devel] Microtek Film Scan 35
Henning Meier-Geinitz wrote: Hi, On 2006-01-08 14:27, Volker Kuhlmann wrote: Most annoying that it doesn't work with SCSI scanners on 64bit machines, something a recompile would fix. Hence my recent question about write() encapsulation in sanei_scsi.c (which no-one replied to :( ). I didn't answer because I'm not really sure about SCSI and 64bit systems. As far as I know there is no special handling for 64bit systems in our SCSI code. If somebody else needs such a special handling because of the binary-only nature of his software, it's up to him to fix the problems caused by this. If there are general problems with sanei_scsi/SANE on 64 bit systems, I'd like to know about this. As far as I know, this is not the case, however. The problem is probably the same that has been discussed for Linux on 64 bit Sparc machines some time ago. The SG interface version 3 can't deal with 32 bit programs on a 64 bit kernel. In read/write calls of the SG driver, the application passes 32 bit pointers to three buffers (SCSI command, data buffer, sense data) to the SG driver, while the driver expects 64 bit pointers to these buffers. As a workaround, one can enforce the usage of the old interface, by inserting the line #define DISABLE_LINUX_SG_IO 1 at the start of sanei_scsi.c. OK, a proper solution would be to add a configure option, but I am not familiar enough with the details of autoconf to tell how to implement such an option. Abel
[sane-devel] dell1600n-net backend
On Sun, 8 Jan 2006 15:16:38 + (GMT) Jon Chambers j...@jon.demon.co.uk wrote: This could be useful. What scanner are you working on and what stage are you at? Do you know the network protocol? Do you have a working prototype? Have you made a start on a SANE backend? Epson CX11NF. The protocol is ESC/I plus some encapsulation. I've a perl script to do some little things with it. Not yet started with the backend, I'm focusing on the transport. 1. Platform independent networking code. Perl does a pretty good job of hiding this. C headers could potentially be more problematic. (Certainly Linux and Win32 BSD socket functions differ - I don't know much about other platforms). A poke around the existing net backend would probably be instructive. I agree. I only know of unix sockets, so probably the first version won't work straight on windows... 2. The app does not know how many pages will be received or their parameters until the scanned pages arrive (ie: it can specify resolution and format but the user may override these on the scanner front panel before pressing scan). I have yet to figure out whether the SANE API will be happy with this (eg: maybe it needs to allocate storage space for the scan data before the scan starts). The CX11NF can be operated both from the panel and the host pc. No problems when doing that from the host, as you can use scanadf to process the pages. The panel interface is a bit different: the CX11 will send multicast packets to discover suitable hosts. The hosts will send the CX11 their name and the CX11 will show them on the panel. When the user presses the scan button, a packet will be sent to the host with the parameters. I've handled this process outside of SANE, using some Perl code. scanadf is then called with the suitable parameters to actually perform the scan. (actually, I'm doing all of this data exchange via network, except the actual scan work which is done via USB). 3. The scan data arrives as either CCITT Fax Group 4 or JPEG format and so will need converting to RGB in order to pass through the API. My scanner is already supported under USB, so my job will probably be a bit easier on this front. -- Best regards, Alessandro Zummo, Tower Technologies - Turin, Italy http://www.towertech.it
[sane-devel] dell1600n-net backend
Hi Alessandro, On Sun, 8 Jan 2006, Alessandro Zummo wrote: I agree. I only know of unix sockets, so probably the first version won't work straight on windows... I don't see any #ifdef WIN32 in the SANE code so I don't think that is a target platform. Nonetheless there are MaC OS and OS2 #ifdefs. Looking at backend/net.c I see stuff like: #include netinet/in.h #include netdb.h /* OS/2 needs this _after_ netinet/in.h, grrr... */ Nothing too horrific but worth copying to avoid known pitfalls. The Dell 1600n network protocol seems quite different to the one you describe, but we both have a requirement for socket communication which works on all SANE platforms. I'll keep you posted on my progress. cheers. Jon ps: FYI the Dell protocol goes like: Discovery: 1. Computer sends a UDP broadcast to discover nearby scanners. 2. Scanner replies via UDP. Scanning: 1. Computer sends UDP message to scanner to register (computer name appears in the scanner menu). 2. User presses scan and selects computer from scanner menu. 3. Scanner sends UDP message to computer requesting TCP connection. 4. Computer inits TCP connection and sends preferred scan parameters. 5. User (having optionally selected different scan parameters etc) selects start scanning and one or more pages are sent to the computer via TCP. == Jon Chambers = http://www.jon.demon.co.uk, 020 8575 7097, 07969 956575 =
[sane-devel] Vendor and product ids in description files
Hi again, On 2006-01-08 17:00, Henning Meier-Geinitz wrote: formats) and therefore help to identify a USB scanner exactly. The second reason for adding these ids to the description files is to generate the lists for hotplug/udev events (e.g. libsane.usermap) automatically from the description files. This is not yet implemented but work in progress. sane-desc now has support for printing USB vendor/product ids in hotplug (libsane.usermap), hotplug-ng (libsane.db) and udev (libsane.rules) format. Please test! Especially the udev format is completely untested. Try something like cd tools ./sane-desc --help ./sane-desc -m usermap -s ../doc/descriptions Bye, Henning
[sane-devel] sane SCSI 32bit emulation on 64bit
Most annoying that it doesn't work with SCSI scanners on 64bit machines, something a recompile would fix. Hence my recent question about write() encapsulation in sanei_scsi.c (which no-one replied to :( ). If somebody else needs such a special handling because of the binary-only nature of his software, it's up to him to fix the problems caused by this. I feared such an attitude would prevail. Here is the situation: 1) sane is an API for scanners which works 2) sane is *NOT* a scanning application, i.e. some software which gets some scanning work done. 3) xsane is a GUI around sane, but not a scanning application either, its results are useless. Take this as a fact which we can debate elsewhere some other time. I am talking expensive film scanners here, not some 0 8 15 flatbed. 4) A very high-quality scanning application exists for Linux - the only one for Linux I know of. But it's compiled on a 32bit machine and doesn't run on a 64bit machine because the Linux SCSI 64/32bit emulation layer deals with ioctl() controls, but not data exchanged with write() (and read()?). Typically it's impossible to make an emulation layer for the data, but in this case the vuescan author says it's possible, I think it's because it happens in the application rather than in the lower-level device driver. He offered to link with a version of sanei_scsi.c which adapted at runtime to the architecture and wrapped the write() calls suitably. He doesn't want to recompile for 64bit because the amount of money he makes from the Linux version doesn't justify it. I can understand your attitude, and I can understand the vuescan author's attitude. Between the two, the net result is no functional scanning application is available for SCSI scanners on a 64bit Linux workstation. There goes Linux is suitable for the desktop. You're doing an excellent job on the sane engine in the face of a lot of seriously annoying hardware manufactures. But to go places, it needs a car - a motor is absolutely necessary, but not sufficient. I'll dig further into it and see if I can cook up something as soon as I'm more familiar with how all the SCSI things work. If someone by chance has an idea of genereal direction I'd like to know ;) If there are general problems with sanei_scsi/SANE on 64 bit systems, I'd like to know about this. As far as I know, this is not the case, however. If everything is compiled as 64bit, it works fine. Software which uses sanei_scsi and is compiled as 32bit is non-functional running on a 64bit architecture. This would be regardless of whether it's free open source software. Greetings, Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
[sane-devel] sane SCSI 32bit emulation on 64bit
Hi, He doesn't want to recompile for 64bit because the amount of money he makes from the Linux version doesn't justify it. Err... excuse me? I don't think the amount of money any of the SANE developers makes from SANE development justifies any effort on this behalf. I can understand your attitude, and I can understand the vuescan author's attitude. Between the two, the net result is no functional scanning application is available for SCSI scanners on a 64bit Linux workstation. There goes Linux is suitable for the desktop. No, there goes Vuescan is suitable for the desktop. Some difference. If you want to ask someone for a favour you better choose your words carefully. /Oliver
[sane-devel] sane SCSI 32bit emulation on 64bit
Hi, On 2006-01-09 09:54, Volker Kuhlmann wrote: 1) sane is an API for scanners which works 2) sane is *NOT* a scanning application, i.e. some software which gets some scanning work done. sane-backends is not. Frontends like scanimage, xscanimage and xsane are. 3) xsane is a GUI around sane, It's a frontend, not really gui around sane. but not a scanning application either, Come on. its results are useless. Take this as a fact which we can debate elsewhere some other time. I am talking expensive film scanners here, not some 0 8 15 flatbed. I'm not sure if it's really xsane's fault or if backend support for film scanners in sane(-backends) is just week. I can understand your attitude, and I can understand the vuescan author's attitude. Between the two, the net result is no functional scanning application is available for SCSI scanners on a 64bit Linux workstation. There goes Linux is suitable for the desktop. Linux works pretty well for my desktop (and other Unixes also do). Actually my goal is to make SANE better, I don't really care that much about Linux. You're doing an excellent job on the sane engine in the face of a lot of seriously annoying hardware manufactures. But to go places, it needs a car - a motor is absolutely necessary, but not sufficient. Just to make one thing clear: Vuescan is NOT a SANE frontend. I.e. it does not use any SANE backend. It's a completely independent program with independent scanner drivers. It just happens to use a part of the internal low level SANE code (sanei_scsi). Last time I looked at it (some years ago), this was done without even adhering to the license. Therefore it's really up to the author to modify this code to his needs. Nevertheless, if I had known a solution, I would have told you. If everything is compiled as 64bit, it works fine. Software which uses sanei_scsi and is compiled as 32bit is non-functional running on a 64bit architecture. This would be regardless of whether it's free open source software. Abel posted a work-around for that. Bye, Henning
[sane-devel] dell1600n-net backend
Hi, On 2006-01-08 19:40, Jon Chambers wrote: I don't see any #ifdef WIN32 in the SANE code so I don't think that is a target platform. See README.windows... Bye, Henning
[sane-devel] sane SCSI 32bit emulation on 64bit
Hi Mr. Kuhlmann, I was the one to bring up the issue with the SPARC workaround, the sane folks helped me a lot to do the testing and find out that using the old interface made everything work. And, as a matter of fact, everything on SPARC64 is compiled 32 bit in the user world. Only the kernel is 64Bit. Therefore you might want try to compile sane 32 bit using the old interface - this works on SPARC64, so it might work on other 64Bit platforms, too. On SPARC64 there is an autodetection for this, but as it has been suggested by Mr. Deuring - you could enable it hard by default. The only thing I cannot tell - well, on SPARC64 you have to say sparc32 make to compile 32Bit - I do not know how to achieve this on 64Bit X86 architecture. Good luck, take care Dieter Jurzitza Am Sonntag, 8. Januar 2006 21:54 schrieb Volker Kuhlmann: Most annoying that it doesn't work with SCSI scanners on 64bit machines, something a recompile would fix. Hence my recent question about write() encapsulation in sanei_scsi.c (which no-one replied to :( ). If somebody else needs such a special handling because of the binary-only nature of his software, it's up to him to fix the problems caused by this. I feared such an attitude would prevail. Here is the situation: ** -- --- | \ /\_/\ | | ~x~ |/-\ / \ /- \_/ ^^__ _/ _ / ??__ \- \_/ | |/| | || || _| _|_| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) ---
[sane-devel] sane SCSI 32bit emulation on 64bit
Err... excuse me? I don't think the amount of money any of the SANE developers makes from SANE development justifies any effort on this behalf. I am aware of that, and I wasn't asking the sane developers for any effort, unless you count brain-picking as effort. No, there goes Vuescan is suitable for the desktop. Some difference. Not really - if there is no alternative to vuescan, the end result is the same. Sorry, xsane doesn't come close yet. People buy vuescan for windows because it's both cheap and better than what the scanner suppliers give them. I don't see a lot of people switching to inferior apps on a superior OS, esp when the app doesn't talk to the scanner. Their main aim is to get the scanning work done. Yes I hate closed source software too, but reality is that it's not possible to do without it quiet yet. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
[sane-devel] sane SCSI 32bit emulation on 64bit
Henning Meier-Geinitz wrote: [snip] but not a scanning application either, Come on. In the context of scanning negatives and films using high end scanners xsane is not scanning application but a toy. its results are useless. Take this as a fact which we can debate elsewhere some other time. I am talking expensive film scanners here, not some 0 8 15 flatbed. I'm not sure if it's really xsane's fault or if backend support for film scanners in sane(-backends) is just week. I think I outlined this a couple of years ago. Basically the sane api simply does not have provision to communicate everything required to talk to even a prosumer film scanner let alone a professional one. For starters there is no provision for IR channel data, multisample scanning, focusing, and batch scanning i.e. I have just inserted a holder with six negatives scan 2 through 4. Or I have just inserted an APS film please scan negatives 1 through 6 and 12 through 30 while I have a cup of coffee. Then we require a front end to deal with all these issues, and all the other bits and pieces like comprehensive negative colour correction. However as far as I am aware zero progress has been made on any of these fronts, even though IR channel provision has made it's way into sub 100GBP flatbed scanners in the meantime. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Northumberland, United Kingdom. Tel: +44 1661-832195
