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"