kopia lustrzana https://gitlab.com/sane-project/website
110 wiersze
5.1 KiB
HTML
110 wiersze
5.1 KiB
HTML
<!-- received="Sun Aug 15 17:13:05 1999 PDT" -->
|
|
<!-- sent="Sun, 15 Aug 1999 17:12:52 -0700" -->
|
|
<!-- name="Stephen Williams" -->
|
|
<!-- email="steve@icarus.com" -->
|
|
<!-- subject="Re: SANE frames" -->
|
|
<!-- id="199908160012.RAA07038@icarus.com" -->
|
|
<!-- inreplyto="Pine.LNX.4.10.9908152307370.24019-100000@chef.ecs.soton.ac.uk" -->
|
|
<title>sane-devel: Re: SANE frames</title>
|
|
<h1>Re: SANE frames</h1>
|
|
<b>Stephen Williams</b> (<a href="mailto:steve@icarus.com"><i>steve@icarus.com</i></a>)<br>
|
|
<i>Sun, 15 Aug 1999 17:12:52 -0700</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#184">[ date ]</a><a href="index.html#184">[ thread ]</a><a href="subject.html#184">[ subject ]</a><a href="author.html#184">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0185.html">Tom Martone: "Re: SANE frames"</a>
|
|
<li> <b>Previous message:</b> <a href="0183.html">Tom Martone: "Re: SANE V2"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
<a href="mailto:njl98r@ecs.soton.ac.uk">njl98r@ecs.soton.ac.uk</a> said:<br>
|
|
<i>> Yes. It's wrong behaviour to pretend you understand unknown formats --</i><br>
|
|
<i>> If you can't think of anything better to do: Scream and Shout and</i><br>
|
|
<i>> Stamp your feet so that the user knows something is wrong.</i><br>
|
|
<p>
|
|
Here's what I think (he says, opening the gas can in preparation for<br>
|
|
adding fuel to the fire:-)<br>
|
|
<p>
|
|
I think that frame format should be selected as an option, the default<br>
|
|
always being one of the existing types. The "format" option should<br>
|
|
be a well-known option with type SANE_TYPE_INT and constrained by<br>
|
|
SANE_CONSTRAINT_WORD_LIST.<br>
|
|
<p>
|
|
If the application does nothing to this option, then the format that<br>
|
|
the scanner uses to send the data should be one of GRAY or RGB. If the<br>
|
|
application is old, it will not ask for an advanced frame type. If<br>
|
|
the user asks for an advanced frame type because the old application<br>
|
|
has a GUI that blindy offers the option, then oh well.<br>
|
|
<p>
|
|
The format needs to be a well known option because an application may<br>
|
|
support some advanced types and may want to ask an arbitrary device what<br>
|
|
types is supports. The application may for example be asked by the user<br>
|
|
to scan to a jpeg file. The application can look in the "format"<br>
|
|
constraints to see if hardware JPEG support exists, and if so use that.<br>
|
|
<p>
|
|
It is hard to get old applications to deal with JPEG because the size<br>
|
|
of the frame is difficult to express with the SANE_Parameters structure.<br>
|
|
Do you include accurate image dimensions in pixels_per_line and lines?<br>
|
|
<p>
|
|
If we want to avoid an enumeration, then perhaps the "format" option<br>
|
|
can be instead a SANE_TYPE_STRING with the SANE_CONSTRAINT_STRING_LIST<br>
|
|
constraint. You can use mime types for the strings. The problem with<br>
|
|
this is that the format in the SANE_Parameters structure will need to<br>
|
|
be changed to "const char*".<br>
|
|
<p>
|
|
This is an incompatible change. This would be SANE 2.0, if ever.<br>
|
|
(It has the advantage of supporting arbitrary multimedia.)<br>
|
|
<p>
|
|
...<br>
|
|
<p>
|
|
Anyhow, to summarize. If we simply add new frame formats and define<br>
|
|
them as advanced or optional, drivers will be expected to support the<br>
|
|
existing formats as defaults. This will allow old applications to work.<br>
|
|
Add wording to the standard something like:<br>
|
|
<p>
|
|
"All SANE drivers must support at least one of SANE_FRAME_GRAY<br>
|
|
and SANE_FRAME_RGB. All SANE applications must support *both*<br>
|
|
SANE_FRAME_GRAY *and* SANE_FRAME_RGB. The driver must provide<br>
|
|
data in one of these standard formats unless requested otherwise<br>
|
|
by manipulation of its "format" option."<br>
|
|
<p>
|
|
should protect most existing applications.<br>
|
|
<p>
|
|
We should define a well known "format" option that enumerates the<br>
|
|
formats that the device supports so that a format-aware application<br>
|
|
can make some informed decisions. For example, a smart GUI application<br>
|
|
that supports writing files but does not have a JPEG compressor can<br>
|
|
check with the driver, and gray out the option if the hardware doesn't<br>
|
|
have compression.<br>
|
|
<p>
|
|
IMPORTANT POINT:<br>
|
|
** Once the well-known option is added, new "advanced" frame formats<br>
|
|
** can be added liberally without ever again breaking compatibility.<br>
|
|
<p>
|
|
<p>
|
|
<pre>
|
|
--
|
|
Steve Williams "The woods are lovely, dark and deep.
|
|
<a href="mailto:steve@icarus.com">steve@icarus.com</a> But I have promises to keep,
|
|
<a href="mailto:steve@picturel.com">steve@picturel.com</a> and lines to code before I sleep,
|
|
<a href="http://www.picturel.com">http://www.picturel.com</a> And lines to code before I sleep."
|
|
<p>
|
|
<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="0185.html">Tom Martone: "Re: SANE frames"</a>
|
|
<li> <b>Previous message:</b> <a href="0183.html">Tom Martone: "Re: SANE V2"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|