tiff2pdf built using Microsoft Visual C++ generates pages out of order

[Shailender Bathula]

Hi


I built tiff2pdf for Windows using instructions at http://www.remotesensing.org/libtiff/build.html

JPEG and ZIP support in nmake.opt are enabled and are linked to static libraries of libjpeg 6b (http://libjpeg.sourceforge.net/) and zlib 1.2.8 (http://www.zlib.net/). I had to build libjpeg and zlib also as I could not find their static libraries for Windows elsewhere.


tiff2pdf built is generating pages out of order for one of our test files 123.tiff (attached). That tiff file is viewable in Windows Photo Viewer and the pages have numbers 1, 2 and 3. The generated pdf is 231.pdf (attached). As you can see the first page is generated at the end instead.


Interestingly, tiff2pdf built on CentOS 6.3 and the one available in Cygwin distribution are generating the PDF correctly (i.e. pages are in order). I tried to copy as many appropriate #defines that are used on the CentOS build in Windows build to eliminate a missing #define problem, without any success. The reason for building tiff2pdf for Windows and not using the one available in Cygwin is to use a static executable instead of a dynamically linked one.


Can anyone spot what the problem could be?


nmake.opt I am using is attached. I am building 4.0.3 release on Windows 7 64 bit using Microsoft Visual C++ 2010 Express.


Thanks

Shailender

[John Brown]

On Tue, 14 Oct 2014 05:09:41 +0000, Shailender Bathula wrote:
>
> Hi
>
>
> I built tiff2pdf for Windows using instructions at
> http://www.remotesensing.org/libtiff/build.html
>
[snip]
 
>
> tiff2pdf built is generating pages out of order for one of our test
> files 123.tiff (attached). That tiff file is viewable in Windows Photo
> Viewer and the pages have numbers 1, 2 and 3. The generated pdf is
> 231.pdf (attached). As you can see the first page is generated at the
> end instead.
>
>
> Interestingly, tiff2pdf built on CentOS 6.3 and the one available in
> Cygwin distribution are generating the PDF correctly (i.e. pages are in
> order).

Unfortunately, I can only offer a "me too!". I built libtiff 4.0.3 using MinGW,
(linking to zlib1.dll, liblzma-5.dll, libjpeg-8.dll, libtif-5.dll all built by myself
with MinGW) and it does the same thing as yours, while my Ubuntu Trusty
14.04 tiff2pdf works as expected.

Regards,
John Brown.

_______________________________________________
Tiff mailing list: ***@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

>>
>> Interestingly, tiff2pdf built on CentOS 6.3 and the one available in
>> Cygwin distribution are generating the PDF correctly (i.e. pages are in
>> order).
>
> Unfortunately, I can only offer a "me too!". I built libtiff 4.0.3 using MinGW,
> (linking to zlib1.dll, liblzma-5.dll, libjpeg-8.dll, libtif-5.dll all built by myself
> with MinGW) and it does the same thing as yours, while my Ubuntu Trusty
> 14.04 tiff2pdf works as expected.

I used 'tiff2pdf' built from libtiff CVS on September 3rd, and Linux
'evince' (PDF viewer) shows the expected sequence 1-2-3.

The TIFF does use page numbers and the page numbers are in ascending
order with the frames (0, 1, 2, of 3).

What PDF viewer is being used when the wrong sequence is shown?

It is important to check if the PDF viewer is re-ordering the PDF
frames based on some PDF metadata in the tiff2pdf output or if
tiff2pdf is somehow outputting the "physical" PDF pages in the wrong
order.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: ***@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Shailender Bathula]

> I used 'tiff2pdf' built from libtiff CVS on September 3rd, and Linux
> 'evince' (PDF viewer) shows the expected sequence 1-2-3.

I built libtiff CVS trunk for Windows today and running the tiff2pdf built over the test file and viewing the generated pdf using 'evince' (for Windows 2.32.0.145) the pages are still out of order.

> What PDF viewer is being used when the wrong sequence is shown?

Adobe Reader X 10.1.12

> It is important to check if the PDF viewer is re-ordering the PDF
> frames based on some PDF metadata in the tiff2pdf output or if
> tiff2pdf is somehow outputting the "physical" PDF pages in the wrong
> order.

Based on the File > Properties windows (screenshots are too big for the mailing list to be attached) of Adobe Reader and Evince for the pdf file generated, I cannot see anything that indicates the viewer is reordering the frames.
Not sure, if there is any other way to find out PDF metadata (did a Google search and most of the results showed this as the way). Let me know if this information is not enough and how I can find out more and I can provide that information.

Thanks
Shailender
_______________________________________________
Tiff mailing list: ***@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[John Brown]

On Tue, 14 Oct 2014 12:56:01 -0500, Bob Friesenhahn wrote:


> It is important to check if the PDF viewer is re-ordering the PDF
> frames based on some PDF metadata in the tiff2pdf output or if
> tiff2pdf is somehow outputting the "physical" PDF pages in the wrong
> order.
>
> Bob
> --

The PDF produced on Windows also shows the page order as 2-3-1 when
viewed in Evince on Linux. I also tried Foxit Reader 7.0.3.916 on Windows,
and the Ghostscript (9.10) that is included with PDF Creator on Windows.

The PDF produced on Linux looks good on Windows in Foxit and Ghostscript.
Please see both attached. The text files contain the output of
`pdftk <filename> dump_data'. I doubt that there is anything helpful in them
though.

Regards,
John Brown.

[Scott Ribe]

On Oct 14, 2014, at 4:42 PM, John Brown <***@hotmail.com> wrote:

> The PDF produced on Windows also shows the page order as 2-3-1 when
> viewed in Evince on Linux. I also tried Foxit Reader 7.0.3.916 on Windows,
> and the Ghostscript (9.10) that is included with PDF Creator on Windows.

Interestingly enough, the "catalog" portions of those two PDFs are identical, so same objects, same order, same pages with same object ids, same page list with same page ids in same order.

So it seems that the only explanation is that the windows version put the actual pages in a different order. Which is very strange.

--
Scott Ribe
***@elevated-dev.com
http://www.elevated-dev.com/
[phone] voice




_______________________________________________
Tiff mailing list: ***@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

On Tue, 14 Oct 2014, Scott Ribe wrote:
>
> Interestingly enough, the "catalog" portions of those two PDFs are
> identical, so same objects, same order, same pages with same object
> ids, same page list with same page ids in same order.
>
> So it seems that the only explanation is that the windows version
> put the actual pages in a different order. Which is very strange.

Very strange indeed. The issue is due to some property of the input
file.

I am able to reproduce the problem by compiling libtiff using the GCC
MinGW compiler under Windows.

If I use GraphicsMagick 'gm convert' or 'tiffcrop' to convert 123.tiff
to a new TIFF file, then the problem does not happen with the new
file.

If I use 'tiffcp' to convert 123.tiff to a new file, then the problem
does still happen.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: ***@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/