kopia lustrzana https://gitlab.com/sane-project/website
71 wiersze
3.3 KiB
HTML
71 wiersze
3.3 KiB
HTML
|
<!-- received="Sun Aug 22 17:20:32 1999 PDT" -->
|
|||
|
|
<!-- sent="Mon, 23 Aug 1999 01:25:13 +0100 (GMT)" -->
|
|||
|
|
<!-- name="Nick Lamb" -->
|
|||
|
|
<!-- email="njl98r@ecs.soton.ac.uk" -->
|
|||
|
|
<!-- subject="Re: SANE V2" -->
|
|||
|
|
<!-- id="" -->
|
|||
|
|
<!-- inreplyto="19990818013441.A904@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>Mon, 23 Aug 1999 01:25:13 +0100 (GMT)</i>
|
|||
|
|
<p>
|
|||
|
|
<ul>
|
|||
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#275">[ date ]</a><a href="index.html#275">[ thread ]</a><a href="subject.html#275">[ subject ]</a><a href="author.html#275">[ author ]</a>
|
|||
|
|
<!-- next="start" -->
|
|||
|
|
<li> <b>Next message:</b> <a href="0276.html">Adam Williams: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint LT"</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0274.html">Bernd Schroeder: "Re: microtek X6 advance and TMA"</a>
|
|||
|
|
<!-- nextthread="start" -->
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|
|||
|
|
<!-- body="start" -->
|
|||
|
|
Well, Andreas seems primarily to be concerned about indentifying a frame<br>
|
|||
|
|
type to the user in the event that it's not natively understand by an<br>
|
|||
|
|
old backend. Honestly I don't think this is a serious problem is real<br>
|
|||
|
|
world use, but it's easily overcome without using the (IMHO) rather<br>
|
|||
|
|
unfriendly quasi-human-readable MIME types.<br>
|
|||
|
|
<p>
|
|||
|
|
We can simply associate a short text string with each defined type, in<br>
|
|||
|
|
the standard and in backend header files, and any frontend which can't<br>
|
|||
|
|
handle the data format it receives (presumably because of a user<br>
|
|||
|
|
advanced setting or badly behaved backend) will just look in the<br>
|
|||
|
|
getparm results for "frame_description" and say...<br>
|
|||
|
|
<p>
|
|||
|
|
Sorry, I can't handle image data in the format:<br>
|
|||
|
|
<insert short description here><br>
|
|||
|
|
Save to a file anyway? (Y)es / No<br>
|
|||
|
|
<p>
|
|||
|
|
The other point which _keeps_ being made by proponents of MIME in this<br>
|
|||
|
|
debate is that there will "inevitably" be a huge number of formats to<br>
|
|||
|
|
support -- yet this is hardly bourne out by an examination of MIME<br>
|
|||
|
|
or by looking at scanners "In the wild". The four new data formats<br>
|
|||
|
|
(and two other formats) suggested by backend writers so far seem to<br>
|
|||
|
|
cover a broad range of high-end scanners.<br>
|
|||
|
|
<p>
|
|||
|
|
Before you make this argument again, I want _evidence_ that we're going<br>
|
|||
|
|
to be swamped by more image formats.<br>
|
|||
|
|
<p>
|
|||
|
|
Further, I think SANE's use of standards-based formats (like JFIF)<br>
|
|||
|
|
is important because SANE is also a Free Software project. Wherever<br>
|
|||
|
|
we have a choice we should encourage Open standards rather than<br>
|
|||
|
|
Proprietary technology. In the backend we have little choice, but<br>
|
|||
|
|
in the SANE protocol and API we *do* have a choice.<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="0276.html">Adam Williams: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint LT"</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0274.html">Bernd Schroeder: "Re: microtek X6 advance and TMA"</a>
|
|||
|
|
<!-- nextthread="start" -->
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|