[sane-devel] [BUG] Duplicate SANE_NAME in saneopts.h

[Olaf Meeuwissen]

"m. allan noah" <kitno455 at gmail.com> writes:

> On 7/8/08, Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>> Checking out why setting X/Y resolutions independently didn't quite
>>  work as expected, I discovered that saneopts.h has this:
>>
>>   #define SANE_NAME_SCAN_RESOLUTION     "resolution"
>>   #define SANE_NAME_SCAN_X_RESOLUTION   "resolution"
>>   #define SANE_NAME_SCAN_Y_RESOLUTION   "y-resolution"
>>
>>  That means that trying to set the X resolution always does the same
>>  thing as setting the scan resolution.  I think that is incorrect in
>>  the general case and suggest the above gets changed to:
>>
>>   #define SANE_NAME_SCAN_RESOLUTION     "resolution"
>>   #define SANE_NAME_SCAN_X_RESOLUTION   "x-resolution"
>>   #define SANE_NAME_SCAN_Y_RESOLUTION   "y-resolution"
>>
>>  So that backend implementations can distinguish these cases if they
>>  want to.  The corresponding descriptions for these option hint that
>>  setting the image's scan resolution is not necessarily the same as
>>  setting the horizontal scan resolution.
>>
>>  In my particular situation, I have a use case where it makes sense to
>>  use SANE_NAME_SCAN_RESOLUTION with one set of allowed resolutions and
>>  different sets of allowed resolutions for the individual horizontal
>>  and vertical resolution settings.
>>
>>  On a more general note, there is no point in having different option
>>  name macros that resolve to the same name.  All of the SANE_NAME_*
>>  macros should be unique.  At the moment (sane-backends-1.0.19), only
>>  SANE_NAME_SCAN_X_RESOLUTION is not unique.
>>
>>  I don't think that the suggested change will break any of the current
>>  backends and frontends, but would like to ask everyone to take a look
>>  and comment on my suggestion before I file a bug report.
>
> i agree with your assessment, but i am not sure i can envision a use
> case with all three controls active at the same time. or, are you
> going to have a locked/unlocked choice that switches between the two
> sets?

Not sure I can either, at least not for a sensible use case.  But then
again, sometimes there are rather senseless use cases.

In my particular case, I can query a number of devices for supported
resolutions in two ways.  One way gives a list of resolutions.  These
would correspond to the SANE_NAME_SCAN_RESOLUTION scenario, that is,
horizontal and vertical resolutions are (and should be) identical.
The other way gives a list with resolutions for both horizontal and
vertical directions, corresponding to the SANE_NAME_SCAN_?_RESOLUTION
scenario, where both resolutions can be selected independently.  Fact
is that all three list may contain values that are on neither of the
other two lists.

So I could end up with these (hypothetical) resolution lists

  SCAN_RESOLUTION  : 100, 200, 300
  SCAN_X_RESOLUTION:  80, 150, 360
  SCAN_Y_RESOLUTION: 120, 240, 480

and the following set of valid resolution settings:

  (100,100)
  (200,200)
  (300,300)

  ( 80,120), ( 80,240), ( 80,480)
  (150,120), (150,240), (150,480)
  (360,120), (360,240), (360,480)

There is no way that I can merge the SCAN_RESOLUTION with the other
two options (or the other way) around that restricts a frontend to
these resolution sets.

# Yes, I'm aware backends may set a value other than that requested
# and I have seen the SANE_NAME_RESOLUTION_BIND option.

Whatever the sensibility of my particular use case, having two macros
expand to the same string for options that correspond to *different*
things is not a good idea.

Hope this helps,
-- 
Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962           sign up at http://member.fsf.org/