[sane-devel] help with improving text scans
On 20.12.2008 23:15, Jeffrey Ratcliffe wrote: 2008/12/20 abel deuring adeuring at gmx.net: Just open sane's .mo file with gettext :) (OK, I'm more involved with the competition -- Python --, so I don't know if a gettext implementation for Perl exists, but I would be really suprised if it doesn't.) Locale::gettext is the Perl module, which gscan2pdf uses for its own localisation. #!/usr/bin/perl use warnings; use strict; use Locale::gettext; use POSIX; # Needed for setlocale() setlocale(LC_MESSAGES, ); my $d = Locale::gettext-domain(sane-backends); print $d-get(Preview), \n; works. What I really meant is that scanimage doesn't seem to use SANE's translations, which makes it difficult to provide a consistent interface for the different frontends scanimage/scanadf/libsane-perl. Ah, I missed that point. But you are right - I can get the English strings from scanimage, and feed them through gettext. Unfortunately scanimage --help only gives the option titles for the groups. Can the backends be induced to give the option titles in some debug mode? Well, since you have now libsane-perl -- do you really need to call scanimage or scanadf from gscan2pdf anymore ;) ? Abel
[sane-devel] Mustek BearPaw 2448CU pro
I am an owner of the scanner Mustek BearPaw 2448CU pro and I'd like to use it on linux system. I'm not a programmer but since there is a backend for a similar scanner (BearPaw 2448 TA pro) I'd like to do my best to adapt mustek_usb2 backend to support this scanner. I'm using ubuntu 8.10 but I downloaded last CVS sane-backends I changed line 148 in mustek_usb2.c from SANE_FALSE,/* Is this a CIS scanner? */ into SANE_TRUE,/* Is this a CIS scanner? */ Because 2448cu is a CIS scanner and not a CCD one like 2448 TA I think that developer's intention was tu support CIS sensors but maybe the support is incomplete. Then I replaced ProducId 0x409 with 0x408 in mustek_usb2_asci.c BearPaw 2448CU Pro, /* Device model name */ (mustek_usb2.c line 128) sane_device-model = strdup (BearPaw 2448 CU Pro); (mustek_usb2.c line 2082) Now scanner is recognized from lsusb when I try to scan with scanimage leds get on, motor start but it doesn't stop at the end and bumps with a noisy tr until I unplug the usb cable. When I try to scan with xsane leds get on, motor moves and suddenly stops with a long beep. In both cases it seems that rgb data are read but an image made of thick red vertical lines is returned as output I tried to analyze the debug output setting SANE_DEBUG_MUSTEK_USB2=255 but in both cases there is no error. Each asic function enter and exit without errors. What could I do at this point?
[sane-devel] Qyestion about usb packet logging
I have had some problems recently with usbsnoop (sniff-bin-1.8) which I wonder if anyone else has encountered and, if so, whether any workarounds are known: 1. Contents of the window wherein the hardware is listed and one can choose to install or uninstall are jumping or flickering approximately once per second. 2. When one tries to install a particular device, the highlighting jumps away from the device one has chosen, as soon as the window flickers. Problems 1 and 2 together are making my installation of usbsnoop to be totally unusable. I spent several hours yesterday trying to get something out of it, and did not succeed. Compounding these problems and perhaps related to them is 3. There does not seem to be any obvious way to remove stale entries from the usbsnoop choice window. Rather, it seems to contain every device which has ever been hooked up to the machine at any time in the past, and some of the devices indeed are listed several times, with apparently duplicate entries. Reinstallation of usbsnoop does not seem to help with any of these problems. I have tried that, with no noticeable result. In particular, the relevant information for all of those old, stale entries and duplicate entries is obviously kept somewhere. Perhaps it would help to delete all that old cruft. But where is it kept? The problems described are, unfortunately, in effect on both of the machines which I use for testing things. One of them is an old machine running Win98, and the other one is a slightly newer one running Win2K. Both of the machines otherwise seem to be in perfect working order and run Linux just fine. Therefore, I do not suspect any hardware problems on either of the machines. I wonder if anyone has ever encountered a similar problem, and, if so, whether anyone has ever figured out a way to overcome the problem. Yesterday, I did download a copy of the source code for sniff-bin-1.8 as well as the binary. Perhaps I could find some clue in that if I knew where to look. I would like very much to learn any suggestions about how to deal with these problems. Theodore Kilgore
[sane-devel] Qyestion about usb packet logging
all three problems solved: http://www.pcausa.com/Utilities/UsbSnoop/ allan On Sun, Dec 21, 2008 at 3:16 PM, kilgota at banach.math.auburn.edu wrote: I have had some problems recently with usbsnoop (sniff-bin-1.8) which I wonder if anyone else has encountered and, if so, whether any workarounds are known: 1. Contents of the window wherein the hardware is listed and one can choose to install or uninstall are jumping or flickering approximately once per second. 2. When one tries to install a particular device, the highlighting jumps away from the device one has chosen, as soon as the window flickers. Problems 1 and 2 together are making my installation of usbsnoop to be totally unusable. I spent several hours yesterday trying to get something out of it, and did not succeed. Compounding these problems and perhaps related to them is 3. There does not seem to be any obvious way to remove stale entries from the usbsnoop choice window. Rather, it seems to contain every device which has ever been hooked up to the machine at any time in the past, and some of the devices indeed are listed several times, with apparently duplicate entries. Reinstallation of usbsnoop does not seem to help with any of these problems. I have tried that, with no noticeable result. In particular, the relevant information for all of those old, stale entries and duplicate entries is obviously kept somewhere. Perhaps it would help to delete all that old cruft. But where is it kept? The problems described are, unfortunately, in effect on both of the machines which I use for testing things. One of them is an old machine running Win98, and the other one is a slightly newer one running Win2K. Both of the machines otherwise seem to be in perfect working order and run Linux just fine. Therefore, I do not suspect any hardware problems on either of the machines. I wonder if anyone has ever encountered a similar problem, and, if so, whether anyone has ever figured out a way to overcome the problem. Yesterday, I did download a copy of the source code for sniff-bin-1.8 as well as the binary. Perhaps I could find some clue in that if I knew where to look. I would like very much to learn any suggestions about how to deal with these problems. Theodore Kilgore -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin
[sane-devel] Qyestion about usb packet logging
On Sun, 21 Dec 2008, m. allan noah wrote: all three problems solved: http://www.pcausa.com/Utilities/UsbSnoop/ allan But will that new version run on Win2K? Says there it will not. Of course, if that is the only solution I guess I have to do it. Theodore Kilgore
[sane-devel] help with improving text scans
2008/12/21 abel deuring adeuring at gmx.net: Well, since you have now libsane-perl -- do you really need to call scanimage or scanadf from gscan2pdf anymore ;) ? It is nice to have them to fall back on - there was one point a couple of Ubuntu releases ago where Xsane, etc. had not quite kept up with libsane, and so the only scanning programs that worked with one particular set of scanners were scanimage, and therefore gscan2pdf. But if it were possible to do everything with scanimage, then I wouldn't have written libsane-perl... Regards Jeff
[sane-devel] Mustek BearPaw 2448CU pro
There was a thread about this same scanner last month. http://lists.alioth.debian.org/pipermail/sane-devel/2008-November/023053.html The author got about as far as you did. Next you are going to have to do some usb snooping on a windows machine using either http://www.pcausa.com/Utilities/UsbSnoop/ or http://benoit.papillault.free.fr/usbsnoop/. Then try to figure out the meaning of the snoop logs. Snoop logs are too big to post here, so you will need to find a free web site to post them to. I've used google site for this in the past. Jack McGill --- On Sun, 12/21/08, Damiano Rossi damianorossi at paranoici.org wrote: From: Damiano Rossi damianorossi at paranoici.org Subject: [sane-devel] Mustek BearPaw 2448CU pro To: sane-devel at lists.alioth.debian.org Date: Sunday, December 21, 2008, 9:39 AM I am an owner of the scanner Mustek BearPaw 2448CU pro and I'd like to use it on linux system. I'm not a programmer but since there is a backend for a similar scanner (BearPaw 2448 TA pro) I'd like to do my best to adapt mustek_usb2 backend to support this scanner. I'm using ubuntu 8.10 but I downloaded last CVS sane-backends I changed line 148 in mustek_usb2.c from SANE_FALSE,/* Is this a CIS scanner? */ into SANE_TRUE,/* Is this a CIS scanner? */ Because 2448cu is a CIS scanner and not a CCD one like 2448 TA I think that developer's intention was tu support CIS sensors but maybe the support is incomplete. Then I replaced ProducId 0x409 with 0x408 in mustek_usb2_asci.c BearPaw 2448CU Pro, /* Device model name */ (mustek_usb2.c line 128) sane_device-model = strdup (BearPaw 2448 CU Pro); (mustek_usb2.c line 2082) Now scanner is recognized from lsusb when I try to scan with scanimage leds get on, motor start but it doesn't stop at the end and bumps with a noisy tr until I unplug the usb cable. When I try to scan with xsane leds get on, motor moves and suddenly stops with a long beep. In both cases it seems that rgb data are read but an image made of thick red vertical lines is returned as output I tried to analyze the debug output setting SANE_DEBUG_MUSTEK_USB2=255 but in both cases there is no error. Each asic function enter and exit without errors. What could I do at this point? -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org
[sane-devel] Translations (was help with improving text scans)
2008/12/20 Jeffrey Ratcliffe jeffrey.ratcliffe at gmail.com: Now I remember the other problem with a general interface - internationalisation. scanimage, for instance, doesn't seem to have been translated: Speaking of which, Ubuntu has translations for sane-backends that aren't in CVS: https://translations.launchpad.net/ubuntu/intrepid/+source/sane-backends/+pots/sane-backends A merge might be easy or difficult, depending on how much the template has changed... Regards Jeff
[sane-devel] Avision bug (was: Re: Suicidal Child Process - SANE)
On Tue, Dec 9, 2008 at 10:48 AM, Mattias Ellert mattias.ellert at fysast.uu.se wrote: m?n 2008-12-08 klockan 09:46 -0500 skrev m. allan noah: After some private mails with Ian, it seems this is a bug in sane-avision: during sane_cancel(), the backend calls: sanei_thread_kill (s-reader_pid), but s-reader_pid is 0, which signals the entire group. There is a test to try and avoid this, but it relies on prior code to have set s-reader_pid = -1, which has not happened in the case of no paper. I just expanded the test to require a positive value, since the pid should never be negative anyway? My fix has just been commited to CVS (backend version 289 nice round number for Ford and Studebaker fans). Ian and Rene- please test. allan This breaks the MacOS X port. The PID number (being a pointer) can be arbitrary large, and when cast to an integer it can easily overflow to a negative value. The code was fixed for this problem by removing all places where the code was checking for a PID 0. For the avision backend this was done here: https://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/backend/avision.c.diff?r1=1.38;r2=1.39;cvsroot=sane Your commit: https://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/backend/avision.c.diff?r1=1.43;r2=1.44;cvsroot=sane reintroduces the problem fixed by the earlier commit. Please revert it and fix the new problem in a way that doesn't break the MacOS X port. Ok, so what is the correct fix? If OSX is using pthread, is it enough to make SANE_Pid pthread_t? allan -- The truth is an offense, but not a sin
