# Re: SANE frames

Tom Martone (tom@martoneconsulting.com)
Sun, 15 Aug 1999 20:07:52 -0400

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Nick Lamb: "Re: SANE V2"
- Previous message: Stephen Williams: "Re: SANE frames"
- Maybe in reply to: Stephen Williams: "SANE frames"
- Next in thread: Oliver Rauch: "Re: SANE frames"

Nick Lamb wrote:
>
> On Sun, 15 Aug 1999, Tom Martone wrote:
>
> > SANE_FRAME_ASCII: The frame contains a stream of ASCII text.
>
> Wouldn't this normally be associated with an image? If so it might be
> better to do this as multi-frame, with the ASCII frame followed by
> zero or more image frames as appropriate. Then you can explain in the
> standard that a frontend is free to throw away the ASCII frame, and
> hope there are image frames following it..?
Yes, it would be associated with an image in almost all cases. I
thought that the multi-frame approach would be a bit more difficult
for the front-ends to deal with, as well as more difficult to specify.
I was planning to leave the chore of associating the barcodes with the
images as a separate issue handled outside of the frontend. The
images and text frames arrive in a predictable order (as defined by
the backend documentation), so the association could be done later
as a separate step. Not that it is all that important, but the text
frame with the barcodes is being sent last by the bh backend.

> Some image file formats (Oliver, are you listening?) even make some
> provision for storing short-ish ASCII streams with the image, in a
> more or less general way.
Yes, this is certainly true with TIFF images, for instance. I think
Oliver is putting some commentary in some of the formats, if I remember
correctly. Then it would seem more valuable to get the ASCII and the
images, synced in a multi-frame.

>
> > SANE_FRAME_RAW: The frame contains a stream of bytes (...)
>
> I don't like this much, as everyone already knows, but if it must go
> into SANE 2.0 then I'd prefer that it was numbered away from the rest
> of the sequence in the enumerated type. I'd also like wording in the
> documentation which asks backend creators to suggest new frame types
> when necessary rather than using FRAME_RAW.
>
> Perhaps -1 or 65535 or something? I think a signed integer is used for
> storing this value, but I might be wrong...
Yes, it does seem to be an odd, useless, debugging sort of thing. I guess
what is intended here is to have a way to send data through without the
frontend mangling it in any way. In a way, a frontend should handle
unexpected frame types in the same way as they would handle RAW.

For scanimage, I think it should write both RAW and unexpected frame types
out to stdout without putting a header on it. Maybe for the unexpected
frame type, it issues a warning.

What the gui's will do is another matter. For RAW, they should write
it to their output file without a header. But for an unexpected frame
type they might want to have a dialog with the interactive user, and let
the user have control.

I guess it's a mechanism where the backends can deliver the data, while
the FRAME definition and incorporation into the standard are taking
place. Then the frontends and middle-pieces evolve to find useful ways
to handle the new frame formats, and then the backend sets the newly
defined and sanctioned frame type and the value added features from the
frontend kicks in.

I agree about some wording in the documentation suggesting having
well defined frame types and discouraging the abuse of the RAW format.
Maybe something like this?

SANE_FRAME_RAW: The frame contains a stream of bytes that should not
be interpreted by the frontend in any way. This is a single frame
format. The values specified in the SANE_Parameters structure
should be: depth = 0, pixels_per_line = 0, bytes_per_line = 1, and
lines should contain the number of bytes in the frame or -1 if this
is not known a priori.

NOTE: Backends are encouraged to use a descriptive format whenever
possible. The use of the SANE_FRAME_RAW format should not be a
substitute for adding the necessary additional frame formats to the
SANE standard.

I guess we are in the process of seeing just how burdensome adding some
new frame formats will be.

Tom Martone

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

- Next message: Nick Lamb: "Re: SANE V2"
- Previous message: Stephen Williams: "Re: SANE frames"
- Maybe in reply to: Stephen Williams: "SANE frames"
- Next in thread: Oliver Rauch: "Re: SANE frames"