Output is rubbish when compiled with libtiff support

[disciple]

Hi,
I've found that tesseract (2.01 - I had some compilation problem with
2.03 :( ) works well if I disable libtiff support, but otherwise:
1. It doesn't work at all for the extra files that libtiff support
should enable it to handle.
2. It outputs rubbish (maybe 50% correct) for uncompressed tiffs.
This seems to have been a problem for a long time - I saw reports of
this on the old forum (or maybe the bugtracker) at SF, along with a
rumour that an updated version of libtiff would work, and other
reports that the rumour was false.

Does tesseract actually work for anybody without disabling libtiff?
If not, why is libtiff support enabled by default? But looking at
other messages, it sounds like it does work for some of you, so does
anybody know how to make it work?
If it IS just that I need an updated libtiff, why doesn't configure
check for a version of libtiff that will actually work?

Thanks.

BTW I'm running an older version of Puppy Linux if that matters.

[Ray Smith]

There is a long-standing bug I just found with the tiff file I/O using libtiff. Don't give it color images. They must be 8 bit gr[ae]y or binary.
There is also a bug with the uncompressed tiff reader that is built in. It doesn't take 32 bit tiff. These problems will be fixed in 2.04.
Ray.

[disciple]

Great.
Hopefully I'll have more success compiling it than 2.03 :). Should I
be having another go and posting the point where make failed for me?

On Sep 24, 3:56 pm, "Ray Smith" <theraysm...@gmail.com> wrote:
> There is a long-standing bug I just found with the tiff file I/O using
> libtiff. Don't give it color images. They must be 8 bit gr[ae]y or binary.
> There is also a bug with the uncompressed tiff reader that is built in. It
> doesn't take 32 bit tiff. These problems will be fixed in 2.04.
> Ray.
>

[Ray Smith]

Yes, that would help, as there is no way of fixing it otherwise.
Ray.