Linux 上的 PDF 查看器“Evince”无法正确显示某些数学符号
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10277418/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
The PDF viewer 'Evince' on Linux can not display some math symbols correctly
提问by Yun Huang
I use Evinceto view PDF files on Ubuntu Linux 10.04. But sometimes the program can not display math symbols correctly.
我使用Evince在 Ubuntu Linux 10.04 上查看 PDF 文件。但有时程序无法正确显示数学符号。
An example. The PDF file can be download from:
一个例子。PDF 文件可从以下网址下载：
See equation (1).
见等式（1）。
On Windows, the equation is correctly displayed by Acrobat Reader:
But on Linux, the \sumis displayed as a solid dot:
在 Windows 上，Acrobat Reader 可以正确显示方程式：
但在 Linux 上，\sum则显示为实心圆点：
I have already installed packages: ttf-symbol-replacement, libpoppler5, poppler-data.
我已经安装了软件包：ttf-symbol-replacement, libpoppler5, poppler-data.
采纳答案by Kurt Pfeifle
The reason why your PDF file doesn't work on all PDF viewers is this:your 'zhang11a.pdf'does not have all fonts embedded. Especially missing is the symbolfont, as you can see from the following list:
您的 PDF 文件不适用于所有 PDF 查看器的原因是：您的“zhang11a.pdf”没有嵌入所有字体。尤其缺少的是symbol字体，您可以从以下列表中看到：
kupfe@abc:~$ pdffonts zhang11a.pdf name type emb sub uni object ID -------------------------------- --------- --- --- --- --------- NXDEKT+CMSY10 Type 1C yes yes yes 11 0 Times-Italic Type 1 no no no 10 0 Times-Bold Type 1 no no no 9 0 Times-Roman Type 1 no no no 8 0 UYBJCW+MSBM10 Type 1C yes yes no 29 0 QEAPRL+CMR10 Type 1C yes yes no 23 0 OBCIBS+CMMI10 Type 1C yes yes yes 25 0 Symbol Type 1 no no no 33 0 OUPZTL+ZapfChancery-MediumItalic Type 1C yes yes no 27 0 CFICWF+CMEX10 Type 1C yes yes no 31 0 XRVDJC+CMMI7 Type 1C yes yes no 56 0 JQSOYL+CMMI10 Type 1C yes yes no 54 0 UWKDHL+CMBX10 Type 1C yes yes no 58 0 AIYCES+CMMI5 Type 1C yes yes no 60 0 SDIKLH+CMEX9 Type 1C yes yes no 72 0 EKRXFC+CMSS10 Type 1C yes yes no 84 0 Courier Type 1 no no no 91 0 Helvetica Type 1 no no no 97 0 UELPFP+CMMI10 Type 1C yes yes no 135 0 VZIXBZ+CMR10 Type 1C yes yes no 133 0
Now if a PDF reader encounters a font that is not embedded it uses a strategy similar to the following. It...
现在，如果 PDF 阅读器遇到未嵌入的字体，它会使用类似于以下的策略。它...
- (1) ....searches the local OS and tries to find a font with a matching type and name in order to use that for rendering the text; if that doesn't succeed, it....
- (2) ....searches the local OS to find a font with a matching name (maybe other font type); if not successfull, it....
- (3) ....searches for an appropriate substitute font (which has font metrics that are close to the metrics of the original font -- original font's metric info should be embedded in the PDF, even if the font file itself isn't); if not successfull, then...
- (4) ....use
Courierto render the text.
- (1) ....搜索本地操作系统并尝试找到具有匹配类型和名称的字体，以便使用它来呈现文本；如果那不成功，它......
- (2) ....搜索本地操作系统以找到具有匹配名称的字体（可能是其他字体类型）；如果不成功，它......
- (3) ....搜索合适的替代字体（其字体规格接近原始字体的规格——原始字体的规格信息应嵌入到 PDF 中，即使字体文件本身不是); 如果不成功，那么...
- (4) ....用于
Courier渲染文本。
My hypothesisfor the root cause of your problem is:
我对您问题的根本原因的假设是：
The glyph for the ∑ character is missing from your
ttf-symbol-replacementfont, or this glyph is found at a different spot in that replacement font's glyph table.
您的
ttf-symbol-replacement字体中缺少 ∑ 字符的字形，或者在该替换字体的字形表中的不同位置找到了该字形。
Hence it is not Evince's fault for not being able to render that file correctly.
因此，无法正确渲染该文件并不是 Evince 的错。
On the other hand, Acrobat Reader does ship with application-embedded instances of Times, Courier, Helveticaand Symbol, so that it can render such PDFs. So AcroRead does not have a problem with this file. (And Evince cannot use such tricks due to the licenses of these fonts...)
另一方面，Acrobat Reader 确实附带了Times、Courier、Helvetica和Symbol 的应用程序嵌入实例，因此它可以呈现此类 PDF。所以AcroRead这个文件没有问题。（由于这些字体的许可，Evince 无法使用这些技巧......）
Mark my words:
If you want foolproofPDF files that can be rendered (and printed) correctly by each and every PDF reader on all types of OS systems, make sure your PDF has embedded all fonts it uses!
记住我的话：
如果您希望所有类型的操作系统系统上的每个 PDF 阅读器都能正确呈现（和打印）万无一失的PDF 文件，请确保您的 PDF 嵌入了它使用的所有字体！
Repairing your zhang11a.pdf
修复你的 zhang11a.pdf
However, it is possible to repair your problematic PDF with the help of Ghostscript. I used this command on a Ubuntu Oneiric system (which uses Ghostscript v9.02) to do this:
但是，可以在 Ghostscript 的帮助下修复有问题的 PDF。我在 Ubuntu Oneiric 系统（使用 Ghostscript v9.02）上使用此命令来执行此操作：
/usr/bin/gs \
-o gs-repaired---zhang11a.pdf \
-dPDFSETTINGS=/prepress \
-sDEVICE=pdfwrite \
zhang11a.pdf
The -dPDFSETTINGS=/prepresspart of the CLI parameters tell Ghostscript to embed all non-embedded fonts.
该-dPDFSETTINGS=/prepress命令行参数的一部分告诉Ghostscript的嵌入所有非嵌入字体。
This is how the embedded-ness' property of the repaired PDF now looks like:
这就是修复后的 PDF 的嵌入性属性现在的样子：
kupfe@abc:~$ pdffonts gs-repaired---zhang11a.pdf name type emb sub uni object ID -------------------------------- --------- --- --- --- --------- AFNVKD+Times-Italic Type 1C yes yes no 12 0 PEQXED+CMSY10 Type 1C yes yes yes 14 0 FYXQNZ+Times-Roman Type 1C yes yes no 8 0 XILTND+Times-Bold Type 1C yes yes no 10 0 HZJMVE+Symbol Type 1C yes yes no 36 0 EGYAWT+CMR10 Type 1C yes yes no 26 0 AQGZYJ+CMMI10 Type 1C yes yes yes 28 0 YJATHO+ZapfChancery-MediumItalic Type 1C yes yes no 30 0 CZXDRN+MSBM10 Type 1C yes yes no 32 0 KTZJPT+CMEX10 Type 1C yes yes no 34 0 NYTDMD+CMMI10 Type 1C yes yes no 58 0 DFQTPB+CMMI7 Type 1C yes yes no 60 0 GXJYGS+CMBX10 Type 1C yes yes no 62 0 QAMUEV+CMMI5 Type 1C yes yes no 64 0 QEWIFQ+CMEX9 Type 1C yes yes no 76 0 KNOSJH+CMSS10 Type 1C yes yes no 88 0 UCHHLK+Courier Type 1C yes yes no 95 0 TWNVND+Helvetica Type 1C yes yes no 102 0 ZDIWNO+CMR10 Type 1C yes yes no 139 0 IGJFUT+CMMI10 Type 1C yes yes no 141 0
I checked how Evince renders the repaired PDF: it is OK now.
我检查了 Evince 如何呈现修复后的 PDF：现在可以了。
Update:
更新：
Martin Schr?der is right in stating that -- according to the ISO PDF standard -- none of the 'Base 14' PDF fonts (which are the 4 'standard', 'italic', 'bold', and 'bold-italic' variations for Helvetica, Times and Courier plus Symbol and Dingbats) needs to be embedded and that all PDF viewers should provide their own means of rendering all glyphs in these fonts even in the case of them not being embedded in the file.
Martin Schr?der 说得对——根据 ISO PDF 标准——没有任何“ Base 14”PDF 字体（即 4 种“标准”、“斜体”、“粗体”和“粗斜体”） ' Helvetica、Times 和 Courier 以及 Symbol 和 Dingbats 的变体）需要嵌入，并且所有 PDF 查看器都应该提供自己的方式来渲染这些字体中的所有字形，即使它们没有嵌入到文件中。
In reality, following this recommendation did lead to many problems in real life (such as one case is on display in this very question): because not all viewers, renderers and automatic PDF processors do reliably render the glyphs for un-embedded fonts. And that's the reason why all current ISO standards for PDF/A (archiving) and PDF/X (blind eXchange) requireto embed allfonts (even the 'Base 14' ones) in PDF files. Otherwise that file is not deemed compliant with the respective standard.
实际上，遵循此建议确实会导致现实生活中的许多问题（例如在这个问题中展示了一个案例）：因为并非所有查看器、渲染器和自动 PDF 处理器都能可靠地渲染未嵌入字体的字形。这就是 PDF/A（归档）和 PDF/X（盲交换）的所有当前 ISO 标准要求在 PDF 文件中嵌入所有字体（甚至是“ Base 14”字体）的原因。否则，该文件将不被视为符合相应标准。
And as my Ghostscript command's result shows: embedding the Symbol font does reliably avoid the ∑ glyph rendering problem for Evince. Even if you consider it an Evince bug (which you rightly can) that it doesn't correctly render the original PDF...
正如我的 Ghostscript 命令的结果所示：嵌入符号字体确实可以避免 Evince 的 ∑ 字形渲染问题。即使您认为它是一个 Evince 错误（您理所当然地可以），它也无法正确呈现原始 PDF...
回答by Reinstate Monica - M. Schr?der
Looks like a bug in the (now two years old) evince in Ubuntu 10.4. Either update your Ubuntu or file a bug with Ubuntu.
看起来像是 Ubuntu 10.4 中（现在已经两年了）evince 中的一个错误。更新您的 Ubuntu 或使用 Ubuntu 提交错误。
