Pdf.js: 公式绘制得太大。

创建于 2013-01-23  ·  62评论  ·  资料来源: mozilla/pdf.js

看一下
http://arxiv.org/pdf/0707.3195v1.pdf

从第2页开始,所有公式看起来都太大了,并在其余文本上部分涂上了颜色。 其他pdf查看器正确显示了这一点。

pdf.js就是这样显示页面2的:
wrong

这是evince显示页面2的方式:
right

3-pdf-broken 4-font-conversion 4-os-linux

最有用的评论

如果这样做不合适,我们深表歉意,但是,对于这个错误,我将提供500美元的悬赏。

在ShareLaTeX,我们使用PDF.js来呈现用户LaTeX文档生成的PDF,因此我们的用户可能比普通用户更经常遇到此错误。

我找不到有关为该项目提供漏洞赏金的任何先例或评论,所以我希望没关系。 随时通过[email protected]与我https://www.bountysource.com/或其他任何人想要添加到赏金中的托管方式设置赏金。

所有62条评论

我忘了提:我在Ubuntu Linux上将Firefox 18.0.1和PDF Viewer 0.7.1一起使用。

看起来只影响linux

但是Windows也会在日志中显示错误:
[16:59:53.199]解析“字体大小”的值时出错。 声明已放弃。 @ http://arxiv.org/pdf/0707.3195v1.pdf
[16:59:53.569]解析“字体”的值时出错。 声明已放弃。 @ http://arxiv.org/pdf/0707.3195v1.pdf

@dabbeljuh ,您认为这有关系吗?

@yurydelendik :似乎没有,我使用了步进器,两个警告都显示在第一页上(在左侧设置垂直arXiV-nr时显示第一条警告,在完成页面时显示第二条警告)。

@yurydelendik我想我们可以关闭这个。 我无法在Arch Linux x64,Firefox 22和pdf.js开发上复制该问题。 在Windows 7 x64上也没有问题。

我只是仔细检查了一下。 问题仍然存在于我的机器上。
(Ubuntu Linux 12.04,Firefox 22,Pdf.js 0.8.1)

我可能不知道它可能是在开发pdf.js中修复的。

让我知道您是否要我测试任何内容。

我可能不知道它可能是在开发pdf.js中修复的。
让我知道您是否要我测试任何内容。

@kaymes请尝试在网络查看器中下载并打开文件(通过单击PDF.js工具栏右侧的打开文件按钮): http :
它始终使用最新版本的PDF.js,因此请尝试使用该版本,并查看文件是否正确显示。

我刚刚尝试了在线查看器
http://mozilla.github.io/pdf.js/web/viewer.html。 它仍然呈现错误
所有的牙套都太大了。 那是另一台电脑
但是还有一个运行带有Firefox 22的Ubuntu 12.04的计算机。所以问题可能出在
特定于Linux(甚至是Ubuntu),但至少显示三个
不同的机器。

嗯,很奇怪。 在那种情况下,我想这将是特定于Ubuntu的,因为Arch Linux上没有问题。 每天学习新东西:-)

我只是测试了是否是某些插件的错误。 我开始Firefox
在安全模式下,然后使用在线查看器打开文档。 的
问题仍然存在。 因此可以排除插件。

我又做了一个测试:我直接从Mozilla下载Firefox。 所以
所有的Ubuntu补丁/修改都消失了。 然后我开始了这个
在安全模式下。 问题仍然存在。

我在Ubuntu 13.04上也看到了这一点

[18:42:43.639] "PDF 8d10792f8d2028a66825b6ce6ab5b3c1 [1.4 GPL Ghostscript GIT PRERELEASE 9.05 / dvips(k) 5.95a Copyright 2005 Radical Eye Software] (PDF.js: 0.8.510)

http://mozilla.github.io/pdf.js/web/viewer.html上的最新PDF.js开发版本仍然存在问题

该问题仍然存在(Ubuntu 12.04,FF26)。

selection_012

在基于Ubuntu的Linux Mint下,此错误也可以在Google Chrome 34(和Firefox 32.0a1)中重现,因此这不是Firefox独有的问题。 Opera 12.16渲染正确。

我将在此注释中使用TeX和LaTeX以及数学一词,以便人们可以发现此错误。

这似乎与抗锯齿有关:我在Debian Jessie计算机Firefox 33.0.2中使用gnome 3.14。 在RGB和灰度两种抗锯齿,当选择轻微提示的选项(在Gnome的调整工具),我有同样的问题。 当我更改为任何其他提示选项(“全”,“中”或“无”)时,它的外观应与预期相同。

请注意,在Firefox中,您至少必须刷新选项卡才能看到更改。

对我来说(Arch Linux),如果我使用无限修补的fontconfig / freetype,则会出现此错误。 使用香草包不会显示此错误。

我不知道它是否与补丁程序或补丁程序包附带的配置有关。

可以在Chromium和Firefox中的Ubuntu 14.04中复制。 请注意缩放文档时工件的变化。 我已经在pdf.js中的数十个pdfTeX文档中看到此错误,例如,总和索引也受到影响。

这确实是一个上游问题,尽管我不确定在哪里提交。

我在没有大多数特定于发行版的补丁的情况下重建了Ubuntu 14.04 freetype / fontconfig,但是问题仍然存在。

我还从Ubuntu 15.10安装了最新的freetype / fontconfig,但问题仍然存在。

也许这需要作为上游Firefox(Linux)错误提交? 我只是不确定这是由Firefox还是特定的Linux字体库引起的。

这是一个最小的测试用例:

\documentclass{article}
\begin{document}
$$ \sqrt{\frac{1}{2}} $$
\end{document}

这在Ubuntu和Windows上的呈现方式有所不同:

<style type="text/css">
* { margin:0; padding: 0 }
@font-face { font-family:"g_font_1";src:url(data:font/opentype;base64,T1RUTwAJAIAAAwAQQ0ZGIEG/4oQAAACcAAACWU9TLzJL4jE4AAAC+AAAAGBjbWFwAA0ApQAAA1gAAAAsaGVhZKsnRLAAAAOEAAAANmhoZWEDBvRyAAADvAAAACRobXR4BdwAAAAAA+AAAAAMbWF4cAADUAAAAAPsAAAABm5hbWUiztZPAAAD9AAAAgRwb3N0AAMAAAAABfgAAAAgAQAEBAABAQEOTU5QRUhJK0NNRVgxMAABAQFF+BsA+BwB+B0C+B4D+B8EHgoAH4uLHgoAH4uLDAdzHPRwHAWu+ZgFHQAAAKoPHQAAAAAQHQAAAK8RHQAAABwdAAABYhIABQEBDSAtOkBWZXJzaW9uIDAuMTFTZWUgb3JpZ2luYWwgbm90aWNlTU5QRUhJK0NNRVgxME1OUEVISStDTUVYMTBNZWRpdW0AAAAAAAAAAAADAQEDC62LDhwB9BwAABYOHAPoHABvFhwBYxz3jhUc//8GHP8oHAPqBRz/fRz/MgUc//kc//ccAAAc//4cAAAc//8IHAAAHP/8HAANHP/1HAABHP//CBwARBwAawUcAOcc+88FHAAhHAAAHAADHAAAHAAGHAAaCBwCJhwJHQUcAAIcAAccAAIcAAkcAAAcAAUIHAALHP/4HAAJHP/0Hhz/8BwAABz//Rz/8xz//Rz/8ggOHgoEeW8MCboKuguzkgwMs5IMDYsMDh0AAAAcEwBrAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbAsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLAAAAAAADAiQB9AAFAAACigK7AAAAjAKKArsAAAHfADEBAgAAAAAGAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAqMjEqAAAAcgByAwT0cABkAwQLkAAAAAAAAAAAAa8AAAAAAHIAAwAAAAEAAwABAAAADAAEACAAAAAEAAQAAQAAAHL//wAAAHL///+QAAEAAAAAAAEAAAAAEAAAAAAAXw889QAAA+gAAAAAngt+JwAAAACeC34nAAD0cA//AwQAAAARAAAAAAAAAAAAAQAAAwT0cAAA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAfQAAAPoAAAAAFAAAAMAAAAAABQA9gABAAAAAAAAABAAAAABAAAAAAABAA0AEAABAAAAAAACAAcAHQABAAAAAAADAAgAJAABAAAAAAAEAA0ALAABAAAAAAAFAAwAOQABAAAAAAAGAAAARQABAAAAAAAHAAcARQABAAAAAAAIAAcATAABAAAAAAAJAAcAUwADAAEECQAAACAAWgADAAEECQABABoAegADAAEECQACAA4AlAADAAEECQADABAAogADAAEECQAEABoAsgADAAEECQAFABgAzAADAAEECQAGAAAA5AADAAEECQAHAA4A5AADAAEECQAIAA4A8gADAAEECQAJAA4BAE9yaWdpbmFsIGxpY2VuY2VNTlBFSEkrQ01FWDEwVW5rbm93bnVuaXF1ZUlETU5QRUhJK0NNRVgxMFZlcnNpb24gMC4xMVVua25vd25Vbmtub3duVW5rbm93bgBPAHIAaQBnAGkAbgBhAGwAIABsAGkAYwBlAG4AYwBlAE0ATgBQAEUASABJACsAQwBNAEUAWAAxADAAVQBuAGsAbgBvAHcAbgB1AG4AaQBxAHUAZQBJAEQATQBOAFAARQBIAEkAKwBDAE0ARQBYADEAMABWAGUAcgBzAGkAbwBuACAAMAAuADEAMQBVAG4AawBuAG8AdwBuAFUAbgBrAG4AbwB3AG4AVQBuAGsAbgBvAHcAbgADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA);}
td { border: 1px solid #ccc; width: 9px; height: 10px; }
</style>
<table cellspacing="0" cellpadding="0" style="border-collapse:collapse;empty-cells:show">
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
</table>
<div style='font:16px "g_font_1";position:absolute;top:0;left:0'>r</div>

不要忘记Chrome也受到影响,因此它可能不是Firefox错误。
屏幕截图:(基于Ubuntu的)Linux Mint下的Chrome 44。
zwischenablage03

@jethrogb感谢您向上游提交这么多详细信息! 希望这会尽快解决问题。

Freedesktop专家似乎认为这仍然部分是pdfjs错误。 因此,这里可能仍有一些工作要做。

另外,在此期间,除了放大直到错误消失,是否还有其他简便的解决方法? 我经常使用sharelatex,它似乎内置了pdfjs查看器。

这是pdf.js错误。 简而言之,pdf.js为那些数学符号创建了无效字体。 随后,字体自动暂停会得出错误的结论,从而触发错误的显示。

因此,pdf.js应该修复它们转换pdf字体的方式。

我已经用atom pdf视图扩展遇到了这个问题,就像进一步证明这不是Firefox问题一样。 它的外观截图中原子在PDF.js ,以及它应该如何看

我可以确认Ubuntu 15.10中的Chrome中存在此问题。

现在应该通过安装最新的Freetype库来修复此错误(> = 2.6.2)

不,真正的错误在于pdf.js的从Type 1到OpenType的转换,该转换创建了无效的字形,而AFAIK尚未解决。

哦,我看错了上游错误。 对不起,不好的信息。
顺便说一下,我在两台Debian机器(Jessie和Stretch)上都没有检测到此错误。

同样在这里:完全没有问题!
Arch Linux x86_64和无定形补丁的字体[*],firefox 45.0.2
(铬50.0.2661.75-1也是如此)

[*] cairo-infinality-ultimate 1.14.6-1
fontconfig-infinality-ultimate 2.11.95-4
freetype2-infinality-最终2.6.3-2

如果这样做不合适,我们深表歉意,但是,对于这个错误,我将提供500美元的悬赏。

在ShareLaTeX,我们使用PDF.js来呈现用户LaTeX文档生成的PDF,因此我们的用户可能比普通用户更经常遇到此错误。

我找不到有关为该项目提供漏洞赏金的任何先例或评论,所以我希望没关系。 随时通过[email protected]与我https://www.bountysource.com/或其他任何人想要添加到赏金中的托管方式设置赏金。

顺便说一句:这已在上游以freetype https://bugs.freedesktop.org/show_bug.cgi?id=91829修复。

正如人们一直在说的那样,这与FreeType无关,

这与FreeType无关... pdf.js的Type1到OpenType转换器中存在错误。

实际上,这是与FreeType相关的问题,因为只有此引擎才会遇到此问题。 pdf.js的转换器可能存在问题,这有助于理解为什么会发生这种情况。 不幸的是,上面的链接没有提供详细的解释。 FreeType专家的更多意见将加快此错误的解决速度。

由pdf.js转换的字体文件
PDF中嵌入的原始字体文件

FreeType错误报告中的选择引号:

所涉及的字体在字母“ s”处具有根符号。

字体包含一个cmap,该cmap会将位置r' (not s'(顺便说一句)映射到名为.notdef'. Since the auto-hinter accesses a font not by glyph names but by a Unicode mapping (either a real one or a synthesized), it believes that glyph r'的字形

字体cmap一定不能撒谎!

哦,也可能部分是pdf.js的错,伪造的cmap是从pdf.js而不是原始字体进行编译的。 有人需要验证。

原始文件cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name radicalbigg'位于位置0x72。 FireFox错误报告中的子集“ CMEX10.pfb”文件也具有正确的字形名称。

暂时修复#7482。 如果测试失败,我没有资源对此进行更多研究,但这可能很简单。 pdf中的字体有点奇怪,因为它具有符号字体,但是对于某些符号也具有unicode映射。 通常对于符号字体,如果只有身份unicode映射,我们会将所有字形移至专用区域。

我可以复制#7482至少在第一篇文章所链接的PDF的第二页上为我解决了这个问题。

@brendandahl太好了,谢谢。 我将检查您的补丁是否尽快修复。 可以合并吗? (看起来有些测试失败了?)

可以合并吗? (看起来有些测试失败了?)

这种补丁是可以预期的。 但是,在致电之前,我们需要检查差异。

好进步! 我进行了更广泛的测试,发现了一个复杂问题-该修复程序适用于dvips + ghostscript产生的输出,但不适用于pdftex产生的输出-如果我采用上述测试用例的源,并使用pdflatex进行编译,则输出呈现不正确。

随附的是更详尽的测试用例,其中包括原始0707.3195v1.pdf文件中破碎的方程式之一。

第一个pdf文件直接由pdflatex ,然后相同的输出由latex->dvips->ps2pdf 。 屏幕截图是pdf.js的渲染,其中应用了pull请求-它不能解决pdftex输出的问题,但是可以解决ghostscript转换问题。

推测pdftex将字体嵌入输出中的方式有​​所不同,导致该错误仍然发生?

test-pdftex.pdf-仍然损坏
test-pdftex pdf - google chrome - with fix

test-ps2pdf.pdf-固定
test dvi - test-ps2pdf pdf - google chrome - with fix

原始乳胶源test.tex.txt

@jpallen ,您好,只是想让您知道,当我将编译器切换到XeLatex时,它似乎可以解决Sharelatex上的问题。

我们在ShareLaTeX上做了一些进一步的研究,看起来上面的补丁(https://github.com/mozilla/pdf.js/pull/7482 by @brendandahl)就在正确的位置将角色移至私人使用区域,但并未涵盖所有必要情况。 ps2pdf生成的PDF可以工作,但是pdflatex直接生成的PDF仍然存在此渲染问题。

如果我们天真地将_everything_移至私人使用区域(例如https://github.com/brendandahl/pdf.js/compare/move-non-unicode-glyphs...briangough:put-all-symbolic-chars-in-专用区域),则可以正确呈现。 但是,这只是一个调试示例,因为我认为这不是一个好主意。

在这一点上,我们的知识已达到极限,我们不知道如何识别要放入私人使用区域的正确符号。 那么,我们有什么可以帮助推动这一发展的?

如果我们天真地将所有内容移到私有使用区域(例如brendandahl @ move-non-unicode-glyphs ... briangough:put-all-symbolic-chars-in-private-use-area),那么它将正确呈现。 但是,这只是一个调试示例,因为我认为这不是一个好主意。

如果没有测试上述内容,我怀疑这样做实际上会导致_many_ PDF文件中的渲染效果变差,因为(可能)(基本上)导致某些字体渲染器中的_all_ Symbolic字体禁用提示。 (请注意,即使实际上不是,许多字体也声称是符号字体。)

在这一点上,我们的知识已达到极限,我们不知道如何识别要放入私人使用区域的正确符号。 那么,我们有什么可以帮助推动这一发展的?

由于有问题的情况使用正常的Type1字体,因此我仍然认为正确的解决方案_may_是要确保在以Type1Font_wrap转换Type1字体时,我们提供正确的Charset / Encoding信息。

@jpallen我认为我们需要识别由乳胶生成的字体,这些字体是符号(例如,按名称或创建方式),但是在其他情况下,它们不应被识别。

不将所有字符移入专用区域会给我们带来一些好处,例如,可以在输入控件中使用字体,更好的工具,以及引擎可以丢弃无效的字形或字体并仍然获得可读性强的文本的功能。 因此,了解字形是否为符号是关键。

基于PR#7482的一个初步想法可能是当我们不能相信toUnicode数据正确时,将字符移动到PUA。 例如这样的东西: https :

大! 我已经尝试了Snuf fleupagus:issue-2594中的新补丁,对于我的测试用例和我尝试过的各种pdflatex文档来说,它似乎都很

作为测试,我已经将它部署在www.ShareLaTeX.com上的pdf查看器中的生产环境中,以查看是否今天出现了任何意外问题。

在过去的3周中,我们已经在生产环境中测试了此补丁(https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-2594),它已修复了LaTeX字体渲染问题,我们,没有其他问题出现。 如果可以包含在内,那就太好了。 :+1:

我开始审查#7705,开始怀疑为什么我的原始补丁还不能修复test-pdftex.pdf 。 只是查看字体数据,看起来pdf.js应该将大多数字形从DVFZZA+CMEX10移到专用区域,因为它们中的大多数没有有效的字形名称为unicode值。 例如,有问题的字形(charcode = 110 name ='braceleftBig')之一没有unicode值,但已被映射为'n'。 问题似乎出在我们构建unicode映射时,它正确包含68个带有带有匹配unicode值的字形的值,但是在构建后,我们将所有原始编码值加回去,因此110用'n'填充。

我不太确定这里是正确的解决方法,因为如果我们删除代码以添加回编码值,则我们的文本选择将从https://github.com/mozilla/pdf.js/commit/325f7afcca30c891ec7be06a5178c012a052bd55

也许@Snuffleupagus有一些想法...

_如https://github.com/mozilla/pdf.js/issues/2594#issuecomment -254289210所建议,PR#7705的先前版本包含的解决方案过于简单。

因此,我整理了一个新的(对于我来说,很可能是最终的)修复此问题的方法,可以通过以下方法进行测试: http ://107.21.233.14:8877 / 768d76e3834ac61 / web / viewer.html。
如果当前受此问题影响的人们可以测试PR#7705的最新版本,并报告是否足以解决此问题,则将非常有帮助!

在test-pdftex.pdf上运行良好,我们将在本周尝试将其部署在www.ShareLaTeX.com上的生产

在test-pdftex.pdf上运行良好,我们将在本周尝试将其部署在www.ShareLaTeX.com上的生产

正如在IRC上讨论的那样,请参阅http://logs.glob.uno/?c=mozilla%23pdfjs&s=21+Nov+2016&e=21+Nov+2016#c54315 ,我们希望通过PR#7705向前发展。
@briangough在ShareLaTeX的生产环境中测试补丁是否有任何结果?

如先前在https://github.com/mozilla/pdf.js/issues/2594#issuecomment -259930252中提到的,如果当前受此问题影响的人员可以帮助测试建议的解决方案,那么这将是最有用的,可以使用例如http://107.21.233.14:8877 / 768d76e3834ac61 / web / viewer.html中的预览,并报告是否解决了这些问题!

我们想要降落PR#7705,但我们确实需要在进行修复之前进行确认。

抱歉耽搁了。 补丁程序运行正常-不会有来自我们用户的投诉,谢谢。

由于#Snuffleupagus和@brendandahl而关闭,由#7705确定。

此页面是否有帮助?
0 / 5 - 0 等级