Here's what I think (he says, opening the gas can in preparation for
adding fuel to the fire:-)
I think that frame format should be selected as an option, the default
always being one of the existing types. The "format" option should
be a well-known option with type SANE_TYPE_INT and constrained by
SANE_CONSTRAINT_WORD_LIST.
If the application does nothing to this option, then the format that
the scanner uses to send the data should be one of GRAY or RGB. If the
application is old, it will not ask for an advanced frame type. If
the user asks for an advanced frame type because the old application
has a GUI that blindy offers the option, then oh well.
The format needs to be a well known option because an application may
support some advanced types and may want to ask an arbitrary device what
types is supports. The application may for example be asked by the user
to scan to a jpeg file. The application can look in the "format"
constraints to see if hardware JPEG support exists, and if so use that.
It is hard to get old applications to deal with JPEG because the size
of the frame is difficult to express with the SANE_Parameters structure.
Do you include accurate image dimensions in pixels_per_line and lines?
If we want to avoid an enumeration, then perhaps the "format" option
can be instead a SANE_TYPE_STRING with the SANE_CONSTRAINT_STRING_LIST
constraint. You can use mime types for the strings. The problem with
this is that the format in the SANE_Parameters structure will need to
be changed to "const char*".
This is an incompatible change. This would be SANE 2.0, if ever.
(It has the advantage of supporting arbitrary multimedia.)
...
Anyhow, to summarize. If we simply add new frame formats and define
them as advanced or optional, drivers will be expected to support the
existing formats as defaults. This will allow old applications to work.
Add wording to the standard something like:
"All SANE drivers must support at least one of SANE_FRAME_GRAY
and SANE_FRAME_RGB. All SANE applications must support *both*
SANE_FRAME_GRAY *and* SANE_FRAME_RGB. The driver must provide
data in one of these standard formats unless requested otherwise
by manipulation of its "format" option."
should protect most existing applications.
We should define a well known "format" option that enumerates the
formats that the device supports so that a format-aware application
can make some informed decisions. For example, a smart GUI application
that supports writing files but does not have a JPEG compressor can
check with the driver, and gray out the option if the hardware doesn't
have compression.
IMPORTANT POINT:
** Once the well-known option is added, new "advanced" frame formats
** can be added liberally without ever again 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