[sane-devel] Well known option consensus
On 1/22/07, abel deuring wrote: > m. allan noah wrote: > > >> 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. > >> > > > > i agree completely other than the last sentence. it should be possible > > for the backend > > to let the user select overscan mode, and then adjust the scan > > area/papersize as needed > > to set tl-x/y 0,0 to the black area 16mm outside of the paper. i dont > > think this violates the > > spirit of the standard proposal, and it keeps overscan mode as similar > > to the other modes > > as possible. in fact, i think this is the right thing to do in sane1, > > given recent user complaints on this mailing list. > > OK, misunderstanding cleared ;) > > Perhaps we're beginning to discuss a far too special feature -- but > I would maintain nevertheless that it makes sense for a backend to > simply disable tl-x, br-x, tl-y, br-y in overscan mode, we agree to disagree :) > and that to > set the scan area automatically to a value that is somewhat larger > than the page size. i agree to set the max area to be larger than page size, yes. > After all, this would allow the backend to fix > the weird behaviour of the fi4210/5120 that the parameter page width > must be set to a "wrong" value: real page width + 32mm in overscan > mode, if one wants the dark background on the left side of the scan > area. i can fix that even without forcing the user to do full-page scans. i just tack the 32mm on when i build the command block if you are in overscan mode. i need more docs and beta testers to see if this page-width change is needed with more expensive scanners. this discusion has become too specialized, but it does point out the concept that we were trying to capture in our 'pagesize' well-known option suggestion: the backend should endeavor to limit the scan area of an adf to values which are sensible for the options being used, including, but not limited to, paper size. allan -- "The truth is an offense, but not a sin"
[sane-devel] Well known option consensus
m. allan noah wrote: >> 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. >> > > i agree completely other than the last sentence. it should be possible > for the backend > to let the user select overscan mode, and then adjust the scan > area/papersize as needed > to set tl-x/y 0,0 to the black area 16mm outside of the paper. i dont > think this violates the > spirit of the standard proposal, and it keeps overscan mode as similar > to the other modes > as possible. in fact, i think this is the right thing to do in sane1, > given recent user complaints on this mailing list. OK, misunderstanding cleared ;) Perhaps we're beginning to discuss a far too special feature -- but I would maintain nevertheless that it makes sense for a backend to simply disable tl-x, br-x, tl-y, br-y in overscan mode, and that to set the scan area automatically to a value that is somewhat larger than the page size. After all, this would allow the backend to fix the weird behaviour of the fi4210/5120 that the parameter page width must be set to a "wrong" value: real page width + 32mm in overscan mode, if one wants the dark background on the left side of the scan area. Abel
[sane-devel] Well known option consensus
On 1/22/07, abel deuring wrote: > 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. > i agree completely other than the last sentence. it should be possible for the backend to let the user select overscan mode, and then adjust the scan area/papersize as needed to set tl-x/y 0,0 to the black area 16mm outside of the paper. i dont think this violates the spirit of the standard proposal, and it keeps overscan mode as similar to the other modes as possible. in fact, i think this is the right thing to do in sane1, given recent user complaints on this mailing list. allan -- "The truth is an offense, but not a sin"
[sane-devel] Well known option consensus
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
[sane-devel] Well known option consensus
Hi, > 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 ! ?tienne. -- Verso l'Alto ! -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070122/14116d8f/attachment.pgp From kitno...@gmail.com Mon Jan 22 14:43:25 2007 From: kitno...@gmail.com (m. allan noah) Date: Mon Jan 22 14:50:42 2007 Subject: [sane-devel] Well known option consensus In-Reply-To: <1169466263.5734.1.camel@thilivren> References: <1169400182.5609.23.camel@thilivren> <45b4083a.7070...@gmx.net> <97246d0e0701211646s24e11ee5o7f0e2e397b45e...@mail.gmail.com> <45b41a2c.9000...@gmx.net> <1169466263.5734.1.camel@thilivren> Message-ID: <97246d0e0701220543t16978099jed1efc3934e0b...@mail.gmail.com> On 1/22/07, ?tienne Bersac wrote: > Hi, > > > 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. allan -- "The truth is an offense, but not a sin"
[sane-devel] Well known option consensus
Allan, >> It might be better if the backend tells the frontend, if scan window >> coordinates are relative to the entire scan area or to the selected >> page size. >> > > abel- i tried this a few weeks ago with my 4120C2, and found that i also > had to > increase the paper size (lie to the scanner) to get it not to throw an > error. > > can you check in your personal modification that you actually can set > the br-x wider than paper-width? even if this is so, i bet you cannot > set it very much higher. i think i can deal with this in backend- when > overscan is set, i am going to add 16mm to your scan area dimensions > anyway... Yes and no... The following settings (for an A5 page, 148.5 mm x 210 mm) [fujitsu] xres=300, tlx=0, brx=8512, pw=6993, maxx=10624 [fujitsu] yres=300, tly=0, bry=11435, ph=9923, maxy=40800 I get the "background pixels" at the top, at the right and at the bottom of the image, but not on the left. So I can set the image width larger than the page width, but in order to get "background pixels" on the left side, the page width value must be increased. 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. (Actually, Eikazo does that -- but I think this should be done by the backend...) Abel
[sane-devel] Well known option consensus
On 1/21/07, abel deuring wrote:
> ?tienne Bersac wrote:
>
> > \section{Papersize}
> >
> > When using an Automatic Document Feeder, the user generally cannot
> > preview. If the page being scanned is smaller than the maximum size
> > supported by the hardware/backend, the frontend cannot determine
> > the location of the document on the scan surface, and cannot limit
> > the values of the scan area (tl-x/y and br-x/y) to match.
> >
> > If the backend implements options for the frontend user to set the
> > paper size, the backend should limit the range of the scan area to
> > that defined by the paper. The scan area is then relative to paper
> > origin, not scan surface origin.
> >
> > \begin{options}
> > \option{paper-width}{\FIXED}{\MM}{Paper width.}
> > \option{paper-height}{\FIXED}{\MM}{Paper height.}
> > \end{options}
>
>
> Now things become really tricky ;) Some Fujitsu ADF scanners (and
> probably also devices from other manufacturers) have a so-called
> "overscan mode". In overscan mode, the scan window is larger than
> the page size; for pixels outside tha page area, you get a
> background colour (you can even select between white and black
> background). This allows to detect and correct skewed scans and to
> check the page size by "analyzing" the image.
>
> So, stating that the scan window should not be larger than the page
> size is not such a good idea...
>
> It might be better if the backend tells the frontend, if scan window
> coordinates are relative to the entire scan area or to the selected
> page size.
>
abel- i tried this a few weeks ago with my 4120C2, and found that i also had to
increase the paper size (lie to the scanner) to get it not to throw an error.
can you check in your personal modification that you actually can set
the br-x wider than paper-width? even if this is so, i bet you cannot
set it very much higher. i think i can deal with this in backend- when
overscan is set, i am going to add 16mm to your scan area dimensions
anyway...
allan
> Abel
>
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> to sane-devel-requ...@lists.alioth.debian.org
>
--
"The truth is an offense, but not a sin"
[sane-devel] Well known option consensus
?tienne Bersac wrote:
> \section{Papersize}
>
> When using an Automatic Document Feeder, the user generally cannot
> preview. If the page being scanned is smaller than the maximum size
> supported by the hardware/backend, the frontend cannot determine
> the location of the document on the scan surface, and cannot limit
> the values of the scan area (tl-x/y and br-x/y) to match.
>
> If the backend implements options for the frontend user to set the
> paper size, the backend should limit the range of the scan area to
> that defined by the paper. The scan area is then relative to paper
> origin, not scan surface origin.
>
> \begin{options}
> \option{paper-width}{\FIXED}{\MM}{Paper width.}
> \option{paper-height}{\FIXED}{\MM}{Paper height.}
> \end{options}
Now things become really tricky ;) Some Fujitsu ADF scanners (and
probably also devices from other manufacturers) have a so-called
"overscan mode". In overscan mode, the scan window is larger than
the page size; for pixels outside tha page area, you get a
background colour (you can even select between white and black
background). This allows to detect and correct skewed scans and to
check the page size by "analyzing" the image.
So, stating that the scan window should not be larger than the page
size is not such a good idea...
It might be better if the backend tells the frontend, if scan window
coordinates are relative to the entire scan area or to the selected
page size.
Abel
[sane-devel] Well known option consensus
Skipped content of type multipart/mixed-- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070121/d1eb3c70/attachment.pgp From bersac...@laposte.net Sun Jan 21 18:56:43 2007 From: bersac...@laposte.net (=?ISO-8859-1?Q?=C9tienne?= Bersac) Date: Sun Jan 21 18:56:51 2007 Subject: [sane-devel] Using host operating system hardware detection Message-ID: <1169402203.5609.57.camel@thilivren> Hi, Following HAL sane support, i talk a bit at freedesktop about a scanner infrastructure (mostly on top of SANE), for handling buttons event, and so on. One more time, i heard this idea i join : SANE should use host operating system hardware detection and handling. As stated above, sanei should be able to handle either HAL UDI and similar standard in Unix, Windows, Mac OS X, ? The better solution would be to receive UDI and only UDI, not backends. So that a frontend can use HAL to query scanner list, and directly sane_open the result. The same on Windows, Mac OS X, Unix, ? At build time, it's simple to choose which "source" can be understand by sanei. Please comment. ?tienne. -- Verso l'Alto ! -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070121/07c9bee1/attachment.pgp From e...@erikwickstrom.com Sun Jan 21 17:47:12 2007 From: e...@erikwickstrom.com (Erik Wickstrom) Date: Sun Jan 21 19:41:28 2007 Subject: [sane-devel] scanimage: sane_read: Error during device I/O Message-ID: <3d381e170701210847k61b0debftcace5fe66af1...@mail.gmail.com> Hi all, I've been trying to get my scanner working, but no luck so far. Whenever I try to scan in sane/xsane I get this "error during device i/o" message. I'm running Ubuntu Edgy (6.10) and my scanner is an HP LaserJet 3330 MFP. scanimage prints a bunch of binary data to standard output while the scanner is scanning. Then it prints this message. Ubuntu/xsane auto-detect my scanner. I've also tried installing HPLIB. I have no idea what to try next. Thanks for your help! Erik -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070121/c306c02f/attachment.html From j...@gmx.de Sun Jan 21 20:39:54 2007 From: j...@gmx.de (Jan Kandziora) Date: Sun Jan 21 20:47:15 2007 Subject: [sane-devel] Pages all white with Cybercom 9352 (mustek_pp) backend Message-ID: <200701212039.54719@gmx.de> Dear All, I have problems with this old parport scanner. It works fine with MS-Windows 98, but SANE's scanimage (xsane, too) only give back all white images. Playing a little with the resolution option (others do not apply to this scanner), I got all the same result. It just scans the whole page, but the image is plain white... I found an older posting http://lists.alioth.debian.org/pipermail/sane-devel/2004-February/010102.html which reports the same problem but, to my pity, no respones. Any ideas/pointers? (YES, I indeed put some colored paper on the scanner...) Kind regards Jan -- Ber?chtigte Euphemismen: "Industriestandard"
