[sane-devel] Re: Feature freeze for sane-backends 1.0.13 is active
Mon, 3 Nov 2003 13:23:12 +0100
On Mon, Nov 03, 2003 at 04:34:45AM -0500, Varol Kaptan wrote:
> The second problem I have is the following: It seems like the epson
> scanners can only scan areas with a width which is a multiple of 8.
> When I scan a 1in x 1in area at 600 dpi I get a 600x600 ppm (that's
> fine). When I scan the same area at 300 dpi, though, I get a 296x300 ppm
> instead of the 300x300 (since 300 is not a multiple of 8). It turns out
> that the driver will round down to a smaller value that is a multiple
> of 8 - I thought that it would be more appropriately to scan 304x300
> and then cut off the excess.
Other scanners show a similar behaviour. Sometimes it's even necessary
to scan a multiple of 64 pixels.
> The easiest way to do this is to have for
> example bytes_per_line=3*304 and pixels_per_line=300 (padded image
> format) and I have a working version (modified epkowa, but same applies
> to epson backend).
Why not just crop the lines? That requires two buffers and some
copying, but that's shouldn't be a real problem on anything faster
than 33 MHz. I.e. everything is done in the backend itsself, the
frontend doesn't need to know of the limitations of the backend.
> If you look at the developer documentation (latest sane.ps, bottom of
> page 29) you will see that frontends are supposed to be able to deal
> with such padded image formats. Unfortunately none of the frontends
> (I tested scanimage and xsane) do support it. Is this a bug in the
> frontends or in the documentation (i.e. should the frontends be
> fixed, or should I forget about padded images) ?!?
You can test that also with the "test" backend. The frontends are
buggy (or don't support that feature). I don't know of any other
backend that uses that feature so I guess it's easier to just avoid
using it. Until your posting I haven't known any useful usage for that