Henning Meier-Geinitz wrote: > Hi, > > On Sun, Sep 29, 2002 at 12:24:21PM +0200, Oliver Rauch wrote: > >>I think this is ok. I suggest to add a sentence that this transfermode >>is not used very often and the backend author should be aware >>that not all frontends may support this mode. > > > Ok, I'll add a paragraph at the end of the section: > > | In frames of type SANE_FRAME_GRAY, when the bit depth is 1 there are > | only two sample values possible, 1 represents minimum intensity > | (black) and 0 represents maximum intensity (white). For all other bit > | depth and frame type combinations, a sample value of 0 represents > | minimum intensity and larger values represent increasing intensity. > > "The combination of bit depth 1 and SANE_FRAME_RGB (or SANE_FRAME_RED, > SANE_FRAME_GREEN, SANE_FRAME_BLUE) is rarely used and may not be > supported by every frontend."
I'm afraid that this could lead to increased traffic on this list. If we have a backend for a more popular scanner which supports 1 bit RGB output, we will probably get a number of questions, what some strange error message means or why the output look scrambled. As a workaround, the frontends should at least be be able to display a message "this program does not support 1 bit RGB scans.", if a user attempts to start such a scan. For Sane 1, we can probably live with this inconsistency -- but for Sane 2, we should either omit the 1 bit RGB mode completely (which I would not like that much...), or all frontends should support all "basic" data formats. Alternatively, we would need something like "content type negotiation protocol" which would allow a backend to enable only those options, which lead to scan modes supported by the frontend. Abel
