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"
