Alessandro Zummo writes: > On Mon, 19 Oct 2015 22:20:25 +0900 > Olaf Meeuwissen <paddy-h...@member.fsf.org> wrote: > >> Adding support for new devices, improving functionality for devices that >> are already supported and fixing bugs will be part of 1.0.26 as well but >> I think that that goes without saying. Said it anyway and maybe that is >> just as well. Better be explicit. > > Thanks for your hard work.
Thanks for the thanks ;-) It's nice to know at least some people appreciate what one's doing. > Regarding coolscan3, epson2 and epsonds, > I have no major additions. > > The first has probably a lot of bugs, but I miss any detailed > specification from Nikon for most of the scanners. No specs is a problem that probably affects most of the backend developers. Reverse engineering is no fun and even less so when you don't have direct access to a device. Maybe we could think about how to approach manufacturers to get access to specs and/or devices (and under what conditions because we still want to be able to release source code under LGPL-like conditions!) but that is not for 1.0.26. Perhaps a discussion about this is better conducted off-list. Anyway, this is not something that affects 1.0.26 directly. > [snip epson2 and epsonds stuff] > I welcome C99/C11 and the new libusb. C11? Too early, I think. C99? So far we have 3 ayes and 0 nays. > There's probably still some bug in the usb code. I have > intermittent results with some scanners on usb2 > and with others on usb3. switching among the two usb > standards solves them all. I'm curious about USB related issues that other backends are facing that might be solved by switching to libusb-1 as the default. I intend to keep libusb-0 as a fallback for 1.0.26. > Infrared support could be finally enabled as well. my own > tiffscan frontend already handles it and I had some > good results using it with coolscan3 and doing > IR scratch removal with vuescan directly on the produced tiff files. IR support? I knew you were gonna bring that up ;-) but that's a SANE API change. Given the schedule for 1.0.26, I don't think that is doable within that time frame. If we are going to change the API, there are probably a *lot* of things we should work out before we can commit to anything. One of those things would be a clearly documented mechanism for API changes so that backends *and* frontends can deal with them in a graceful and sane manner (pun intended) and changes can be made in a more incremental fashion than library major so-version bumps (if at all possible). There's lots more but I'll keep that for later so I can focus on getting a 1.0.26 out in time for the major Linux distribution's spring releases. If there are other releases SANE should care about, please say so! Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 Support Free Software Support the Free Software Foundation https://my.fsf.org/donate https://my.fsf.org/join GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org