I am really confused :) I was under the impression that the SANE project was proposing a better = alternative to the TWAIN interface. Better, meaning that the backend is = written once and is cross platform. That's what I understood from the = intro page on the web-site (I pasted part of the intro here for your = convenience).
<snippet from intro page on www.sane-project.org> If you're familiar with TWAIN, you may wonder why there is a need for = SANE. Simply put, TWAIN does not separate the user-interface from the = driver of a device. This, unfortunately, makes it difficult, if not = impossible, to provide network transparent access to image acquisition = devices (which is useful if you have a LAN full of machines, but = scanners connected to only one or two machines; it's obviously also = useful for remote-controlled cameras and such). It also means that any = particular TWAIN driver is pretty much married to a particular GUI API = (be it Win32 or the Mac API). In contrast, SANE cleanly separates device = controls from their representation in a user-interface. As a result, = SANE has no difficulty supporting command-line driven interfaces or = network-transparent scanning. For these reasons, it is unlikely that = there will ever be a SANE backend that can talk to a TWAIN driver. The = converse is no problem though: it is pretty straight forward to access = SANE devices through a TWAIN source. In summary, if TWAIN had been just = a little better designed, there would have been no reason for SANE to = exist, but things being the way they are, TWAIN simply isn't SANE. </snippet> I guess without an image or in depth technical explanation, I am having = a difficult time understanding where SANE and TWAIN operate on different = levels, as you indicated in your message. Your message indicates that = TWAIN is a necessary technology, but the intro page indicates that TWAIN = is not necessary, and that SANE is the replacement. And from the intro page, I thought that a scanner manufacturer that = bundles 3rd-party TWAIN-compliant front-ends (OCR packages, = Photoshop-like packages, etc.), but who wanted to move to supporting = SANE could make the SANE backend and keep their Win32 TWAIN front-end = for these 3rd-party software apps. Perhaps I misunderstood something = there too. Regarding manu. support, I wasn't thinking of formal contracts or such = with each manufacturer. In the beginning, just publicly crediting = companies that have contributed to various backends (even if it's only = one scanner). But make that information easily available on the = web-site, not burried in source code. Until I understand how the expected roles of TWAIN and SANE (as = architected in SANE, its roadmap, etc.) I cannot argue my points about = simply making the web-site contain more information about the = importance, benefits, momentum, and support of the SANE project. If you = could take a moment, I'd appreciate it. There are many components in = talking to a scanner, and I don't see how they all fit together. 1. driver (OS and scanner chipset dependent),=20 2. connection protocol handler (USB, SCSI, TCP/IP, Bluetooth?) 3. TWAIN? 4. SANE? 5. Applications If you have a moment to draw out the ideal setup, I'd appreciate it. Thanks, Dave Paules > -----Original Message----- > From: Major A [mailto:and...@users.sourceforge.net] > Sent: Sunday, July 11, 2004 12:16 AM > To: David N. Paules > Cc: SANE devel > Subject: Re: [sane-devel] discussion: Future of SANE-project >=20 >=20 >=20 > > But, if the ultimate goal of SANE is to supplant TWAIN as the > > standard for accessing image devices, shouldn't more effort be put >=20 > I don't think it is. TWAIN and SANE act on completely different > levels. I suppose that once a sufficiently large number of > manufacturers support SANE with their code (binary or open-source), > they will begin to see that there's no point in wasting time and money > writing a separate Windows/MacOS driver, they will just use SANE on > these platforms too, with the cross-platform SANE backend they had to > write anyway (possibly with their own frontend optimized for their > scanners). TWAIN is still going to be the interface between the > frontend and the application the image is to be imported to. >=20 > > Perhaps working examples demonstrating how scanner makers can > > leverage their investment in TWAIN support while migrating to SANE > > might be useful for getting scanner makers to take notice of > > SANE. If an upgrade path was readily shown, techno-geeks at the > > manufacturer might prefer and sell the SANE idea to managers within > > the company. >=20 > I don't think we can do a lot at the moment. There's no update path > from TWAIN to SANE that I can see, and you can't tell who the > techno-geeks in a company are without having had prior contact with > them. I think that more and more developers of proprietary software > realize that open-source can save them money and effort and create > superior products (they already see that the first time they pop that > Knoppix CD into their Windows computer), so it's only a matter of time > before they start lobbying within the company. >=20 > > Formal propoganda of industry heavyweight support (a consortium of > > scanner makers and front-end application development houses) on the > > web-site might make other makers feel the need to join in. >=20 > That sounds a bit like Darl McBride to me. I don't think any of us > hobbyist SANE developers have the financial and legal backing needed > to claim any heavyweight industry support. >=20 > > Without this kind of direction, I simply see SANE as being a > > hobbyist-level effort which is why I questioned the future of > > it. Thanks for listening and answering my questions. >=20 > That's how all open-source projects start out, just like Linux, GIMP, > etc. Look at what's become of them, I'm quite confident that SANE will > have a similar future. >=20 > Andras
