Comment 53 for bug 891586

(19:33:33) Michael Nagel: -- resolution control: setting x/y resolution independently https://bugs.launchpad.net/simple-scan/+bug/891586
(19:34:36) Michael Nagel: this has two aspects: it is quite hard to get a current simple-scan on older ubuntu releases, as the dependencies are tricky
(19:34:55) robert_ancell: yes
(19:35:37) Michael Nagel: do you know if it is possible simple scan 3.4.1 on ubuntu 11.10 as discussed there?
(19:35:39) robert_ancell: that falls into the "too bad" basket to some degree
(19:36:03) robert_ancell: I don't have time to support older platforms, but others are welcome to do
(19:36:52) Michael Nagel: and the second aspect is: scanners do not always offer the same resolutions in x/y direction and sane does not abstract that away either.
(19:37:31) robert_ancell: I don't really want to support different x and y resolutions, that kind of breaks the "simple" part of simple scan
(19:38:16) robert_ancell: the case that some drivers support x-res=z and y-res=z and not res=z seems like a driver problem. We should handle falling back to setting x-res and y-res as sane doesn't require res to exist
(19:38:42) Michael Nagel: i agree. but it leaves one with very few resolutions in some cases and even no cases in theory.
(19:39:01) robert_ancell: but I wonder what type of hardware they have - is it common?
(19:39:32) Michael Nagel: i think it is a scanner with two scanning units
(19:39:37) Michael Nagel: a normal for paper
(19:40:06) robert_ancell: in the comment #45, they do have enough resolutions, but they have the driver bug I described above
(19:40:07) Michael Nagel: and one for (i dont know the proper english word) dias/transparencies
(19:40:19) robert_ancell: transparencies sounds correct
(19:40:39) Michael Nagel: like old-school photos to be projected to a wall
(19:41:12) robert_ancell: correction - comennt 41 has the bug, comment 45 is a driver with very limited options
(19:42:01) robert_ancell: so we could support that - if we decimate some of the values (i.e. scan at x=2400, y=600 and use every fourth x value)
(19:42:15) robert_ancell: it would be kind of nice if the driver did it for us
(19:42:45) robert_ancell: as long as the final image has the same res in both directions I'm ok with it
(19:43:23) Michael Nagel: --resolution seems to more "clever" (dumb in this case) than just setting x and y
(19:43:57) Michael Nagel: as it checks the other scanning modes as well and discards resolutions not supported by all modes
(19:44:12) robert_ancell: so i'd keep the bug triaged, there is a solution for drivers like this. it will take some work.
(19:44:24) robert_ancell: I'll update the bug now
(19:44:26) Michael Nagel: modes meaning "normal unit" and "transparency unit"
(19:45:09) Michael Nagel: --x-resolution seems to list the resolutions for the current mode and that might be a superset.
(19:45:51) Michael Nagel: you can intersect --x-resolution and --y-resolution manually and that set both instead of using --resolution
(19:46:04) Michael Nagel: at least thats how i understand the issue