LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2008
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2008.11.14 23:32 "Re: example of (standalone) TIFFRegisterCODEC", by Brad Hards
On Saturday 15 November 2008 03:18:09 am you wrote: > I believe you will just need to manually install tiffiop.h and any other > include files you need. It will mean that any application registering > custom codecs will not be able to use "standard" libtiff sdk packages on > things like linux which lack the tiffiop.h include file. That is a problem. I'm trying to provide the MODI_VECTOR codec (which requires an EMF renderer) for the Okular viewer in KDE. We ship sources, not binaries. Distributions turn those into packages (with a dependency on a single copy of the libtiff shared library). I can live with "any version of libtiff after X", but I can't live with "specific version X", because libtiff gets upgraded in different cycles to okular generators. I'm also very reluctant to include a specific version of libtiff into okular. I think I understand why you don't want to always install tiffiop.h (or otherwise expose the struct tiff definition) - it is internal, and subject to change. I think the way to fix this is to complete the abstraction in libtiff. My current thinking is that there should be accessors for each thing that a codec needs to do (e.g. to set function pointers or obtain data). Those accessors would go into tiffio.h or perhaps into a new tiffcodec.h. This would be intended for external codecs (although there wouldn't be anything stopping built-in codecs using the API additions if desired). Does this look like a reasonable way forward? Brad