I took the liberty of CC'ing Carl in this message in case he's interested. Carl, you can find the rest of the thread at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487462>
On Fri, 27 Jun 2008, Olaf Meeuwissen wrote: > I'm definitely not in favour of applying the epson4490-fixup.patch. > As for the 16bit patches from Carl, I already mentioned[1] that I'd > look at that. > > [1] http://lists.alioth.debian.org/pipermail/sane-devel/2008-June/022157.html Thanks for link. I have a question about this comment though: > Thanks for the patches. I'll take a look and see what, if, when and > in what form things will make it into the epkowa backend. Please note > that from iscan's (somewhat myopic) point of view, 16-bit support is > not required. All scans, except bi-level, are done with 8-bit. That > means that any 16-bit support that makes it in will be pretty much > untested. Without published specs, a lot of open source code is guess and check. Is there a specific technical problem with Carl's 16-bit patch that we can improve? > Here is the scoop on the epson4490-fixup.patch: > > | - Added 4800 dpi resolution which is suppported but not reported by the > | scanner. > > This will be automatically fixed when we release a new version of the > plugin to work with iscan-2.11.0 and later. > > | - Re-enabled 400 dpi resolution. There was no comment as to why it had [ . . ] > > That resolution was disabled to get ADF to work. Sorry for not adding > a comment. > > | - Fixed an off by one error in the original filter_resolution() function. > > The array has the size in its first element (see the last line of the > patch), as per requirement for SANE_CONSTRAINT_WORD_LIST. Instead of > fixing an off by one error, you introduce one. I don't think so... but the confusion is understandable. s->hw->resolution_list[] has the length in element 0, but s->hw->res_list[] does not. The length of s->hw->res_list[] is stored in s->hw->res_list_size. The for() loop was iterating over s->hw->res_list[]. > | - Enabled resolutions <300 dpi. This makes for _much_ faster preview [ . . . ] > This will also be automatically fixed with a new version of the plugin > for iscan-2.11.0 and later. > > WHEN will this new plugin be released? > > Honestly, I don't know (it not my call) but given how things are at > the moment it will not be anytime real soon now. I hope we can get > an updated version out sometime in autumn. Are there technical reasons why the above patches shouldn't be applied? The fact that these features will be fixed/supported in a future iscan release is great, but it shouldn't preclude their inclusion in the sane package now. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
