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

[m. allan noah]

Several backends use SANE_NAME_SCAN_X_RESOLUTION: abaton, artec,
canon, epjitsu, fujitsu, microtek2, sp15c, and umax. I propose to
change those backends to use SANE_NAME_SCAN_RESOLUTION, so that their
UI does not change if we separate those options.

comments?

allan

On Wed, Jul 9, 2008 at 11:57 PM, m. allan noah <kitno455 at gmail.com> wrote:
> i actually just found this comment in maxview, so other folks have
> noticed this too...
>
> //actually there seems to be no difference between
> //resolution and x-resolution; see saneopts.h
>
> allan
>
> On 7/9/08, Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>> "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/
>>
>
>
> --
> "The truth is an offense, but not a sin"
>



-- 
"The truth is an offense, but not a sin"