[gdal-dev] Something wrong with writing a big raster into PDF

Rahkonen Jukka (Tike) jukka.rahkonen at mmmtike.fi
Fri Mar 7 14:09:56 PST 2014


Even Rouault wrote:
> 
> Le vendredi 07 mars 2014 21:11:40, Even Rouault a écrit :
> > Le vendredi 07 mars 2014 14:20:13, Rahkonen Jukka (Tike) a écrit :
> > > Hi Even,
> > >
> > > Yes, that way I can perhaps create an all-white PDF map a bit faster
> > > but with no other improvement, unfortunately.
> >
> > I've tried "gdal_translate UM5L.png UM5L.pdf -of pdf" on my Linux
> > workstation and the the following viewers :
> 
> I forgot to mention the "-co TILED=YES" which was actually used and makes a
> dramatic improvement for xpdf & QGIS use cases, compared to not tiling mode.
> 
> > - Adobe Reader 9.4.2 Linux: blank image
> > - Okular, KDE-based PDF viewer, based on poppler library: can display
> > a
> > fit-to- page overview in a few seconds, but not the full resolution
> > image since it tries to allocate a 15360x15360 buffer
> > - Evince, GNOME-based PDF viewer, based on poppler library, uses cairo
> > for
> > display: blank image with error message "cairo context error: out of
> > memory" - xpdf, viewer whose code has been forked to build the poppler
> > library: can display the PDF at full resolution, and in reasonable time.
> > - qgis (based on GDAL PDF driver, and poppler backend) : the initial
> > overview computation is really really slow. Roughly half an hour.
> > Because there's currently no optimization in the GDAL PDF reader to
> > get a lower resolution image. Could potentially be dramatically
> > improved by asking a rendering at lower DPI for overview levels,
> > instead of querying at best DPI and then downsampling. But once that
> > 32x32 overview is computed, if you go to 100% scale and pan, the
> > refresh time is around 1 second after each pan. - command line
> > "rendering" (based on GDAL PDF driver, and poppler backend) :
> > gdal_translate UM5L_tiled.pdf out.tif -co TILED=YES : 1 minute 20 sec
> > (less if you specify a higher value than the default for
> > GDAL_CACHEMAX)
> >
> > I've also tried generating a JPEG2000 compressed PDF and Adore Reader
> > is not happier.
> >
> > Conclusion: most PDF viewers assume that a PDF page can fit in memory
> > and don't use a tiling strategy to display it.
> >
> > Even

I  made some tests too by increasing the output size step by step. For my laptop running Windows 7 54 bit with 8 GB RAM and 32-bit Acrobat Reader XI the first failing pdf was made as
gdal_translate -of png -outsize 80% 80% ul4l.png ul4l_80p.png -co tiled=yes
Input file size is 19200, 19200

Output size is then 15360, 15360.
Acrobat Reader shows an empty map but task manager is listing only a nominal memory consumption of 24 MB for the AcroRd32.exe process. From the Reader file properties menu the page size of the failing one is 5080x5080.
For the till 60% reduced version that shows the map the PDF page size is 4064x4064.

Now I wonder if this is really about too big image or something else. 15360 by 15360 pixels is not extremely much. Is there some secret 200 inch limit hiding in the background? See http://indesignsecrets.com/beware-200-limit-for-pdfs.php. 5080 mm is just above 200 inches.
 
-Jukka Rahkonen-

-Jukka Rahkonen-


More information about the gdal-dev mailing list