Oliver,
But if it was compulsary for a b/e to support the current transfer
mechanism then couldn't the f/e simply fall back to using this method if
it didn't support other image encodings.
mick
Oliver Rauch wrote:
>
> Stephen Williams wrote:
>
> > Other then that, supporting new formats should be easy and backwards
> > compatible. Just create a well-known-type "transfer-type" with the
> > default always set to TRANSFER_TYPE_SANE that acts like the existing
> > in-memory transfer.
>
> Hi Stephen,
>
> it is not a good idea to add such a hack to the currecnt sane standard.
> You can not only create a backend that uses such (more or less) "well known"
> option, you also need frontends that do handle this.
> And there is much more to take care about.
> With your suggestion a graphical frontend has to be able to
> deocde a compressed image data to create a preview from this. Or you
> will not be able to create a preview from it.
>
> Please do not suggest to do such wild things with the sane-1 standard.
>
> If I find the time I will go through all the suggestions I collected
> from the discussions about the sane-2 standard. Then we can spend
> our time and work to keep the sane-1 standard clean and define and
> implement a proper sane-2 standard.
>
> Bye
> Oliver
>
> --
> Homepage: http://www.rauch-domain.de
> sane-umax: http://www.rauch-domain.de/sane-umax
> xsane: http://www.xsane.org
> E-Mail: mailto:Oliver.Rauch@rauch-domain.de
>
> --
> Source code, list archive, and docs: http://www.mostang.com/sane/
> To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Thu May 03 2001 - 14:45:39 PDT