/mode annoyed on
Pardon ? Why ?
> Here is my counter-proposal, I think it's simpler and remains in the
> spirit of SANE 1.0
Sorry, if I sound a little pissed, but it might help to read up a little on
the history of SANE. You might wish to look at V 0.1 and the names in that
spec before judging "the spirit" of it.
> 1. Add several new SANE_FRAME_ (...) formats
Now _this_ IMHO is bad. What do you tell the user, if you encounter an
unknown format ?
Ahem - Mr. user - I got an unknown frame type #345. Should I save it ?
The reason for giving the mime type is, that you _can_ get a clue what the
unknown format is about using mime.types and/or the brains of the user.
I'd hate to first save a type #345 file, then ask the "file" magic database
about what it could be, just to find out that it's something very obscure
for which I have no convertors.
I'd rather be told it's "image/obscure-stuff-for-PDP-11" right away.
> Each frame format would be for a standards-based image compression format
> in common use on scanners.
Happy time hacking all of them in. Digital cameras are very creative in that
area.
> It should be possible to save the data stream exactly as transmitted into
> a file, and load that file into any suitable image viewer or editor.
How do you decide "suitable", if you just have an "unknown frametype" ?
> So far we've seen JFIF and the G3 series discussed on this list, unless
> anyone steps forward I would guess that's all there is for now.
Flashpix, Photo-CD, and about any other file-format for the case of picture
archives, which can as well be implemented as a SANE backend.
With more intelligence being moved into the scanners, we might get
text/plain or text/rtf in the future. TWAIN has provisions to read barcodes,
so their translation is probably also directly provided by some scanners.
> 2. Define appropriate behaviour for new frames
> The existing frame types have obvious meanings for bps, lines etc.
> but these may not be useful in the same way for compressed data. After
> looking at the existing software, and the new compressed formats, we
> need to define some appropriate behaviour in the SANE standard
I would simply consider them undefined and filled with values that will
allow for smooth transfer even with old code. They are of no interest to
you for the transmission. And any external format like JPG will have the
information we transfer outband for application/sane inband, that is,
included in the file stream itself.
> 3. Add extra well-known options
> compression "Controls image compression (e.g. JPEG, G3, NONE)"
> Backends should offer this option if they support standards-based
> compression.
> filename "Recommended file name (e.g. buttercup.jpg)"
> Backends with appropriate information can recommend a filename for
> storing this image on disk.
Pardon me ? This is precisely what I was proposing ... ???
Could you consider reading what others propose before judging ?
/mode annoyed off
CU, ANdy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com