我不知道这是Latex
问题还是浏览器问题。所以我先在这里问。
此 MWE
\documentclass[12pt]{article}%
\usepackage{graphicx}
\begin{document}
This is my image
\includegraphics[width=0.5\textwidth]{image}
\end{document}
文件image.pdf
位于同一文件夹中。使用lualatex foo.tex
某些浏览器编译并查看 foo.pdf 时,图像不会显示在屏幕上。
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.
查看在本地 Adobe PDF 阅读器中生成的 PDF,图像显示正常。
但是当我在 Chrome 或 Brave 浏览器中打开相同的 PDF 时,图像不会显示。在 Edge 或 Firefox 浏览器中查看时,图像会显示出来。
这只会影响部分图像,而不会影响全部。
我不知道这是否与 pdf 的生成方式有关lulatex
。我也试过了pdflatex
,没有区别。
我的问题是:这是否与 Latex 生成 PDF 文件的方式有关,或者这是这些浏览器 PDF 阅读器的一个错误?我不知道为什么只有一些图像有这个问题,而其他图像没有。
我把我的网站放在这个文件夹中这里image.pdf 和生成的 foo.pdf 以及 foo.tex
image.pdf 是由 IPE 程序生成的。我从来没有遇到过它的 pdf 文件问题。所以我不知道为什么这个文件在某些浏览器中不显示。
答案1
简短回答:您的 PDF 中的对象嵌套太深,并且不同的查看器对嵌套深度的限制不同。
为了确认/说明问题:您的Chrome PDF 查看器中
foo.pdf
没有显示以下内容:image.pdf
虽然它在其他查看器中运行良好:
正如 David 指出的那样,问题已经存在
image.pdf
,Chrome 无法显示文本:而其他观众则:
问题可能与 PDF 的结构有关,并且
image.pdf
使用foo.pdf
qpdf 或iText RUPS显示 PDF 嵌套很深:一些文本/字体似乎位于最深层,而这些是 Chrome 中不会显示的。
CreationDate
您还可以在文件中搜索类似内容,以查看它包含许多 PDF:/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')
这表明 Chrome 愿意渲染的最大深度较低。我们可以试验一下!
创建simple.pdf
以下内容simple.tex
:
\documentclass{standalone}
\begin{document}
Hello
\end{document}
我们可以尝试递归地包含此 PDF,看看可以走多远。长话短说,您可以在 shell 中编写以下循环来创建 100 个 PDF:
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
这将生成 100 个 PDF,命名test-1.pdf
为test-100.pdf
。例如,这是test-5.pdf
在所有查看器中成功呈现的 PDF:
Chrome 成功显示如下test-30.pdf
:
而当test-31.pdf
它放下最里面的“hello”时:
并且test-32.pdf
它会丢弃最里面的两个,也就是说,它只能渲染最多~30 的深度(根据您如何计算,会偏离 1 或 2):
同时,预览一直正常,直到test-49.pdf
(虽然如果你仔细观察,“Hello”的一部分在底部被截断了 - 但这可能是一个单独的舍入问题):
并且开始下降到test-50.pdf
:
Adobe Acrobat Reader DC 的表现稍好一些,在以下时间段内其性能开始下降test-53.pdf
:
它还说有一个错误:
此页存在错误。Acrobat 可能无法正确显示该页面。请联系创建 PDF 文档的人员以更正此问题。
如果您打开test-100.pdf
,在 Chrome 中您会看到从 70 开始的数字,在预览中看到从 51 开始的数字,在 Acrobat Reader 中看到从 48 开始的数字。
如果你查找PDF 参考版本 1.7,有一个附录 C:实施限制(第 991 页),其中写道:
一般而言,PDF 不会限制文件格式中描述的内容(例如数字、数组、图像等)的大小或数量。但是,在特定处理器和特定操作环境中运行的 PDF 消费者应用程序确实存在此类限制。
并有一个表 C.1,其中说“强烈建议生成 PDF 文件的应用程序保留在这些文件中”。其中一个限制是 q/Q 嵌套深度:
这似乎正是你所达到的极限,尽管所有观众似乎都比这稍微慷慨一些(有些人比其他人更慷慨)。