AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2016.07.05 09:41 "[Tiff] Proposed API improvements", by Yakov Galka
2016.07.05 14:51 "Re: [Tiff] Proposed API improvements", by Olivier Paquet
2016.07.05 15:41 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn
2016.07.05 16:14 "Re: [Tiff] Proposed API improvements", by Olivier Paquet
2016.07.05 17:18 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn
2016.07.05 19:52 "Re: [Tiff] Proposed API improvements", by Olivier Paquet
2016.07.06 14:25 "Re: [Tiff] Proposed API improvements", by Yakov Galka
2016.07.06 14:48 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn
2016.07.19 13:36 "Re: [Tiff] Proposed API improvements", by Yakov Galka
2016.07.19 14:17 "Re: [Tiff] Proposed API improvements", by Olivier Paquet
2016.07.19 14:41 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn

2016.07.19 13:36 "Re: [Tiff] Proposed API improvements", by Yakov Galka

Ok, I was thinking more about it and had studied some code... So some extra input follows.

On Tue, Jul 5, 2016 at 5:51 PM, Olivier Paquet <olivier.paquet@gmail.com> wrote:

> There doesn't seem to be any
> shortened name in the API though so I believe TIFFTileDimensions would
> fit better.
>

This is not actually true. Just a few I found: Dir(ectory), Proc(edure), Ext(ention), Info(rmation). Not that I'm trying to take a position here.

On Tue, Jul 5, 2016 at 10:52 PM, Olivier Paquet <olivier.paquet@gmail.com> wrote:

> Some grepping shows the codec registration functions are the only ones > to have this problem. Everything else appears to either take a handle

> or not yet produce any error messages.
>

Not exactly. The functions which open files have some code that reports errors before a TIFF structure was created. It is possible to pass clientdata and errorProcs as deep as needed, but it isn't pretty.

I start leaning towards the way SQLite handles errors. There are no callback functions (which solves problems wrt longjmp and C++ exceptions, which libtiff currently eludes), and instead it sets an error on the sqlite3 object. If some operation fails the user can query the sqlite3 object for the latest error string. The sqlite3_open functions return a valid sqlite3 object even on failure, and it contains the error description if they failed (they indicate failure by a returned error code). The only possible error condition where an error string is not available is when sqlite3 could not be allocated, but this happens only in out-of-memory condition.

What do you think?

On Wed, Jul 6, 2016 at 5:48 PM, Bob Friesenhahn < bfriesen@simple.dallas.tx.us> wrote:

Libtiff has been in use for 28 years already. Most of the applications which will use it are written already and the persons who wrote the interfacing code (or know how to do so) may not be available any more.

It sounds like you believe that your own software has no future.. Why the pessimism? TIFF is still a widely used format that does not have a substitute in the respective professional areas, and libtiff is the most widely used library to read that format.

--

Yakov Galka
http://stannum.co.il/