"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/
