AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2006

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



Valid HTML 4.01!



Thread

2006.01.01 16:57 "Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.01 18:02 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.01 18:50 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.01 21:13 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.02 16:08 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.03 00:27 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Jay Berkenbilt
2006.01.03 02:31 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.04 13:23 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Andrey Kiselev
2006.01.04 16:18 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Bob Friesenhahn
2006.01.07 02:59 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Jay Berkenbilt

2006.01.03 00:27 "Re: Outrageous profile tag sizes reported by libtiff 3.8.0", by Jay Berkenbilt

Bob Friesenhahn wrote:
>
> A bit of testing shows that previously the third parameter of
> TIFFGetField() was of type uint32 when retrieving TIFFTAG_ICCPROFILE,
> TIFFTAG_PHOTOSHOP, TIFFTAG_RICHTIFFIPTC, TIFFTAG_XMLPACKET, but in
> 3.8.0 the size is a uint16.  Unfortunately this interface is not fully
> defined by a header file since it is based on a variable argument
> list.  Libtiff 3.8.0 is *not* binary compatible with previous
> releases.
>
> The TIFFGetField() documentation does not address these tags.

For such a small change, I would vote for reverting it rather than
introducing a binary incompatibility.  Library ABI changes are a big
deal for distributions, so it would be shame to have to have one for
such a small change.  I doubt many debian applications or libraries
use these tags, but it's certainly possible that some do and likely
that some debian users use them in their own programs.  I was hoping
that the next ABI change would coincide with a library with release
that used full symbol versioning and took advantage of one big chance
to break everything that needs breaking all at once.

Is there a chance that this change will be reverted, or are we stuck
with it?

-- 
Jay Berkenbilt <ejb@ql.org>