kopia lustrzana https://gitlab.com/sane-project/website
122 wiersze
6.2 KiB
HTML
122 wiersze
6.2 KiB
HTML
|
<!-- received="Sun Aug 15 17:49:53 1999 PDT" -->
|
|||
|
|
<!-- sent="Sun, 15 Aug 1999 20:07:52 -0400" -->
|
|||
|
|
<!-- name="Tom Martone" -->
|
|||
|
|
<!-- email="tom@martoneconsulting.com" -->
|
|||
|
|
<!-- subject="Re: SANE frames" -->
|
|||
|
|
<!-- id="" -->
|
|||
|
|
<!-- inreplyto="SANE frames" -->
|
|||
|
|
<title>sane-devel: Re: SANE frames</title>
|
|||
|
|
<h1>Re: SANE frames</h1>
|
|||
|
|
<b>Tom Martone</b> (<a href="mailto:tom@martoneconsulting.com"><i>tom@martoneconsulting.com</i></a>)<br>
|
|||
|
|
<i>Sun, 15 Aug 1999 20:07:52 -0400</i>
|
|||
|
|
<p>
|
|||
|
|
<ul>
|
|||
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#185">[ date ]</a><a href="index.html#185">[ thread ]</a><a href="subject.html#185">[ subject ]</a><a href="author.html#185">[ author ]</a>
|
|||
|
|
<!-- next="start" -->
|
|||
|
|
<li> <b>Next message:</b> <a href="0186.html">Nick Lamb: "Re: SANE V2"</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0184.html">Stephen Williams: "Re: SANE frames"</a>
|
|||
|
|
<li> <b>Maybe in reply to:</b> <a href="0173.html">Stephen Williams: "SANE frames"</a>
|
|||
|
|
<!-- nextthread="start" -->
|
|||
|
|
<li> <b>Next in thread:</b> <a href="0209.html">Oliver Rauch: "Re: SANE frames"</a>
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|
|||
|
|
<!-- body="start" -->
|
|||
|
|
Nick Lamb wrote:<br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> On Sun, 15 Aug 1999, Tom Martone wrote:</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> > SANE_FRAME_ASCII: The frame contains a stream of ASCII text.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Wouldn't this normally be associated with an image? If so it might be</i><br>
|
|||
|
|
<i>> better to do this as multi-frame, with the ASCII frame followed by</i><br>
|
|||
|
|
<i>> zero or more image frames as appropriate. Then you can explain in the</i><br>
|
|||
|
|
<i>> standard that a frontend is free to throw away the ASCII frame, and</i><br>
|
|||
|
|
<i>> hope there are image frames following it..?</i><br>
|
|||
|
|
Yes, it would be associated with an image in almost all cases. I <br>
|
|||
|
|
thought that the multi-frame approach would be a bit more difficult<br>
|
|||
|
|
for the front-ends to deal with, as well as more difficult to specify.<br>
|
|||
|
|
I was planning to leave the chore of associating the barcodes with the<br>
|
|||
|
|
images as a separate issue handled outside of the frontend. The<br>
|
|||
|
|
images and text frames arrive in a predictable order (as defined by<br>
|
|||
|
|
the backend documentation), so the association could be done later<br>
|
|||
|
|
as a separate step. Not that it is all that important, but the text<br>
|
|||
|
|
frame with the barcodes is being sent last by the bh backend.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> Some image file formats (Oliver, are you listening?) even make some</i><br>
|
|||
|
|
<i>> provision for storing short-ish ASCII streams with the image, in a</i><br>
|
|||
|
|
<i>> more or less general way.</i><br>
|
|||
|
|
Yes, this is certainly true with TIFF images, for instance. I think<br>
|
|||
|
|
Oliver is putting some commentary in some of the formats, if I remember<br>
|
|||
|
|
correctly. Then it would seem more valuable to get the ASCII and the<br>
|
|||
|
|
images, synced in a multi-frame. <br>
|
|||
|
|
<p>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> > SANE_FRAME_RAW: The frame contains a stream of bytes (...)</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> I don't like this much, as everyone already knows, but if it must go</i><br>
|
|||
|
|
<i>> into SANE 2.0 then I'd prefer that it was numbered away from the rest</i><br>
|
|||
|
|
<i>> of the sequence in the enumerated type. I'd also like wording in the</i><br>
|
|||
|
|
<i>> documentation which asks backend creators to suggest new frame types</i><br>
|
|||
|
|
<i>> when necessary rather than using FRAME_RAW.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Perhaps -1 or 65535 or something? I think a signed integer is used for</i><br>
|
|||
|
|
<i>> storing this value, but I might be wrong...</i><br>
|
|||
|
|
Yes, it does seem to be an odd, useless, debugging sort of thing. I guess<br>
|
|||
|
|
what is intended here is to have a way to send data through without the<br>
|
|||
|
|
frontend mangling it in any way. In a way, a frontend should handle<br>
|
|||
|
|
unexpected frame types in the same way as they would handle RAW. <br>
|
|||
|
|
<p>
|
|||
|
|
For scanimage, I think it should write both RAW and unexpected frame types<br>
|
|||
|
|
out to stdout without putting a header on it. Maybe for the unexpected<br>
|
|||
|
|
frame type, it issues a warning. <br>
|
|||
|
|
<p>
|
|||
|
|
What the gui's will do is another matter. For RAW, they should write <br>
|
|||
|
|
it to their output file without a header. But for an unexpected frame <br>
|
|||
|
|
type they might want to have a dialog with the interactive user, and let<br>
|
|||
|
|
the user have control.<br>
|
|||
|
|
<p>
|
|||
|
|
I guess it's a mechanism where the backends can deliver the data, while<br>
|
|||
|
|
the FRAME definition and incorporation into the standard are taking<br>
|
|||
|
|
place. Then the frontends and middle-pieces evolve to find useful ways<br>
|
|||
|
|
to handle the new frame formats, and then the backend sets the newly<br>
|
|||
|
|
defined and sanctioned frame type and the value added features from the<br>
|
|||
|
|
frontend kicks in.<br>
|
|||
|
|
<p>
|
|||
|
|
I agree about some wording in the documentation suggesting having <br>
|
|||
|
|
well defined frame types and discouraging the abuse of the RAW format.<br>
|
|||
|
|
Maybe something like this?<br>
|
|||
|
|
<p>
|
|||
|
|
SANE_FRAME_RAW: The frame contains a stream of bytes that should not<br>
|
|||
|
|
be interpreted by the frontend in any way. This is a single frame<br>
|
|||
|
|
format. The values specified in the SANE_Parameters structure <br>
|
|||
|
|
should be: depth = 0, pixels_per_line = 0, bytes_per_line = 1, and <br>
|
|||
|
|
lines should contain the number of bytes in the frame or -1 if this <br>
|
|||
|
|
is not known a priori.<br>
|
|||
|
|
<p>
|
|||
|
|
NOTE: Backends are encouraged to use a descriptive format whenever<br>
|
|||
|
|
possible. The use of the SANE_FRAME_RAW format should not be a <br>
|
|||
|
|
substitute for adding the necessary additional frame formats to the<br>
|
|||
|
|
SANE standard.<br>
|
|||
|
|
<p>
|
|||
|
|
I guess we are in the process of seeing just how burdensome adding some<br>
|
|||
|
|
new frame formats will be.<br>
|
|||
|
|
<p>
|
|||
|
|
Tom Martone<br>
|
|||
|
|
<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="0186.html">Nick Lamb: "Re: SANE V2"</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0184.html">Stephen Williams: "Re: SANE frames"</a>
|
|||
|
|
<li> <b>Maybe in reply to:</b> <a href="0173.html">Stephen Williams: "SANE frames"</a>
|
|||
|
|
<!-- nextthread="start" -->
|
|||
|
|
<li> <b>Next in thread:</b> <a href="0209.html">Oliver Rauch: "Re: SANE frames"</a>
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|