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

[m. allan noah]

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"