#223 "Auto length detection" option does not work with ScanSnap IX500

[Faheem Mitha]

Hi Jeffrey,

I just tried using the enabling the "Auto length detection" option under the Advanced tab. Scanning a page just gives a white rectangle, and a lot of gibberish prominently featuring the string GLOB is printed to standard output. I attach a 15MB log file created by just scanning one side of a page. This was produced using the command you had told me to use before to produce a log file, namely:

gscan2pdf --debug &> /tmp/gscan2pdf.log

This is not a super-big deal, because one can usually get by with using the closest approximation to the paper size in the standard classes, but it might be a useful option in some cases.

I've tried using this before, and got similar results, but for whatever reason I haven't reported it before. At least, I don't think so.

Regards, Faheem Mitha.

[Faheem Mitha]

I forgot to say that the gscan2pdf version is 1.5.0.

gscan2pdf --version
gscan2pdf 1.5.0

[Jeffrey Ratcliffe]

The order of a log file created like that is not well defined. Please start gscan2pdf as follows:

gscan2pdf --log=/tmp/gscan2pdf.log

reproduce the problem, and post the new log file. You will find that it is also echoed to stdout, but you can ignore that.

[Jeffrey Ratcliffe]

What does the following give you?

scanimage --resolution=200 --source='ADF Front' --ald=yes > image.pnm

Does it result in a valid PNM?

The problem is that in order to support this, I'd have to be able to reproduce it. I imagine that gscan2pdf would have to buffer the image until the scanner had finished, ask the scanner what it had detected, and then write the image.

Interestingly, the test backend offers a hand-scanner emulator, which gives me the same error, so perhaps I CAN reproduce the problem.

[Faheem Mitha]

On Mon, 20 Jun 2016, Jeffrey Ratcliffe wrote:

What does the following give you?

scanimage --resolution=200 --source='ADF Front' --ald=yes > image.pnm

Does it result in a valid PNM?

This might be a dumb question, but how do I determine whether a PNM is
valid? View it with imagemagick's display, or something else?

I'll get back to you in a couple of hours. We've got a domestic plumbing
emergency here. Thanks for the quick response.

Regards, Faheem Mitha

[Faheem Mitha]

gscan2pdf --log=/tmp/gscan2pdf.log

output attached.

[Faheem Mitha]

scanimage --resolution=200 --source='ADF Front' --ald=yes > image.pnm
scanimage: setting of option --source failed (Invalid argument)

In any case, I'm unclear what the point, or indeed the meaning, of this command is.

[Jeffrey Ratcliffe]

scanimage is the command-line interface to the SANE library and the only frontend maintained by the SANE project. i.e. if you can't make the ald option work with scanimage, then I don't have much chance of success with gscan2pdf. I don't doubt it will work, but I wanted to make sure.

Evidently, I got the source option wrong.

scanimage --help

will tell you what it should be.

To test the results PNM, any image viewer should do the trick. imagemagick has the "display" command, or the "identify" command.

[Jeffrey Ratcliffe]

I realised that I could reproduce this with the "hand-scanner" option in the test backend, and that the fix was easy.

[Faheem Mitha]

Hi Jeffrey,

Nice work. Can you tell me what the problem was and the fix is?

[Jeffrey Ratcliffe]

Here's the patch

--- a/lib/Gscan2pdf/Frontend/Sane.pm
+++ b/lib/Gscan2pdf/Frontend/Sane.pm
@@ -842,7 +842,9 @@ sub _write_buffer_to_fh {
     }
     _thread_write_pnm_header( $fh, $parm->{format}, $parm->{pixels_per_line},
         $image->{height}, $parm->{depth} );

-    for ( @{ $image->{data} } ) { goto CLEANUP if not print $fh }
+    for my $data ( @{ $image->{data} } ) {
+        goto CLEANUP if not print {$fh} $data;
+    }
     return;
 }

[Faheem Mitha]

Hi Jeffrey,

Thanks for the patch. Can you explain in simple words, suitable for a layman, what the problem was?

Also, did you get my email regarding donations?

[Jeffrey Ratcliffe]

Stupidity on my part.

Normally, the scanner knows in advance how big the scan is, and therefore gscan2pdf takes this information, writes the image header first, and then dumps the image data from the scanner direct to the file.

With the automatic length detection option (or hand-scanner), the scanner passes the image size to gscan2pdf after the data, so gscan2pdf has to buffer the data. So far so good. But I don't have such a scanner and could test the code. Then the penny dropped that the test backend has the hand-scanner option.

The patch is very simple. Previously, I was trying to be too clever. Perl uses the magic variable $_ in many place if you don't specify one. The "for" construct was correctly setting $_, but "print" was not using it, and instead of writing the contents of$_to the file, it was writing the name of the filehandle to the terminal window. This was the GLOB-HASH you were seeing.

[Faheem Mitha]

Hi Jeffrey,

Thanks for the explanation. Did you mean to write:

But I don't have such a scanner and could not test the code.

?

Looking forward to testing the fix.

[Faheem Mitha]

Incidentally, I'm surprised that the file handle is so large. Is this necessary? What information does it contain?

[Jeffrey Ratcliffe]

Yes. Not enough coffee. I meant that I couldn't test the code before.

The file handle itself is not large. And the Perl wrapper is only a blessed hash and also not large. The reason that it produced so much output is that rather than writing the buffer a byte at a time to the file, the hex address of the blessed hash was printed to the terminal window, once for every byte.

[Faheem Mitha]

HI Jeffrey,

As of 1.5.2, the "Auto length detection" option "works", in the sense that it produces a scan. However, the scan doesn't size correctly to the page (which in this case is a paper check) and there is a big black rectangle below the actual scan.

I'm not completely clear what the "Auto length detection" option is supposed to do, but I presume it should size the PDF scan correctly to the paper.

Should I open a separate issue for this?

[Jeffrey Ratcliffe]

If it isn't working properly, then I'm happy dealing with it here. Please give me:

• another log file from: gscan2pdf --log=log
• an example of the output, explaining which is the direction of the scan.
• the scanimage.log and image.pnm files from: scanimage --ald=yes 2> scanimage.log > image.pnm

[Faheem Mitha]

Hi Jeffrey,

On Mon, 10 Oct 2016, Jeffrey Ratcliffe wrote:

If it isn't working properly, then I'm happy dealing with it here.
Please give me: another log file from: gscan2pdf --log=log an example of
the output, explaining which is the direction of the scan. * the
scanimage.log and image.pnm files from: scanimage --ald=yes 2>
scanimage.log > image.pnm

Ok, I'll give that a try later today. Thanks.

                    Regards, Faheem Mitha