On 12/17/07, Alessandro Zummo <azummo-lists at towertech.it> wrote: > On Mon, 17 Dec 2007 08:58:01 -0500 > "m. allan noah" <kitno455 at gmail.com> wrote: > > > > from what I've understood we'd need RGBI, GRAYI and RIGIBI. > > > > there are also at least three fax compression variants, as well as a > > text variant for hardware patch-code support. i've got a HUGE scanner > > in my dining room ATM that needs these. Actually, the bell and howell > > backend already supports all these, with a #ifndef. > > My dining room is free for your use :-D > > I would output something like XML for every kind of barcode/patchcode/text > output. this way the frontend will work even for new data types. > > something like > > <barcode x=".." y="..." type="..."> > <code>....</code> > </barcode> >
i am not personally prepared to prescribe the use of xml to any backend author. but i do think that makes more sense than plain text. there has also been a suggestion in the past of sending scanner EXIF-type data, which would also work well in xml, but i'm no expert on either of those. > > > If there's space, > > > i' love to have a way to ask the backend for scanner make/model. :) > > > > that is already in the SANE_Device struct? > > Yes, but it is not accessible after sane_open, if I have understood > correctly? > only when you ask the driver the list of devices. > yes- you would have to cache the results from the device list. i suppose that the exif-type data could handle that. > > > if we can make RGBI = 0x10 I will avoid to rewrite the frontend :) > > > > > > > if you include sane.h you wont have to change it later. > > sure I will, but the binary is the wild, so I was trying to avoid > some work ;) > well, if we really add: IR, RGBI, GRAYI, RIGIBI, TEXT, XML, G31D, G32D, and G42D, we are getting close to your 0x10 :) allan -- "The truth is an offense, but not a sin"
