2007.09.13 18:11 "Re: [Tiff] bug reporting and state-of-the-project query", by Lee Howard
On Tue, Sep 11, 2007 at 08:28:14PM -0700, Lee Howard wrote:
I just filed a bug report for 3.9.0beta here regarding tiff2pdf...
I am encouraging users to try out 3.9.0 branch and report any possible problems via Bugzilla
The crux of the problem illustrated in the above-mentioned bug report appears to be the inability of libtiff/tif_dirinfo.c _TIFFMergeFieldInfo to actually merge two arrays containing identical tags. I changed the error message there to read:
"Field \"%s\" with tag %lu is already registered as
(unsigned int) info[i].field_tag,
And then the run-time error reads thus:
_TIFFMergeFieldInfo: Field "SubfileType" with tag 254 is already registered as "SubfileType".
I'm not exactly sure what changed between 3.8.2 and 3.9.0beta to cause this, but what tools/tiff2pdf.c is it's trying to count the number of pages first by calling TIFFSetDirectory, then TIFFGetField for TIFFTAG_SUBFILETYPE in each directory, and then moving on to the next directory with TIFFSetDirectory again, and the TIFFFieldInfo for the first directory persists as we read the second directory, and that's where the _TIFFMergeFieldInfo fails.
From what I understand of the API tools/tiff2pdf.c is not doing
anything incorrect. It seems to be that something new developed in the underlying library functionality that now prevents _TIFFMergeFieldInfo from actually merging the two arrays.
I've tried a few different approaches to fixing the matter... but my problem is that I don't have a requisite understanding of the 3.8.2-to-3.9.0beta changes to feel confident that whatever fix I employ wouldn't break what those changes were trying to accomplish.
Your assistance would be appreciated. It's not an urgent matter for me, but I do not wish to see 3.9.0 release with these kinds of problems as inevitably it will come back to haunt me as my customers with future 3.9.0-using distributions are going to want tiff2pdf to function... at which point I'll have to make a decision on whether to fix the problem as best I can and ignore the collateral damage, or downgrade them to 3.7.2 (which is what I've been doing to many of my 3.8.2-using customers to-date).