# Re: SANE API & file format

From: Stephen Williams (steve@icarus.com)
Date: Thu May 03 2001 - 15:34:39 PDT

- Next message: shailendra mehta: "RE: SANE API & file format"
  - Previous message: Oliver Rauch: "Re: SANE API & file format"
  - In reply to: Mick Barry: "Re: SANE API & file format"
  - Next in thread: Oliver Rauch: "Re: SANE API & file format"
  - Next in thread: Frederik Ramm: "Re: SANE API & file format"
  - Reply: Oliver Rauch: "Re: SANE API & file format"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  oliver.rauch@rauch-domain.de said:
  > 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.

  No. The default behavior should be defined so that existing front-ends
  continue to work normally. The burden is placed on the driver to see
  that that is so. The default SANE transfer type must be supported by
  a driver as the default for the sake of guaranteed minimum compatibility.

  Therefore, if the applications never sets the transfer type, the driver
  must supply it in the sane-1 manner.

  mick@objects.com.au said:
  > 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.

  Exactly. In fact, the existing SANE format must not only be supported,
  but must be the default. That way, an existing sane 1.0 application,
  which knows nothing of transfer types, should have no trouble using
  a backend that supports many transfer types.

  Maybe this is a sane-2 item, but I contend that it is entirely compatible
  with existing applications and drivers.

  mick@objects.com.au said:
  > If a f/e doesn't support a particular encoding then it would not
  > request it.

  Exactly, and in that case, the back-end will translate the stream to
  the basic SANE format.

  > So I think it is compulsary to
  > - include the transformation (uncompression) in the backend for sane-1
  > - add support for new file formats to sane-2

  And I'm saying that support for new formats can be done in a way that
  is compatible with sane-1 applications and drivers.

      --
      Steve Williams                "The woods are lovely, dark and deep.
      steve@icarus.com              But I have promises to keep,
      steve@picturel.com            and lines to code before I sleep,
      http://www.picturel.com       And lines to code before I sleep."
      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: shailendra mehta: "RE: SANE API & file format"
  - Previous message: Oliver Rauch: "Re: SANE API & file format"
  - In reply to: Mick Barry: "Re: SANE API & file format"
  - Next in thread: Oliver Rauch: "Re: SANE API & file format"
  - Next in thread: Frederik Ramm: "Re: SANE API & file format"
  - Reply: Oliver Rauch: "Re: SANE API & file format"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Thu May 03 2001 - 15:25:32 PDT