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
September 2007

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

2007.09.12 03:28 "bug reporting and state-of-the-project query", by Lee Howard
2007.09.12 05:21 "Re: bug reporting and state-of-the-project query", by Frank Warmerdam
2007.09.12 14:45 "Re: bug reporting and state-of-the-project query", by Bob Friesenhahn
2007.09.13 05:14 "Re: bug reporting and state-of-the-project query", by Lee Howard
2007.09.13 13:29 "Re: bug reporting and state-of-the-project query", by Frank Warmerdam
2007.09.13 14:29 "Re: bug reporting and state-of-the-project query", by Bob Friesenhahn
2007.09.13 19:41 "Re: bug reporting and state-of-the-project query", by Lee Howard
2007.09.13 19:53 "Re: bug reporting and state-of-the-project query", by Bob Friesenhahn
2007.09.19 22:02 "Re: bug reporting and state-of-the-project query", by Bob Friesenhahn
2007.09.12 18:43 "Re: bug reporting and state-of-the-project query", by Andrey Kiselev
2007.09.13 18:11 "Re: bug reporting and state-of-the-project query", by Lee Howard
2007.09.13 20:16 "Re: bug reporting and state-of-the-project query", by Frank Warmerdam

2007.09.13 18:11 "Re: bug reporting and state-of-the-project query", by Lee Howard

Andrey Kiselev wrote:

>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...
>>
>> http://bugzilla.remotesensing.org/show_bug.cgi?id=1585
>>    
>>
>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:

     TIFFErrorExt(tif->tif_clientdata, module,
                  "Field \"%s\" with tag %lu is already registered as 
\"%s\"",
                        info[i].field_name,
                        (unsigned int) info[i].field_tag,
                         fip->field_name);

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).

Thanks,

Lee.