There should be some way for the frontend and backend to negotiate formats,
and a small core set of formats that both must support. For example, if
my scanner-with-compression driver is hooked to a frontend that knows
of none of its high performance formats, then the driver, to be compliant,
should be able to resort to RGB or somesuch.
On the other hand, I will be able to write a nifty fastscan program that
*does* know about SCAN_FRAME_JFIF and can do all the right things and
can ask for the JFIF format from the scanner. Great!
So, I think there must be a small set of "must have" frame formats,
and a larger set of "standard optional" formats that handle some of
the common and obvious formats, like JPEG. The negotiation process could
also allow for a set of local or private formats that are outside any
sort of standard definition.
If all applications must support any combination of frame types, then
the application writers will go nuts. If, on the other hand the scanner
vendors must work with an excessively short list of formats, they will
not be able to demonstrate the value of their nifty expensive equipment.
Maybe there should be some standard option that the application can query
to get a list of all the supported frame formats from the scanner. This
would be sufficient, and allow new frame type to be added in the future
without breaking compatibility.
-- Steve Williams "The woods are lovely, dark and deep. steve@icarus.com But I have promises to keep, steve@picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com