[Tex/LaTex] why some images do not show up inside PDF when viewed inside some browsers

graphicspdf

I do not know if this is a Latex issue or browser issue. That is why I am asking here first.

This MWE

\documentclass[12pt]{article}%
\usepackage{graphicx}
\begin{document}

This is my image

\includegraphics[width=0.5\textwidth]{image}
\end{document}

The image.pdf file is in same folder. When compiled using lualatex foo.tex and viewing the foo.pdf inside some browsers, the image do not appear on screen.

lualatex foo.tex
This is LuaTeX, Version 1.10.0 (TeX Live 2019)
 restricted system commands enabled.
(./foo.tex
LaTeX2e <2018-12-01>

luaotfload | main : initialization completed in 0.146 seconds
(/usr/local/texlive/2019/texmf-dist/tex/latex/base/article.cls
Document Class: article 2018/09/03 v1.4i Standard LaTeX document class
(/usr/local/texlive/2019/texmf-dist/tex/latex/base/size12.clo))
(/usr/local/texlive/2019/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/local/texlive/2019/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/local/texlive/2019/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/local/texlive/2019/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/local/texlive/2019/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/local/texlive/2019/texmf-dist/tex/latex/graphics-def/luatex.def)))
(./foo.aux)
(/usr/local/texlive/2019/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/usr/local/texlive/2019/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/usr/local/texlive/2019/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
(/usr/local/texlive/2019/texmf-dist/tex/latex/oberdiek/grfext.sty
(/usr/local/texlive/2019/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
(/usr/local/texlive/2019/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)))
(/usr/local/texlive/2019/texmf-dist/tex/latex/oberdiek/kvoptions.sty
(/usr/local/texlive/2019/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
(/usr/local/texlive/2019/texmf-dist/tex/generic/oberdiek/etexcmds.sty
(/usr/local/texlive/2019/texmf-dist/tex/generic/oberdiek/ifluatex.sty))))
(/usr/local/texlive/2019/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
(/usr/local/texlive/2019/texmf-dist/tex/generic/oberdiek/ifpdf.sty))
(/usr/local/texlive/2019/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
[1{/usr/local/texlive/2019/texmf-var/fonts/map/pdftex/updmap/pdftex.map}<./imag
e.pdf>] (./foo.aux))
 377 words of node memory still in use:
   2 hlist, 1 vlist, 1 rule, 2 glue, 3 kern, 1 glyph, 4 attribute, 44 glue_spec
, 4 attribute_list, 1 write nodes
   avail lists: 2:27,3:6,4:1,5:23,6:2,7:35,9:16,11:1
</usr/local/texlive/2019/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.
otf>
Output written on foo.pdf (1 page, 78909 bytes).
Transcript written on foo.log.

Looking at the pdf generated in local adobe PDF reader, the image shows up OK.

But when I open the same PDF inside Chrome or Brave browsers, the image do not show up. The image shows up when viewed inside Edge or Firefox browsers.

This only affects some images and not all.

I do not know if it has something to do with how the pdf is generated by lulatex. I also tried pdflatex, no difference.

My question is: Is this in any way related to How Latex generated the pdf file, or is this a bug in these browsers PDF readers? I have no idea why only some images have this problem and not others.

I put on my site on this folder here the image.pdf and generated foo.pdf and also foo.tex

The image.pdf was generated from IPE program. I never had problem with its pdf files. So I do not know why this one do not show up in some browsers.

Best Answer

Short answer: Your PDF has objects too deeply nested, and different viewers have different limits for nesting depth.

  • To confirm/illustrate the problem: your foo.pdf does not show the included image.pdf in the Chrome PDF viewer:

    in chrome

  • while it works fine in other viewers:

    in Preview

  • As David pointed out, the problem already exists with image.pdf, where Chrome does not show the text:

    image.pdf in Chrome

  • while other viewers do:

    image.pdf in Preview

  • The problem probably has to do with the structure of the PDF, and opening up your image.pdf (or foo.pdf for that matter) with qpdf or iText RUPS shows that the PDF is deeply nested:

    viewed in RUPS

    Some of the text / fonts seem to be at the deepest layer, and these are what do not show up in Chrome.

    You can also just search for something like CreationDate in the file, to see that it contains many PDFs:

    /CreationDate (D:20191029080119-05'00')
/CreationDate (D:20191029074018-05'00')
/CreationDate (D:20191029073712-05'00')
/CreationDate (D:20191029065739-05'00')
/CreationDate (D:20191029065707-05'00')
/CreationDate (D:20191029065458-05'00')
/CreationDate (D:20191029065024-05'00')
/CreationDate (D:20191029032054-05'00')
/CreationDate (D:20191029031857-05'00')
/CreationDate (D:20191029021955-05'00')
/CreationDate (D:20191029021626-05'00')
/CreationDate (D:20191029021103-05'00')
/CreationDate (D:20191029020932-05'00')
/CreationDate (D:20191027235854-05'00')
/CreationDate (D:20190513215137)
/CreationDate (D:20191029123721-05'00')

  • This suggests that Chrome has a lower max depth it's willing to render. We can experiment!

Create a simple.pdf out of the following simple.tex:

\documentclass{standalone}
\begin{document}
Hello
\end{document}

And we can try to include this PDF recursively and see how far we can go. Long story short, in your shell you can write the following loop to create 100 PDFs:

cp simple.pdf test-0.pdf
for n in {1..100}; do m=$(($n - 1)); echo $m $n; echo -E "\documentclass{standalone} \usepackage{graphicx} \begin{document} $n [\includegraphics{test-$m}] $n \end{document}" > test-$n.tex; pdflatex test-$n.tex; done

This results in 100 PDFs named test-1.pdf to test-100.pdf. For example this is test-5.pdf which is rendered successfully in all viewers:

test-5, Chrome

This is Chrome successfully displaying test-30.pdf:

enter image description here

while at test-31.pdf it drops the innermost “hello”:

test-31, Chrome

and at test-32.pdf it drops two of the innermost ones, i.e. it only renders up to a depth of ~30 (off by 1 or 2 depending on how you count):

test-32, Chrome

Meanwhile, Preview is fine until test-49.pdf (although if you look closely, part of the "Hello" is cut off at the bottom — but that may be a separate rounding issue):

test-49, Preview

and it starts dropping at test-50.pdf:

test-50, Preview

Adobe Acrobat Reader DC does a tiny bit better, as it starts dropping at test-53.pdf:

test-53, Acrobat Reader

It also says there's an error:

An error exists on this page. Acrobat may not display the page correctly. Please contact the person who created the PDF document to correct the problem.

If you open test-100.pdf, in Chrome you can see numbers starting at 70, in Preview starting at 51, and in Acrobat Reader starting at 48.

If you look up the PDF reference version 1.7, there's an Appendix C: Implementation Limits (page 991), which says:

In general, PDF does not restrict the size or quantity of things described in the file format, such as numbers, arrays, images, and so on. However, a PDF consumer application running on a particular processor and in a particular operating environment does have such limits.

and has a table C.1 about which it says “applications producing PDF files are strongly advised to remain within them”. One of the limits is on q/Q nesting depth:

q/Q limit

This seems to be exactly the limit you're hitting, though all viewers seem to be slightly more generous (some more than others) than that.

Related Question