[sane-devel] test backend & SANE_INFO_INEXACT
jffry at posteo.net
jffry at posteo.net
Mon Jun 14 11:57:20 BST 2021
On 10.06.2021 17:22, Ralph Little wrote:
> The problem with accurately modelling SANE_INFO_INEXACT behaviour in
> the manner suggested is that generally the backend would alter the
> specified value to something that was acceptable, using the flag to
> indicate that the originally requested value could not be precisely
> supported. Because SANE_INFO_INEXACT has these additional effects, I
> wonder if it might be too "scatter-gun" for the test backend to be
> useful since we would have to substitute every subsequent option value
> with something that was different but valid. I can see that being
> quite complicated to implement. I note that the SANE spec also says
> that SANE_INFO_INEXACT can also apply to strings so not very
> straightforward to implement in a general way.
I'm not sure we would have to substitute every subsequent option value
with something that was different but valid. This is the test backend.
But I take your point. The test backend is there to reproduce bugs in
frontends, and some bugs are more subtle than others.
> Perhaps it would be better to try to replicate this specific behaviour
> in sane-test as a valid real-world test case, especially if the
> behaviour is reasonable, if you have a good understanding of the
> user's scenario?
:-) Perhaps. I'd be happy with any way with which I can reproduce the
> If this is a geometry option, does this backend always set
> SANE_INFO_INEXACT regardless of the value supplied or does the
> supplied value have to be rounded, or is the value modified to fit
> within a specific range?
The (geometry) values in question have typically a quant (step) of
something like 0.021163. So if you hit the exact value,
SANE_INFO_INEXACT is not emitted.
> What SANE type does it use for the geometry?
> As an example of what I mean, one of the things I would like to change
> might be the increment value for the resolution, which is hard coded
> to 1 at the moment as a continuous range from 1 to 1200. This is not
> always the case.
> Setting this to something such as 2 would require the use of
> SANE_INFO_EXACT when specifying an even value, resulting in the next
> odd value being substituted.
I've played some more with the test backend. I can get it to emit
SANE_INFO_INEXACT by setting any of the geometry options to a
non-integer. Unfortunately, this doesn't seem enough to reproduce the
bug the user found.
A difference then to the fujitsu backend is that the latter also emits
SANE_INFO_RELOAD_OPTIONS on any change to the geometry options.
How about an additional option to always set SANE_INFO_RELOAD_OPTIONS on
any change to the geometry options?
The test backend does not currently have the (common) geometry options
page-width and page-height. As many scanners require these options to be
set before setting any geometry options if an ADF is in use, it would be
good to have these in the test backend, too.
More information about the sane-devel