Hi, 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 feature :-) Bye, Henning
