Hi,
On 2021-06-10 7:08 a.m., [email protected] wrote:
Hi Ralph,
On 09.06.2021 21:33, Ralph Little wrote:
I have added a new test option to the test backend called int-inexact.
Thanks for your work. That is certainly a good first step, but won't
allow me to reproduce the user's problem.
Would it be possible to change the option to set SANE_INFO_* for all
following options, just as read-return-value does?
I believe that read-return-value only applies to the sane_read() call
once the scan has started, but I get what you mean.
That way it would apply to the geometry options and I could reproduce
the bug in my frontend:
I wouldn't do anything visible for scanimage, but in gscan2pdf or
simplescan, you could then:
return-info-value=SANE_INFO_INEXACT (or any other SANE_INFO_*, or
default)
Then setting br-x, br-y, tl-x, tl-y, paper-width, paper-height would
set the info value to whatever return-info-value was set to previously.
The only complication is that the SANE_INFO_* values are bitmasks, so
that multiple values can be set simultaneously.
sane-test already has some internal mechanisms I believe to manage
SANE_INFO_RELOAD_OPTIONS when the main options such as depth are modified.
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.
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?
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?
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.
----------------------
Interestingly, with the int_inexact option added to the mix, I found
that xsane does not support updating with the modified value which I
think would be reasonably expected behaviour. So the change had value
for me :D
That's something that I will put some time into at some point.
Cheers,
Ralph
