Hi, I'm lazy and didn't feel like removing the padding bytes from the image data that I pass to the frontend via sane_read(). The SANE API specification for sane_get_parameters() [1], is very clear about what SANE frontends should be capable of WRT padding bytes:
Note that the number of bytes per line can be larger than the minimum value imposed by the right side of this equation. A frontend must be able to properly cope with such "padded" image formats. [1] http://sane.alioth.debian.org/html/doc012.html#s4.3.8 That is, the bytes_per_pixel value of SANE_Parameters only has a lower limit that is determined by pixels_per_line, format and depth. There is no upper limit (other than whatever the maximum of SANE_Int is). Let's say we scan a 1 pixel wide image in SANE_FORMAT_GRAY with 8 bits to the sample. Then the lower bound on bytes_per_pixel is 1, the upper bound is 2^31 - 1. If it pleases me to use the latter (for whatever devious reasons), the frontend should cope. Much to my chagrin, I found out that scanimage and xsane do NOT cope properly with such padded image formats. Much to my surprise, however, simple-scan does (but has a bunch of problems of in own in terms of being a SANE frontend). I haven't checked any further. Any chance that these (and other non-compliant) SANE frontends get fixed and, if so, anytime soon? It's a bit embarrasing that even scanimage does not live up to the expectations of the SANE standard ... :-( In the mean time, though, I guess I have little choice but to not be lazy and rip out the padding bytes in the backend ... :-(( Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
