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
November 2009

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

2009.11.06 04:53 "TIFFDirEntry type moved from tiff.h to tiffiop.h in v4.0", by Lee Howard
2009.11.06 07:55 "Re: TIFFDirEntry type moved from tiff.h to tiffiop.h in v4.0", by Joris Van Damme
2009.11.06 15:16 "Re: TIFFDirEntry type moved from tiff.h to tiffiop.h in v4.0", by Lee Howard
2009.11.06 16:29 "Re: TIFFDirEntry type moved from tiff.h to tiffiop.h in v4.0", by Joris Van Damme
2009.11.07 00:24 "Re: TIFFDirEntry type moved from tiff.h to tiffiop.h in v4.0", by Lee Howard

2009.11.07 00:24 "Re: TIFFDirEntry type moved from tiff.h to tiffiop.h in v4.0", by Lee Howard

Joris Van Damme (AWare Systems) wrote:
> Lee,
>
>> HylaFAX is only using it in one source file:  hfaxd/FileTransfer.c++.
>>
>> http://hylafax.cvs.sourceforge.net/viewvc/*checkout*/hylafax/hylafax/hfaxd/FileTransfer.c%2B%2B
>> 
>>
>>
>> You'll see that it's used in several places.
> From a quick skim through the code, am I correct in assuming this code 
> assembles memory structures to pass to LibTiff as file input, so as to 
> persuade LibTiff in decoding compressed data that comes from other 
> places? Sort-off like wrapping dog medicine in a piece of steak so as 
> to persuade the beast to eat it.

Yes, I think that's correct.

> If so, yes, that would be a place where the old TIFFDirEntry structure 
> had a good purpose. Or maybe not, since structures depend on compiler 
> packing and padding settings, and should actually not be used to 
> encode fixed bit/byte patterns in a future-proof and portable way, I 
> guess.
>
> The easiest way out would probably be to completely ignore that last 
> issue, and define a new, local OldClassTiffDirEntry structure that is 
> completely identical to the old TIFFDirEntry of the old 
> ClassicTIFF-only LibTiff, as you're never going to hit the ClassicTIFF 
> 4 gigabyte boundary in this particular application. Next, do a 
> search&replace on this code file. That should fix it.
>
> That would be a FileTransfer.c local fix, rather then a fix inside 
> LibTiff, but I do feel that is probably most appropriate here.

This works for me.

Thanks,

Lee.