m. allan noah wrote: >> > But back to the problem I have/had with Etienne's suggstion for the >> > "relations" between page size and scan window coordinates: It does >> > not make much sense to allow to set a scan window in overscan mode: >> > The backend should calculate the scan window settings automatically >> > from the page size, and disable the options tl-x, tl-y, br-x, br-y. >> >> No ! If a user want to scan only a portion of the paper, he must be able >> to set scan area, but as long as there is no scan surface, we use paper >> size as scan surface. That make sense ! > > you missed the point here. we are talking about an overscan option, which > causes the scanner to add space all around the scan, such that the back- > ground shows thru. > > but i think a person might want to overscan and still have only a > small area of the page (one of the corners?) i think i can work this > out, and still be compatible with the text of our suggestion.
Since the "level" of page size and skew detection is quite low in the scanners we're talking about, I think a backend does not need to do much here: In overscan mode, the backend simply returns the image of the document surrounded by "easily distinguishable", typically "dark" pixels; it is up to the frontend to detect the page borders and rotation angle. All this does not mean that the frontend cannot let the user select a smaller scan window within the page area -- but the clipping of the image must be done by the frontend. Abel
