# why some images do not show up inside PDF when viewed inside some browsers?

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
) (/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.

• I can confirm that the image does not show up when viewing your foo.pdf in Chrome browser, though it shows up in most other PDF viewers. Interesting. – ShreevatsaR Oct 30 '19 at 18:32
• your image.pdf shows the lines but no text in chrome, but works in firefox, edge, acrobat and xpdf. It is probably worth submitting that as a chrome bug report, see what they say. If the browser can not display the original image it is not likely to display it included in a document. – David Carlisle Oct 30 '19 at 20:44
• My (blind) guess is that Chrome PDF viewer has some max depth it will follow PDF object resources to (like a depth of 50 or 64 or something), and as you nest things more and more deeply, things fall off that limit and don't get rendered. – ShreevatsaR Oct 30 '19 at 23:13
• @ShreevatsaR So why does it not display correctly when viewed on its own? (See David's comment.) – cfr Oct 31 '19 at 0:47
• I've had problems with Metapost images not displaying or displaying incorrectly in chromium. I don't know how IPE does things, so no idea if that might be related. (The images are converted to PDF on-the-fly in my case, using the usual graphicx configuration.) – cfr Oct 31 '19 at 0:49

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:

• while it works fine in other viewers:

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

• while other viewers do:

• 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:

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:

This is Chrome successfully displaying test-30.pdf:

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

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):

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):

and it starts dropping at test-50.pdf:

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

It also says there's an error:

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:

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.

• Does this imply a bug in the tool that created image.pdf? I believe pdfcrop may be the culprit. – Anush Nov 1 '19 at 7:51
• @Anush I'm not sure how image.pdf got so nested. I can imagine pdfcrop adding one level of nesting, but not so many. – ShreevatsaR Nov 1 '19 at 18:06