> rickand@gemse.fr said:
> > The problem with defining all thinkable formats is that it adds a
> > considerable amount of complexity to the frontend which is only used
> > for one specific backend which is able to produce that one particular
> > data-type.
>
> 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.
Good point.
The frontend is already able to ask for the frame formats the backend uses:
if the backend makes the different formats available as "mode"
(where normally Grayscale, Halftone and RGB can be selected)
and defines modes like "Color RGB" or "Color JFIF", the frontend could select
each mode and read the parameter block and take a look at the
frame format. If it supports the frame format, it enables that mode, if
it does not support that frame format, it hides that mode.
Does the backend need to know what a frontend can handle?
> 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.
I don`t know if we really need "must have" frame formats.
If there is a frontend that only can handle JPEG-frames, where
is the problem?
> The negotiation process could
> also allow for a set of local or private formats that are outside any
> sort of standard definition.
Hm, sounds a bit strange to define "private" formats in the
SANE STANDARD.
> 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.
I think we must find a good way between that.
If a frontend is not able to handle a special file format: ok - no problem
We should add formats that will be used by different backends.
That will e.g. be some formats for still cameras.
If there is one backend that uses a prorietary format it has to convert
it into another format or it has to pass it trough in raw format.
> 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.
Adding a new format does not break the compatibility.
If a backend sends an image in an unknown frame format,
the frontend simply does say "don't know to handle SANE_FRAME_xyz".
Bye
Oliver
-- EMAIL: Oliver.Rauch@Wolfsburg.DE WWW: http://www.wolfsburg.de/~rauch
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com