[sane-devel] SANE 1.1.0 Release discussion

On Wednesday 09 July 2008, m. allan noah wrote: > > Is anybody updating the test backend with the new features? I needed to > > add a gamma table stub to the test backend to be able to implement > > gammatable support in libksane. > > i dont recall seeing a patch from you for the gamma table suppor

[sane-devel] SANE 1.1.0 Release discussion

Le Tuesday 08 July 2008 21:42:09 K?re S?rs, vous avez ?crit?: > Hi, > > On Mondayen den 7 July 2008 23:51:24 m. allan noah wrote: > > ok guys- take 4: > > > > Six general points for sane 1.1.x: > > - no changes to function calls > > - no changes to structures > > - 1.0 backends forward compatibl

[sane-devel] SANE 1.1.0 Release discussion

Hi, On Mondayen den 7 July 2008 23:51:24 m. allan noah wrote: > ok guys- take 4: > > Six general points for sane 1.1.x: > - no changes to function calls > - no changes to structures > - 1.0 backends forward compatible with 1.1 > - improve backend consistency > - support more advanced scanners

[sane-devel] SANE 1.1.0 Release discussion

On 7/8/08, K?re S?rs wrote: > Hi, > > > On Mondayen den 7 July 2008 23:51:24 m. allan noah wrote: > > ok guys- take 4: > > > > Six general points for sane 1.1.x: > > - no changes to function calls > > - no changes to structures > > - 1.0 backends forward compatible with 1.1 > > - impro

[sane-devel] SANE 1.1.0 Release discussion

ok guys- take 4: Six general points for sane 1.1.x: - no changes to function calls - no changes to structures - 1.0 backends forward compatible with 1.1 - improve backend consistency - support more advanced scanners - improve cooperation with modern system services Specific proposals: 1. C

[sane-devel] SANE 1.1.0 Release discussion

Hi, ps: this time to the list as well :-) m. allan noah wrote: > On 5/26/08, Ren? Rebe wrote: >> Hi Allan, >> >> can you explain the paper width option to me? Why can we >> not simply use br x/y? >> >> Actually I got a Fujitsu scanner here and find the duplicate >> paper width option annoyin

[sane-devel] SANE 1.1.0 Release discussion

Hi, > but what is the frontend going to do with that, read the user's > setting, then turn the data back around and set the resolution and > duplex options? it seems that would be better done in the backend > itself.? But the frontend should be aware that the device has changed some value, at lea

[sane-devel] SANE 1.1.0 Release discussion

Hi Allan, can you explain the paper width option to me? Why can we not simply use br x/y? Actually I got a Fujitsu scanner here and find the duplicate paper width option annoying at best. Aside the already mentioned button to use some more extend-able XML encoding instead of a hardcoded set, I w

[sane-devel] SANE 1.1.0 Release discussion

Hi, some scanners even have simplex / duplex buttons or even fine grained to up/down arrows to setup resolution, color mode etc. (i.g. the popular HP 7400). In the Avision backend I know use a string option to spit out a message the program can parse. Going with the current trend, maybe a xml st

[sane-devel] SANE 1.1.0 Release discussion

Hi, > or perhaps scan2 or altscan? No ! you need to keep to semantic ! altscan or scan is not selfexplanatory. Please prefer "film" or "scan-film". We should also state whether we should use "_" or "-" in option name. I guess that the standard is lowercase + hyphen + digit. ?tienne.

[sane-devel] SANE 1.1.0 Release discussion

On 5/26/08, Ren? Rebe wrote: > Hi, > > ps: this time to the list as well :-) > > m. allan noah wrote: > > > On 5/26/08, Ren? Rebe wrote: > > > > > Hi Allan, > > > > > > can you explain the paper width option to me? Why can we > > > not simply use br x/y? > > > > > > Actually I got a Fujitsu

[sane-devel] SANE 1.1.0 Release discussion

On 5/26/08, ?tienne Bersac wrote: > Hi, > > > > but what is the frontend going to do with that, read the user's > > setting, then turn the data back around and set the resolution and > > duplex options? it seems that would be better done in the backend > > > itself.? > > But the frontend shoul

[sane-devel] SANE 1.1.0 Release discussion

sorry rene- this should have gone to list... On 5/26/08, m. allan noah wrote: > On 5/26/08, Ren? Rebe wrote: > > > Hi Allan, > > > > can you explain the paper width option to me? Why can we > > not simply use br x/y? > > > > Actually I got a Fujitsu scanner here and find the duplicate >

[sane-devel] SANE 1.1.0 Release discussion

On 5/26/08, Ren? Rebe wrote: > Hi, > > some scanners even have simplex / duplex buttons or even fine grained > to up/down arrows to setup resolution, color mode etc. (i.g. the > popular HP 7400). right- but what is the frontend going to do with that, read the user's setting, then turn the data

[sane-devel] SANE 1.1.0 Release discussion

On 5/26/08, ?tienne Bersac wrote: > Hi, > > > > or perhaps scan2 or altscan? > > > No ! you need to keep to semantic ! altscan or scan is not > selfexplanatory. Please prefer "film" or "scan-film". i doubt any frontend is going to code distinct support for such a unique button, but we can craft

[sane-devel] SANE 1.1.0 Release discussion

El Wednesday 21 May 2008 20:50:46 m. allan noah escribi?: > 5. Several new well-known options for buttons and sensors. Backends > should use the closest one to the meaning of the label on the scanner > or the button's use in the manufacturer's software. Backends may also > use a different name if

[sane-devel] SANE 1.1.0 Release discussion

or perhaps scan2 or altscan? allan On 5/25/08, JKD wrote: > El Wednesday 21 May 2008 20:50:46 m. allan noah escribi?: > > > > 5. Several new well-known options for buttons and sensors. Backends > > should use the closest one to the meaning of the label on the scanner > > or the button's use i

[sane-devel] SANE 1.1.0 Release discussion

Hi, >From my point of view, everything is fine. Regards, ?tienne.

[sane-devel] SANE 1.1.0 Release discussion

ok guys- take 3: Six general points for sane 1.1.x: - no changes to function calls - no changes to structures - 1.0 backends forward compatible with 1.1 - improve backend consistency - support more advanced scanners - improve cooperation with modern system services Specific proposals: 1. C

[sane-devel] SANE 1.1.0 Release discussion

Hi, > Maybe "fax" and "copy" too? "fax" is good, but "copy" may be redundant with print, isn't it ? > The Canon LiDE 60 I have to hand has "copy", "scan", "pdf", "e-mail" > buttons on the front We should add "pdf" as well. "e-mail" should be renamed to "mailto" (or vice versa). Regards, ?tie

[sane-devel] SANE 1.1.0 Release discussion

Hi, > Then i will await your list of preferred button names :) I suggest : * "auto" for blank/context dependant button. * "scan" for start button * "cancel" * "paper-in" but what for multiple source device ? (maybe autoselecting source is enough ?) *

[sane-devel] SANE 1.1.0 Release discussion

Hi, Agree, HW_BUTTON is redundant with HARD_SELECT. Sorry for not notifying it earlier. ?tienne.

[sane-devel] SANE 1.1.0 Release discussion

On 16 May 2008, at 20:50, ?tienne Bersac wrote: > * "auto" for blank/context dependant button. > * "scan" for start button > * "cancel" > * "paper-in" but what for multiple source device ? (maybe >autoselecting source is enough ?) > * "mailto" > * "print"

[sane-devel] SANE 1.1.0 Release discussion

Hi, > 5. One new SANE_TYPE value: HW_BUTTON (do we also need consistent names?) Yes, well-known naming would be very nice. Fujitsu backend is fairly good for that. This will allow frontend to predetermine action for sensor (paper-in, cancel, etc.). The less you ask user to describe their hardwar

[sane-devel] SANE 1.1.0 Release discussion

On Fri, May 16, 2008 at 2:13 PM, m. allan noah wrote: > On Fri, May 16, 2008 at 12:21 PM, m. allan noah wrote: > >> 5. One new SANE_TYPE value: HW_BUTTON > > actually, as i am trying to implement this- i notice that the > constraint is not really enough info to distinguish between types, as > the

[sane-devel] SANE 1.1.0 Release discussion

On Fri, May 16, 2008 at 12:21 PM, m. allan noah wrote: > 5. One new SANE_TYPE value: HW_BUTTON actually, as i am trying to implement this- i notice that the constraint is not really enough info to distinguish between types, as the RANGE and WORD_LIST are applicable to INT and FIXED types. we rea

[sane-devel] SANE 1.1.0 Release discussion

Then i will await your list of preferred button names :) allan On Fri, May 16, 2008 at 12:56 PM, ?tienne Bersac wrote: > > Hi, > >> 5. One new SANE_TYPE value: HW_BUTTON (do we also need consistent names?) > > Yes, well-known naming would be very nice. Fujitsu backend is fairly > good for that.

[sane-devel] SANE 1.1.0 Release discussion

I have consolidated previous discussions: Six general points for sane 1.1.x: - no changes to function calls - no changes to structures - 1.0 backends forward compatible with 1.1 - improve backend consistency - support more advanced scanners - improve cooperation with modern system services

[sane-devel] SANE 1.1.0 Release discussion

> > proprietary unices can't use gcc or another C99 compiler? > > Which unix in particular? > > Pretty much all of them ship compilers that do not implement C99 or > do > not implement all of it yet. Moreover, we're speaking of systems that > often do not get updated for a variety of reasons, s

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo writes: > On Thu, 08 May 2008 09:29:09 +0900 > Olaf Meeuwissen wrote: > >> > don't know yet. I still have to check epkowa code then Olaf and I could >> > maybe discuss the thing in order to have similar behaviours. >> >> The information is returned as part of the status (see

[sane-devel] SANE 1.1.0 Release discussion

On Thu, 08 May 2008 22:33:01 +0200 Julien BLACHE wrote: > Alessandro Zummo wrote: > > > portability makes a lot of sense. constraining ourselves to things > > that are decades older does not. > > There's no reason to leave users out in the cold when it doesn't cost > us anything to support t

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo wrote: > portability makes a lot of sense. constraining ourselves to things > that are decades older does not. There's no reason to leave users out in the cold when it doesn't cost us anything to support them. We only have to not break the existing code. JB. -- Julien BLACH

[sane-devel] SANE 1.1.0 Release discussion

On Thu, 08 May 2008 22:07:40 +0200 Julien BLACHE wrote: > > proprietary unices can't use gcc or another C99 compiler? > > Which unix in particular? > > Pretty much all of them ship compilers that do not implement C99 or do > not implement all of it yet. Moreover, we're speaking of systems that

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo wrote: > proprietary unices can't use gcc or another C99 compiler? > Which unix in particular? Pretty much all of them ship compilers that do not implement C99 or do not implement all of it yet. Moreover, we're speaking of systems that often do not get updated for a variety of

[sane-devel] SANE 1.1.0 Release discussion

On Thu, 08 May 2008 19:13:39 +0200 Julien BLACHE wrote: > Alessandro Zummo wrote: > > > if there are standard and equivalent types, we should use them. > > iirc some of them were added with C99. Given we are now > > in 2008 we might start supporting C99 :-D > > Will break proprietary Unices

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo wrote: > if there are standard and equivalent types, we should use them. > iirc some of them were added with C99. Given we are now > in 2008 we might start supporting C99 :-D Will break proprietary Unices. JB. -- Julien BLACHE

[sane-devel] SANE 1.1.0 Release discussion

On Thu, 08 May 2008 14:19:38 +0200 CEST "Fran?ois Revol" wrote: > > On 5/6/08, > > IIRC some non-standard (linux specific) types were used (u_int8_t ?) in > place of standard ones, without even including the correct headers, so > I had to fix many backends. > That might not only affect BeOS bt

[sane-devel] SANE 1.1.0 Release discussion

On Thu, 8 May 2008 08:24:37 -0400 "m. allan noah" wrote: > > > > > > :) libusb is probably used in 90% of the user base.. shouldn't be a > > problem, > > unless someone is really using a 2.4 kernel with /dev/scanner > > typical linux developer response :) sane builds on alot of other > syste

[sane-devel] SANE 1.1.0 Release discussion

> > > > > > :) libusb is probably used in 90% of the user base.. > > shouldn't be a problem, > > unless someone is really using a 2.4 kernel with /dev/scanner > > typical linux developer response :) sane builds on alot of other > systems- e.g. the OSX libusb names are really long GUID-looking

[sane-devel] SANE 1.1.0 Release discussion

> On 5/6/08, ?tienne Bersac wrote: > > Hi, > > > > Thanks alan fo this post. I agree with everything on you list. > > Just add > > something : would it be possible to just "ensure" that all usb > > scanner > > backends support libusb:xxx:yyy as "fallback" device name ? > > i think we can do

[sane-devel] SANE 1.1.0 Release discussion

On Thu, 08 May 2008 13:56:45 +0200 Julien BLACHE wrote: > "m. allan noah" wrote: > > Hi, > > > still not sure how to document that requirement for the front-end > > author, because those device names will vary quite a bit between > > platforms... > > "Use the device name returned by the backe

[sane-devel] SANE 1.1.0 Release discussion

"m. allan noah" wrote: Hi, > still not sure how to document that requirement for the front-end > author, because those device names will vary quite a bit between > platforms... "Use the device name returned by the backend unless you know damn well what you are doing". There, done. ;) JB. --

[sane-devel] SANE 1.1.0 Release discussion

On Thu, 08 May 2008 09:29:09 +0900 Olaf Meeuwissen wrote: > > don't know yet. I still have to check epkowa code then Olaf and I could > > maybe discuss the thing in order to have similar behaviours. > > The information is returned as part of the status (see ESC f, FS F). > I was thinking along

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo writes: > On Wed, 07 May 2008 11:58:52 +0200 > ?tienne Bersac wrote: > >> Hi, >> >> So you mean an hardware selected option that can be read after the >> scan ? Sounds good ! > > don't know yet. I still have to check epkowa code then Olaf and I could > maybe discuss the thing

[sane-devel] SANE 1.1.0 Release discussion

On 5/8/08, Alessandro Zummo wrote: > On Thu, 08 May 2008 13:56:45 +0200 > > Julien BLACHE wrote: > > > > "m. allan noah" wrote: > > > > Hi, > > > > > still not sure how to document that requirement for the front-end > > > author, because those device names will vary quite a bit between > >

[sane-devel] SANE 1.1.0 Release discussion

On 5/6/08, ?tienne Bersac wrote: > Hi, > > Thanks alan fo this post. I agree with everything on you list. Just add > something : would it be possible to just "ensure" that all usb scanner > backends support libusb:xxx:yyy as "fallback" device name ? i think we can do that, but write it in a mo

[sane-devel] SANE 1.1.0 Release discussion

On 5/7/08, ?tienne Bersac wrote: > Hi, > > > > it is something > > that should be considered when the need arises, in order to not > > have the same situation we had with the options that we are now > > going to standardize. > > > +1000 :) > > Please provide a "well-known" DTD :) this is

[sane-devel] SANE 1.1.0 Release discussion

Olaf Meeuwissen wrote: Hi, >> there are some patches that Julien included in its debian >> package that might be useful. I especially like the one >> that searches for config files in /etc/sane.d/dll.d > > +1 Due to popular demand, I've now committed that patch in the CVS. :) JB. -- Juli

[sane-devel] SANE 1.1.0 Release discussion

Johannes Meixner wrote: Hi, > Therefore I prefer bitmasks provided that the debug output has > appropriate identifiers for each kind of message so that one can > easily "grep" for certain kind of messages in a debug log file. Same analysis, seconded. JB. -- Julien BLACHE

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo writes: > On Wed, 07 May 2008 10:15:36 +0900 > Olaf Meeuwissen wrote: > >> >> Some of the EPSON models support hardware paper size detection. You'd >> want at least an option to toggle whether or not you want to use it. > > is that supported in epson/epkowa?

[sane-devel] SANE 1.1.0 Release discussion

On Wed, 07 May 2008 11:58:52 +0200 ?tienne Bersac wrote: > Hi, > > So you mean an hardware selected option that can be read after the > scan ? Sounds good ! don't know yet. I still have to check epkowa code then Olaf and I could maybe discuss the thing in order to have similar behaviours. -

[sane-devel] SANE 1.1.0 Release discussion

Hi, So you mean an hardware selected option that can be read after the scan ? Sounds good ! Regards, ?tienne.

[sane-devel] SANE 1.1.0 Release discussion

On Wed, 07 May 2008 11:48:18 +0200 ?tienne Bersac wrote: > Hi, > > Please avoid using paper name and rather keep using paper lengths and > let frontend use papernames on top of that. This allow frontend to use > custom paper sizes (without specifying top left corner coordinate) or i > will end u

[sane-devel] SANE 1.1.0 Release discussion

Hi, Please avoid using paper name and rather keep using paper lengths and let frontend use papernames on top of that. This allow frontend to use custom paper sizes (without specifying top left corner coordinate) or i will end up with three way of specifying ROI : coordinates, paper lengths and pap

[sane-devel] SANE 1.1.0 Release discussion

Hi, > it is something > that should be considered when the need arises, in order to not > have the same situation we had with the options that we are now > going to standardize. +1000 :) Please provide a "well-known" DTD :) ?tienne.

[sane-devel] SANE 1.1.0 Release discussion

On Wed, 07 May 2008 17:51:26 +0900 Olaf Meeuwissen wrote: > > > > is that supported in epson/epkowa? > > From memory, epkowa "detects" the information but does not explicitly > use it (yet). The epson backend probably doesn't detect it unless > Karl merged my changes to epkowa. will give it

[sane-devel] SANE 1.1.0 Release discussion

"m. allan noah" writes: > 6. Common debugging bitmask: > > 1 major errors > 2 minor errors > 4 function start/stop msgs > 8 function detail msg > 16 SANE_OPTION processing msgs > 32 calibration msgs > 64 outgoing command dump > 128 incoming data dump > > help me fix that... Please allow for sepa

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo writes: > On Mon, 5 May 2008 13:56:58 -0400 > "m. allan noah" wrote: > >> >> Other things from stef's list have been left out because the dont meet >> my 5 points, anyone else have some more? > > there are some patches that Julien included in its debian > package that might b

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo writes: > On Mon, 5 May 2008 13:56:58 -0400 > "m. allan noah" wrote: > >> 2. Consistent well known-options, button handling and papersize come >> to mind. others? > > when I wrote epson2 i removed the paper size support that was in epson. > I believe the paper size is somethi

[sane-devel] SANE 1.1.0 Release discussion

Hello, On May 6 08:08 Frank Zago wrote: > > > 6. Common debugging bitmask: > > > > 1 major errors > > 2 minor errors > > 4 function start/stop msgs > > 8 function detail msg > > 16 SANE_OPTION processing msgs > > 32 calibration msgs > > 64 outgoing command dump > > 128 incoming data dump > > > >

[sane-devel] SANE 1.1.0 Release discussion

On Wed, 07 May 2008 10:15:36 +0900 Olaf Meeuwissen wrote: > > Some of the EPSON models support hardware paper size detection. You'd > want at least an option to toggle whether or not you want to use it. is that supported in epson/epkowa? > As for "standard" paper sizes, there are many and

[sane-devel] SANE 1.1.0 Release discussion

On Tue, 6 May 2008 16:25:02 -0400 "m. allan noah" wrote: > We don't understand the problem space enough to write a proper schema. > If SANE_FRAME_XML goes in, it has to be flexible enough for new > backend authors to actually use it via their own schema, which can be > embedded in the stream. a

[sane-devel] SANE 1.1.0 Release discussion

"m. allan noah" wrote: Hi, > How about we just state that the schema is backend dependent? Could depend on the model, too ;) As I see it, the XML frame type will be transformed by the frontend by applying an XSLT stylesheet before using the data. That means adding support for a DTD to the fro

[sane-devel] SANE 1.1.0 Release discussion

On Tue, 6 May 2008 16:10:37 -0400 "m. allan noah" wrote: > How about we just state that the schema is backend dependent? pretty difficult if you want to parse the results.. it makes sense to have some common output. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo wrote: > that was the only part with a spec, the whole dtd/document/page model > yet has to be defined. Propose a standard DTD if you wish, but do not restrict the frame type to this DTD. That was my message :) JB. -- Julien BLACHE

[sane-devel] SANE 1.1.0 Release discussion

"m. allan noah" wrote: Hi, > so what do the files look like, just a single line listing the backend name? Yep, just like dll.conf. JB. -- Julien BLACHE GPG KeyID 0xF5D65169

[sane-devel] SANE 1.1.0 Release discussion

On Tue, 06 May 2008 18:56:19 +0200 Julien BLACHE wrote: > >> I dont know. that is why i originally left it out of 1.1.0, until some > >> upstart came along and forced my hand :) seriously, i think we should > >> leave it undefined for now, and wait until we have some examples. > > > > this is wh

[sane-devel] SANE 1.1.0 Release discussion

"m. allan noah" wrote: Hi, > we can stick with levels, if we make them more consistent. I > personally am a fan of bitmasks, because of the flexibility, but you > are correct that most users will have trouble doing the bitwise AND :) I vote for bitmasks too: - debug stuff is for developers -

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo wrote: Hi, >> > shall xml be a free type or shall we define its tags? >> >> I dont know. that is why i originally left it out of 1.1.0, until some >> upstart came along and forced my hand :) seriously, i think we should >> leave it undefined for now, and wait until we have so

[sane-devel] SANE 1.1.0 Release discussion

"m. allan noah" wrote: Hi, >> > there are some patches that Julien included in its debian >> > package that might be useful. I especially like the one >> > that searches for config files in /etc/sane.d/dll.d >> >> That's the only one that can be integrated into SANE upstream, >> actually

[sane-devel] SANE 1.1.0 Release discussion

We don't understand the problem space enough to write a proper schema. If SANE_FRAME_XML goes in, it has to be flexible enough for new backend authors to actually use it via their own schema, which can be embedded in the stream. allan On Tue, May 6, 2008 at 4:13 PM, Alessandro Zummo wrote: > On

[sane-devel] SANE 1.1.0 Release discussion

How about we just state that the schema is backend dependent? allan > On Tue, May 6, 2008 at 1:24 PM, Julien BLACHE wrote: > > Alessandro Zummo wrote: > > > > > > > that was the only part with a spec, the whole dtd/document/page model > > > yet has to be defined. > > > > Propose a

[sane-devel] SANE 1.1.0 Release discussion

This is a much better solution than coming with a completely new SANE2 API. At the Linux Foundation Summit in April we have decided on taking the SANE1 API into LSB 4.0, so that scanner manufacturers can make distribution-independent LSB-based scanner driver packages. Standardizing on the drive

[sane-devel] SANE 1.1.0 Release discussion

we can stick with levels, if we make them more consistent. I personally am a fan of bitmasks, because of the flexibility, but you are correct that most users will have trouble doing the bitwise AND :) allan On Tue, May 6, 2008 at 9:08 AM, Frank Zago wrote: > > > 6. Common debugging bitmask: >

[sane-devel] SANE 1.1.0 Release discussion

Hi, Thanks alan fo this post. I agree with everything on you list. Just add something : would it be possible to just "ensure" that all usb scanner backends support libusb:xxx:yyy as "fallback" device name ? Regards, ?tienne.

[sane-devel] SANE 1.1.0 Release discussion

Hi, > I include it based on long discussion i had with E. Bersac about adf > machines and how to properly align the x/y coordinates when using > paper that is narrower than the maximum. Yes, but this mean that paper-size is paper with and height, unlike epson "quick-format" (A4, CD cover, etc.) w

[sane-devel] SANE 1.1.0 Release discussion

> 6. Common debugging bitmask: > > 1 major errors > 2 minor errors > 4 function start/stop msgs > 8 function detail msg > 16 SANE_OPTION processing msgs > 32 calibration msgs > 64 outgoing command dump > 128 incoming data dump > > help me fix that... > Should these need to be bitmasks ? I think

[sane-devel] SANE 1.1.0 Release discussion

> 6. Common debugging bitmask: > > 1 major errors > 2 minor errors > 4 function start/stop msgs > 8 function detail msg > 16 SANE_OPTION processing msgs > 32 calibration msgs > 64 outgoing command dump > 128 incoming data dump > > help me fix that... > Should these need to be bitmasks ? I think

[sane-devel] SANE 1.1.0 Release discussion

On Mon, 5 May 2008 16:30:18 -0400 "m. allan noah" wrote: > > > 4. More SANE_FRAME types, jpeg, fax, IR, text, xml. > > > > shall xml be a free type or shall we define its tags? > > > > I dont know. that is why i originally left it out of 1.1.0, until some > upstart came along and forced my

[sane-devel] SANE 1.1.0 Release discussion

On Mon, 5 May 2008 13:56:58 -0400 "m. allan noah" wrote: > 2. Consistent well known-options, button handling and papersize come > to mind. others? when I wrote epson2 i removed the paper size support that was in epson. I believe the paper size is something better suited for a frontend. opin

[sane-devel] SANE 1.1.0 Release discussion

Alessandro Zummo wrote: Hi, > there are some patches that Julien included in its debian > package that might be useful. I especially like the one > that searches for config files in /etc/sane.d/dll.d That's the only one that can be integrated into SANE upstream, actually. All the other patch

[sane-devel] SANE 1.1.0 Release discussion

On Mon, 5 May 2008 13:56:58 -0400 "m. allan noah" wrote: > > Other things from stef's list have been left out because the dont meet > my 5 points, anyone else have some more? there are some patches that Julien included in its debian package that might be useful. I especially like the one tha

[sane-devel] SANE 1.1.0 Release discussion

Hello, I think this is a reasonable plan, and I feel like working on it. Regards, Stef

[sane-devel] SANE 1.1.0 Release discussion

On Mon, 5 May 2008 14:38:34 -0400 "m. allan noah" wrote: > On Mon, May 5, 2008 at 2:06 PM, Alessandro Zummo > wrote: > > On Mon, 5 May 2008 13:56:58 -0400 > > "m. allan noah" wrote: > > > > > 3. Two new return codes: SANE_STATUS_HW_LOCK to tell the frontend that > > the > > > scanner has a

[sane-devel] SANE 1.1.0 Release discussion

On Mon, 5 May 2008 13:56:58 -0400 "m. allan noah" wrote: > 3. Two new return codes: SANE_STATUS_HW_LOCK to tell the frontend that the > scanner has a hardware lock installed, and SANE_STATUS_WARMING_UP for lamp. it would be fine if we can keep those in sync with sane evolution. > 4. More SANE

[sane-devel] SANE 1.1.0 Release discussion

On Mon, May 5, 2008 at 3:51 PM, Julien BLACHE wrote: > Alessandro Zummo wrote: > > Hi, > > > > there are some patches that Julien included in its debian > > package that might be useful. I especially like the one > > that searches for config files in /etc/sane.d/dll.d > > That's the only

[sane-devel] SANE 1.1.0 Release discussion

On Mon, May 5, 2008 at 3:54 PM, Alessandro Zummo wrote: > On Mon, 5 May 2008 13:56:58 -0400 > "m. allan noah" wrote: > > > > 2. Consistent well known-options, button handling and papersize come > > to mind. others? > > when I wrote epson2 i removed the paper size support that was in epson. >

[sane-devel] SANE 1.1.0 Release discussion

On Mon, May 5, 2008 at 2:06 PM, Alessandro Zummo wrote: > On Mon, 5 May 2008 13:56:58 -0400 > "m. allan noah" wrote: > > > 3. Two new return codes: SANE_STATUS_HW_LOCK to tell the frontend that the > > scanner has a hardware lock installed, and SANE_STATUS_WARMING_UP for lamp. > > it would b

[sane-devel] SANE 1.1.0 Release discussion

Lets talk about SANE 1.1.0 release, both timetables and deliverables. I have tried to pick some things from recent discussions, and build on the momentum provided by stef and julien. It is not my intention to hijack this process, but I have some spare cycles coming up, and we are all tired of talki