AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1994.02.10 19:32 "LibTIFF working on MS-Windows 3.1.", by Soren Pingel Dalsgaard
1994.02.11 09:39 "Re: LibTIFF working on MS-Windows 3.1.", by Bjorn P. Brox
1994.02.11 01:09 "Re: LibTIFF working on MS-Windows 3.1.", by Richard Minner
1994.02.11 14:40 "Re: LibTIFF working on MS-Windows 3.1.", by Jie Yao
1994.02.11 01:16 "Re: LibTIFF working on MS-Windows 3.1.", by Richard Minner
1994.02.11 10:17 "Re: LIBTIFFW working on MS-Windows 3.1.", by Niles Ritter
1994.02.14 11:03 "Error/warning handlers in libtiff", by Erik Corry
1994.02.16 22:38 "Re: Error/warning handlers in libtiff", by Sam Leffler
1994.02.11 18:27 "Re: LibTIFF working on MS-Windows 3.1.", by Francois Gauthier
1994.02.11 21:29 "Re: LibTIFF working on MS-Windows 3.1.", by Sam Leffler

1994.02.16 22:38 "Re: Error/warning handlers in libtiff", by Sam Leffler

As others have mentioned, there are of course ways to override the default action. The real point, though, is that you would like to formulate the new way of performing an interface-action in such a way that it can be gracefully integrated with the libtiff proper. The reason isn't just for other host's sake; if your code remains compatible with the public libtiff, then when improvements/new compression schemes (such as the long-awaited JPEG-in-TIFF) become part of libtiff you will not have to deal with so much grief.

While we are on the subject, there is a fairly simple change to the Tiff library, which I have not yet had time to do, but which would improve the usability of the library in applications with several threads.

The libtiff has a generally exemplary clean interface, but...

At the moment, the only way of getting information other than the error message itself into the error handler is through global variables. For example the infos allowing the error handler to pop up a window in X (application context, parent window, application name for the window manager bar) must be accessed by the error handler through global variables. This is generally undesirable and obviously precludes having several app-contexts. In the application in which I use the libtiff at the moment, there is a second problem, as the libtiff is called from signal handlers. (As well as from the User Interface, X-Windows code). It is very difficult to know what to do about error messages since X is not callable from a signal handler, and X is also not callable from a library which in turn uses the libtiff, but is not X-based. It all becomes very ugly.

My proposed solution would be:

  1. To allow the user of the library to give a void pointer as error-handler- client-data. When the error handler is called, it is given this void pointer which is cast into a pointer to a structure containing all the context the error handler needs. This technique, under the name of client_data, or closure works very well for X-Windows allowing you to avoid global variables, with the problems they bring with them.

Sounds ok, send me mods to implement it.

  1. To allow the error handler and closure to be given on a per-tiff basis, ie as parameters to the 'open' functions. This means storing the values in the TIFF structure instead of in global variables. For backwards binary compatibility, the old functions could be adapted to still produce the expected results.

Since "open" is synchronous, there's no reason to change its interface. You can instead setup handlers in separate library calls. Once again this sounds ok, though I don't figure to implement it. Send me mods and we can discuss getting it integrated into a new version of the library.

As I said, I have not yet had time to make these changes. Would they be integrated into the library if I did?

I welcome reasonable changes to the library. "reasonable" is of course whatever I think is good :-). Honestly I'm quite open to improving the software, but I am not willing to devote huge amounts of time to the current code or to integrate major modifications w/o a significant payback. The library needs a complete rewrite and if/when that is done it will be recoded in C++.

        Sam