kopia lustrzana https://gitlab.com/sane-project/website
106 wiersze
5.0 KiB
HTML
106 wiersze
5.0 KiB
HTML
<!-- received="Sun Aug 15 14:10:40 1999 PDT" -->
|
||
<!-- sent="Sun, 15 Aug 1999 22:10:32 +0100 (GMT)" -->
|
||
<!-- name="Nick Lamb" -->
|
||
<!-- email="njl98r@ecs.soton.ac.uk" -->
|
||
<!-- subject="Re: SANE V2" -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="19990815135354.B539@rz.uni-duesseldorf.de" -->
|
||
<title>sane-devel: Re: SANE V2</title>
|
||
<h1>Re: SANE V2</h1>
|
||
<b>Nick Lamb</b> (<a href="mailto:njl98r@ecs.soton.ac.uk"><i>njl98r@ecs.soton.ac.uk</i></a>)<br>
|
||
<i>Sun, 15 Aug 1999 22:10:32 +0100 (GMT)</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#177">[ date ]</a><a href="index.html#177">[ thread ]</a><a href="subject.html#177">[ subject ]</a><a href="author.html#177">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0178.html">Tom Martone: "Re: SANE frames"</a>
|
||
<li> <b>Previous message:</b> <a href="0176.html">Tom Martone: "Re: SANE frames"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
On Sun, 15 Aug 1999, Andreas Beck wrote:<br>
|
||
<p>
|
||
<i>> Sorry, if I sound a little pissed, but it might help to read up a little on</i><br>
|
||
<i>> the history of SANE. You might wish to look at V 0.1 and the names in that</i><br>
|
||
<i>> spec before judging "the spirit" of it.</i><br>
|
||
<p>
|
||
I know. That's why I'm sad that you (and apparently David) are proposing<br>
|
||
to butcher SANE in the way you described. If you take the course you<br>
|
||
originally proposed, I genuinely believe it will be the end of SANE.<br>
|
||
<p>
|
||
MIME is not a solution to your problems, even the MIME types system is<br>
|
||
probably overkill, but MIME itself is definitely *not* what SANE needs to<br>
|
||
support the scanners we've been talking about on the list.<br>
|
||
<p>
|
||
<i>> Happy time hacking all of them in. Digital cameras are very creative in that</i><br>
|
||
<i>> area. </i><br>
|
||
<p>
|
||
I'm not interested in having fairly bad support for digital cameras in SANE<br>
|
||
when there's really good support for digital cameras in gPhoto. Since<br>
|
||
we are now working toward TWAIN/Unix, it makes sense for gPhoto and SANE<br>
|
||
to each implement TWAIN sources on top of their respective APIs.<br>
|
||
<p>
|
||
<i>> Flashpix, Photo-CD, and about any other file-format for the case of picture</i><br>
|
||
<i>> archives, which can as well be implemented as a SANE backend.</i><br>
|
||
<p>
|
||
I want SCANNER ACCESS NOW EASY. I don't want CAT FOOD NOW CHEAP, or CAMERA<br>
|
||
SUPPORT NOW MEDIOCRE or PHOTOS NOW STORED CENTRALLY<br>
|
||
<p>
|
||
We *could* implement anything as a SANE backend, and I guarantee that you<br>
|
||
will find at least one person who'll ask for HTML, MP3 and probably for<br>
|
||
a new API better suited to the Amiga. I'm not interested in fantasy, I<br>
|
||
want the next generation SANE to be a useful and effective tool.<br>
|
||
<p>
|
||
It's worth stating here that right from the start I was suprised that<br>
|
||
SANE had xcam, because the SANE API is exactly the wrong way to do that<br>
|
||
sort of thing. No surprise for me when it was altogther the least used<br>
|
||
feature of SANE. Now of course there's better support for the QuickCam<br>
|
||
in other applications and APIs.<br>
|
||
<p>
|
||
<i>> With more intelligence being moved into the scanners, we might get</i><br>
|
||
<i>> text/plain or text/rtf in the future. TWAIN has provisions to read barcodes,</i><br>
|
||
<i>> so their translation is probably also directly provided by some scanners.</i><br>
|
||
<p>
|
||
If the scanner wants to speak text, it's probably beyond the territory<br>
|
||
we should sensibly stake out for SANE. At that point you're looking at a<br>
|
||
whole new class of device IMHO.<br>
|
||
<p>
|
||
<i>> I would simply consider them undefined and filled with values that will</i><br>
|
||
<i>> allow for smooth transfer even with old code. They are of no interest to</i><br>
|
||
<i>> you for the transmission. And any external format like JPG will have the</i><br>
|
||
<i>> information we transfer outband for application/sane inband, that is,</i><br>
|
||
<i>> included in the file stream itself.</i><br>
|
||
<p>
|
||
application/sane? <br>
|
||
<p>
|
||
<i>> > filename "Recommended file name (e.g. buttercup.jpg)"</i><br>
|
||
<i>> > Backends with appropriate information can recommend a filename for</i><br>
|
||
<i>> > storing this image on disk.</i><br>
|
||
<i>> </i><br>
|
||
<i>> Pardon me ? This is precisely what I was proposing ... ???</i><br>
|
||
<i>> Could you consider reading what others propose before judging ?</i><br>
|
||
<p>
|
||
That was one option, the one you seemed to favour less, and for only a<br>
|
||
small part of your proposal. I don't think "filename" will be used much<br>
|
||
anyway, because most of the devices I can envision being used with<br>
|
||
SANE don't have a useful filename to suggest.<br>
|
||
<p>
|
||
Nick.<br>
|
||
<p>
|
||
<p>
|
||
<pre>
|
||
--
|
||
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
||
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
||
</pre>
|
||
<!-- body="end" -->
|
||
<p>
|
||
<ul>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0178.html">Tom Martone: "Re: SANE frames"</a>
|
||
<li> <b>Previous message:</b> <a href="0176.html">Tom Martone: "Re: SANE frames"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|