We can simply associate a short text string with each defined type, in
the standard and in backend header files, and any frontend which can't
handle the data format it receives (presumably because of a user
advanced setting or badly behaved backend) will just look in the
getparm results for "frame_description" and say...
Sorry, I can't handle image data in the format:
<insert short description here>
Save to a file anyway? (Y)es / No
The other point which _keeps_ being made by proponents of MIME in this
debate is that there will "inevitably" be a huge number of formats to
support -- yet this is hardly bourne out by an examination of MIME
or by looking at scanners "In the wild". The four new data formats
(and two other formats) suggested by backend writers so far seem to
cover a broad range of high-end scanners.
Before you make this argument again, I want _evidence_ that we're going
to be swamped by more image formats.
Further, I think SANE's use of standards-based formats (like JFIF)
is important because SANE is also a Free Software project. Wherever
we have a choice we should encourage Open standards rather than
Proprietary technology. In the backend we have little choice, but
in the SANE protocol and API we *do* have a choice.
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com