Brad Sawatzky <[EMAIL PROTECTED]> writes: > 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>
ACK. > 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? Not off the top of my head, but with, what, 50? models supported by the backend, capability to scan with bit depths ranging from 1 to 16 depending on the model and about a week behind schedule, I prefer to put this not near to top of my TODO list :-| >> 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[]. I'll have a second look at that. >> | - 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. As in "damage the hardware"? Probably not. Your patches for Julien's epkowa backend are against code from iscan-2.10. Julien has not upgraded to the sources for iscan-2.11 yet. That very understandable because it will break support for all models that need an interpreter (except the GT-X770 / Perfection V500). Once AVASYS releases fixed interpreters, all Julien should have to do is upgrade to the latest epkowa backend sources. Julien is free to decide whether he'll include your patches in his sane-backends-extras for the time being and rip them out again when upgrading to iscan-2.11 or later. But I don't quite see a need to include them in the AVASYS iscan sources. Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
