<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.2">
</HEAD>
<BODY>
On Sat, 2008-06-07 at 22:09 -0400, m. allan noah wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
> JPEG output works fine. Is the compression done by the scanner or the
> backend?
the scanner itself. it appears that every fi-series Fujitsu might be
able to do this.
</PRE>
</BLOCKQUOTE>
When I was on windows I noticed that the jpeg quality was pretty bad compared to scans from my flatbed compressed to the same file size. But then, the windows software applied a very 'happy' color adjustment, which could not be changed, and which really made the compression artifacts stand out - and uncompressed output was not available. Better redo those tests now...<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> 2. The mechanism for determining the color interlace mode is now
> automatic, so please see if color scans look weird, particularly if
> the scanner has done a color scan in windows without being power
> cycled.
>
> Not really tested, but no problems observed.
if a non-jpeg color scan looks ok, then that is all the testing we need really.
</PRE>
</BLOCKQUOTE>
All good then.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> [...]
> The page-height option works as expected in combination with
> dfdetect=Length except that dfdiff seems to be fixed at 10mm.
odd. do you get an error when you set the other lengths?
</PRE>
</BLOCKQUOTE>
No, the value is just ignored. The fixed difference may actually be 12 mm, but maybe there is some tolerance to these values?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
A long page
> (paper jam) occurring as the last sheet of a batch is detected only on the
> next invocation of scanimage. (May be a limitation of the scanner's
> detection mechanism, or a scanimage issue?)
hmm, i need to look into that. it is possible that the scanner does
not report the error to us until after the page is fully sent, so
there is no way to inform the front-end.
</PRE>
</BLOCKQUOTE>
It is not a big issue, but of course it would be more elegant to always have it detected. <BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> Some additional observations about this scanner, for the record:
> [...]
> - the overscan option seems to be ignored, although I am not sure I fully
> understand its purpose. The output looks identical, with no additional space
> at the top. What is the bgcolor option mentioned in the --help -d output?
when overscan is enabled, the x and y values of the scan area can
extend slightly larger than the page width, and the scanner outputs a
few mm of the background before the top of the page hits the sensor.
if your machine has a white background stripe behind the sensor, try
scanning a darker sheet and see if the white background shows above.
</PRE>
</BLOCKQUOTE>
It does not. For the same values of t, l, x, y the scans with and without overscan are as identical as can be expected.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
the bgcolor option is only for scanners which have a servo driven
black/white background in the adf, such as the fi-5120C
</PRE>
</BLOCKQUOTE>
Aha... :-)<BR>
<BR>
Best regards,<BR>
Jacob Nielsen<BR>
<BR>
</BODY>
</HTML>