--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
On Sun, Apr 14, 2002 at 10:45:21PM +0200, Oliver Rauch wrote:
> Henning Meier-Geinitz wrote:
>
> > Some questions and comments that came to my mind while reading the
> > standard the first time (so I may have missed something):
> >
> > * 3.2 Image data format and 3.2.1 Image transmission:
> > The radical change in frame types and frame transmission should be
> > mentioned earlier in the text.
>
> Suggestions are welcome.
Ok. I append a LaTeX code for a revised chapter "Image data format". I
mostly moved paragraphs around. I removed the exact descriptions for
the old frame types. Added references to sane_get_parameters. Added
definition of the order of bits in 1-bit modes.
What do you think about it?
> > We don't know if all the information
> > about 1, 8, 16 bits per sample are true for some MIME format, do we?
>
> May be correct. Possibly the value depth makes no sense in MIME format.
I moved this part to SANE_FRAME_RAW.
> > I'm not sure if we should even mention the old SANE1 frame types.
> > If someone really wants to use them, he should looak at the SANE1
> > standard. Or is tehre a special reason for this?
>
> Once is to tell why values 5 and 6 are used for SANE2 frames,
> onther thing is the idea that a frontend may decide to support
> SANE1 and SANE2 backends.
That's ok. But I don't think we should describe all the old data
structures in detail in SANE 2. The frontend implementor has to read
the old standard anyway (e.g. for the changed sane_open() call).
> It also would be possible to start from 0 and remove the SANE1
> frame types. But this way it would be harder to write a
> SANE1+SANE2 frontend.
> This is one of the points that have to be discussed. May be
> it makes more sense to remove all SANE1 things.
Mention that the types were used by version 1 and add a "don't use
flag". Not more.
> >
> > Add a reference to the chapter about sane_get_parameters fort the exact
> > meaning of formatdesc.
>
> There is a describing point formatdesc in sane_get_parameters. What
> do you think about?
That's ok. I just wanted a link to that desription (\ref{some_section}).
> > * SANE_Device.email_backend_author: I'm not sure, if this really
> > belongs into the structure (and not into the man page and HTML page).
> > If it's in the code, I would prefer to also have the name of the
> > author in this entry. This makes it easier to find him when the
> > email address doesn't exist any longer.
>
> The email address should look like this:
>
> Oliver Rauch <oliver.ra...@xsane.org>
Ok, better explicitely talk about the name.
> it makes sense to put the email address into the backend because
> if someone uses a backend via network he may not have the manpage
> of the backend.
Ok. Maybe also a URL to the backend homepage?
> > * SANE_Device.device_location: I don't understand this one. Which
> > location? My device is on the table 1.5m to the right of me :-)
> > Do you mean the backend? A URL to the vendor? Or a path name?
> > And why should it be read from the config file (the backend doesn't
> > even need one and I'm not sure if we should mention this).
>
> No, I think about a real physical location.
> Imagine you are at work or in the university and 200 computers have
> access to a scanner via network, then it is necessary that a user
> can find out where he finds the scanner, so the entry could look like
> this:
>
> building 93, 2nd plane, room 2113
Ah, ok. Then my first guess wasn't that wrong. Maybe just add your
example to the descriptions, that makes it pretty clear.
> > * SANE_Device.backend_capability_flags: Can you give an example for
> > such a flag and what the frontend should do with it?
>
> This is planned for future extensions.
> Let?s say we add a new feature that is not defined in the sane-2.0.0
> standard (e.g. audio support for a camera) then it is necessary that
> the backend can tell te frontend if special features are supported or
> not.
But the features must be supported by some addition function or frame
type in this case, needn't it?
> > * 4.2.10 InternationAlization (missing "a").
> > Be clear. "Should" is should. There is no "preferrable" necessary.
> > Maybe we should cite the RFCs' meaning of "MUST" and "SHOULD"
> > somewhere in the standard?
>
> We can write "must" but I do not want to force this here, it also does
> work when the backend is written in chineese and we have a chineese
> to english translation
Ok, then just use "should". I didn't like the "preferrable".
> > As an addition, we should make clear what can be changed in a
> > SANE_Option_Descriptor and when. Currently it must only be "vaild" and
> > the address stay the same. E.g. is the backend allowed to change the
> > type of option? Or only capabilities?
>
> I think it is allowed to change all in sane_control_option when
> SANE_INFO_RELOAD_OPTIONS is set - or am I wrong?
Be carefull. You can change the value and (at least I think so)
SANE_CAP_INACTIVE. You don't know if SANE_INFO_RELOAD_OPTIONS means
that the options are reloaded immediately. info can even be 0.
Even when sane_get_option_descriptor is actually called, it's
currently not allowed to change the returned address until sane_close().
The net backend had this bug until recently.
