> I think that number 3) would be a bug and would need to be fixed,
> because by prepending the header to the unknown frame, the front-end
> will have effectively corrupted the data stream.
Yes. It's wrong behaviour to pretend you understand unknown formats --
If you can't think of anything better to do: Scream and Shout and
Stamp your feet so that the user knows something is wrong.
> NOTE: This is how I understand scanimage behavior when encountering
> an unexpected frame type:
>
> 1) if the FRAME does not need to be buffered (lines >= 0)
> The output will be the raw data with a PNM header prepended.
> 2) if the FRAME needs buffering (lines < 0, size not known a-priori)
> The output will be a PNM header only.
>
> Niether one of these is useful behavior and would necessitate a minor
> change to scanimage. I'll volunteer to make that change.
Sounds good. Presumably you'll spit the raw data straight out onto the
stdout file decriptor? That way:
scanimage -d interesting:jpeg-device > buttercup.jpg
Gets you a JPEG in buttercup.jpg ready for further processing
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com