Forum moved here!

Home / PDF with one image displays only a blank page


It is one, CCITT encoded image. but it is a bit large… 70880 x 19866 (118" by 33" @600dpi). It shows the correct viewport, but only blank.

I used pdftk to burst the original pdf, and it was able to process it fine.

Acrobat shows it with difficulty.

The PDFCandy website [Moderator note: Beware reputation] extracted the image fine.

pdfium also does not handle this pdf:


Unfortunatly MuPdf reports “Image is too wide”, 2380 mm rotated !! (and no idea yet why that does not equal 118" but agrees more with 93.6" as seen by foxit) so unlikely to be fixed in SumatraPDF unless Artifex MuPDF fixes that via a bugreport at
pdfcandy is generally a front end to Debenu/Foxit and Imagemagick converters so may be worth using those directly to convert the file first.

after extraction by pdfcandy the image shows as File: problem_1476395011.tif
File Size: 6.3 MB (6,609,674 Bytes)
Number of Pages: 1
Page Size: 1,875.37 x 525.62 cm
which is based on the native assumption of 96 dpi
converted to image we can see it is unusually wide
trimmed its 56040 x 19819 Pixels
and now we can see why it is a BAD idea to convert vectors to mono pixels (each single line or tone is spilt into hundreds and thousands of fragments)


For my dayjob I get complaints from customers when the software we provide can not handle these large files sometimes. But this one is a bit excessive :wink: and I was happy to find it as I can not provide real customer data. Flattening of an image like this is sadly not uncommon in my field as these large images present faster in most cases and if it did not have so much dithering it could even be smaller. most end users of these documents are not informed of the pro’s and cons, and then demand convenience.

The size I mentioned came from the size of the internal image (19866/600 = 33" , 70880/600 = 118") but you are right, the pagesize is as you claim; Odd.

The aspect ratio and size of this image is not strange though. We regularly process these documents at a lower resolution, but in full colour. I was just sad that Sumatra does not always show the content. I hope someone can fix it.

Sorry for sending you to a bad site, I just wanted to do some tests to see the pdf was not corrupt in any way, and as the image is already in the public domain I did not check which site I used.


My day job involves producing/checking and all to often rejecting or re-educating users, that whats convenient for the one author may be detrimental to dozens or more users productivity.
But then I get paid for all those delays so no problems :slight_smile:

It is a case of ensuring the output matches the users needs

  1. avoid compresion its seconds to compress but man years to decompress
  2. decide what the target use is, if its printing use a different format than for viewing. if its for both consider two outputs.
  1. With the standards we must try to obtain a full colour A4 is somewhere around 1.2Mb. We already have to compromise to 800K, and still the customer is complaining about file size :wink:
    The trouble is that the practical hard- and software stack is just not available at a decent price point. And as the people making the real decisions do not really understand there is no market.
  2. I know, but we need to make it work for four opposing forces at the same time (convenience, quality, storage, price) so compromise is key.

In the meantime I tried to open our problem file with Ghostscript AGPL 9.53.3 x64 and when I open the pdf in gswin64 it shows the image fast but a bit low res.
I normally do not use gswin to show my pdf’s so i’m not sure if this is a good test, But it seems to parse it fine.


I sympathise that customers often push for more, when selling scanning solutions it was difficult to assure that for many cases 150 dpi was usually good allround setting fo printing rolls of wallpaper for pasting on ceilings (who’s going to climb on a ladder to look closer?) its only archival / QA use where it’s in-frequently used that often needs 600 dpi or more

Artifex (writers of Ghostscript / MuPDF code) are (for roughly 32 years) a competitor to Adobe but Adobe use Artifex code to provide android PDF support

There have been multiple GhostScript “viewers” over the years but GS is primarily targeted towards PCL/PDL/(E)PS printing and MuPDF leans towards ePub/PDF/XPS viewing. Both have conversion features that overlap some voids.

MuPDF is very ComandLine rather than GUI orientated, but their -GL variant is a workable viewer, that benefits much from SumatraPDF’s keyboard shortcuts and minimal Interface

It was a struggle to keep the old GSview(er) stable so as to play with the settings but when exported via MS print to pdf it raised the question, that since these drawings are clearly just part of a larger set why not just use cut lines at an easier / more conventional size like B0=39.4 x 55.7, however I often handle much bigger layouts that represent miles at a time so 4 or 5 xA1 horizontal (4-5 yards on paper) is a common size but plotted as vectors the files are easy to handle even in 3D