[sane-devel] test backend & SANE_INFO_INEXACT

[Ralph Little]

Hi,

On 2021-06-10 7:08 a.m., jffry at posteo.net 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