Thank you, Allan, for the very quick reply. I hate to be the harbinger of bad news, but there is only bad news or worse news to choose from. It is not directed at you. Here it is:
On 15-06-27 02:35 PM, m. allan noah wrote: > Can you try using scanimage -B ? TL;DR: Does not change a thing, and I had to use --buffer-size because the -B switch is broken in version 1.0.23 that is distributed from the Ubuntu repositories. I candidly admit that before Allan's hint I did not think of changing the input buffer size manually, despite being familiar with the manpage, having read it many times over the years. Not this time, alas. Why should there be a need to manually set the input buffer size when the size needed can be calculated from the other inputs? -B itself did not work -- see worse news below, but when I used --buffer-size=64 (or 256), the change of input buffer size was confirmed by the sane_read() debug output line telling me that maxlen=65536 (or 262144) and the result was the same: scanner timeout. Worse news: I may have found what I think is an IN*SANE* inconsistency between the man page and the actual response of scanimage. Quoting the man page: | The -B or --buffer-size changes the input buffer size | from 32KB to the number kB specified or 1M. First of all, -B is not equivalent to --buffer-size. All of the following resulted in maxlen=0: scanimage -B=64 scanimage -B=64k scanimage -B=64K scanimage -B=65536 Worse, all of the following resulted in an 'argument without option error', making the -B switch inconsistent with other single letter switches such as -l, -t, -x and -y, all of which accept a space and a numeric input after the space: scanimage -B 64 scanimage -B 64k scanimage -B 64K scanimage -B 65536 Finally, --buffer-size= yields different results than -B=. Sometimes these results are not what is intuitively expected: scanimage --buffer-size=65536 maxlen=67108864 way too big scanimage --buffer-size=64K maxlen=65536, as expected scanimage --buffer-size=64 maxlen=65536 scanimage --buffer-size=64M maxlen=65536, way too small scanimage --buffer-size=1M maxlen=1024 way too small and the worse one: scanimage --buffer-size=64insaneblurb yields maxlen=65536 It seems that the text input after the numbers is simply ignored. So in addition to my issue not being solved, I now have a few question about scanimage: (1) are there plausibility checks of the command line switches and if so why did they not catch the gibberish that I enter after --buffer-size? (2) has the difference between -B and --buffer-size been introduced by mistake, or is it intentional? What should be fixed, the code or the man page? (3) what prevents the automated calculation of the buffer size according to the very simple formula that is X/254*D*B, where X is the scan width in millimetres as entered with the -x parameter, D the DPI as entered with the --resolution parameter, and B the number of bytes used per pixel, based on the --mode parameter? I recall the times when memory was at a premium, when programming in Assembler on CPUs such as the 6502 or the 8048 one had to think hard of limiting buffers to a few bytes, but in this day and age does a 32K default limit make any sense? Yuv -- Yuval Levy, JD, MBA, CFA
signature.asc
Description: OpenPGP digital signature
-- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
