Hi,
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
problem.
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?
SANE_Fixed
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.
Regards
Jeff
