Pdf.js: 数式が大きすぎます。

言及するのを忘れました：UbuntuLinux上のFirefox18.0.1でPDFViewer0.7.1を使用しています。

Linuxにのみ影響するようです

ただし、Windowsはログにもエラーを表示します。
[16：59：53.199] 'font-size'の値の解析中にエラーが発生しました。 宣言は取り下げられました。 @ http://arxiv.org/pdf/0707.3195v1.pdf
[16：59：53.569]「font」の値の解析中にエラーが発生しました。 宣言は取り下げられました。 @ http://arxiv.org/pdf/0707.3195v1.pdf

@dabbeljuh 、あなたはそれが関連していると思いますか？

@yurydelendik ：そうではないようです、私はステッパーを使用しました、そして両方の警告は最初のページに表示されます（最初は左側に垂直arXiV-nrを設定するとき、2番目はページを終了するとき）。

@yurydelendikこれを閉じることができると思います。 Arch Linux x64、Firefox 22、pdf.jsの開発で問題を再現できません。 また、Windows 7x64でも問題はありません。

私はちょうど再確認しました。 問題はまだ私のマシンで解決しません。
（Ubuntu Linux 12.04、Firefox 22、Pdf.js 0.8.1の両方）

たぶんそれは開発pdf.jsで修正されているかもしれませんが、私にはわかりません。

何かテストしてほしい場合はお知らせください。

たぶんそれは開発pdf.jsで修正されているかもしれませんが、私にはわかりません。
何かテストしてほしい場合はお知らせください。

@kaymesファイルをダウンロードして、Webビューアで（PDF.jsツールバーの右側にある[ファイルを開く]ボタンをクリックして）開いてみてください： http ：//mozilla.github.io/pdf.js
これは常に最新バージョンのPDF.jsを使用するため、それを試して、ファイルが正しく表示されるかどうかを確認してください。

私はちょうどでオンラインビューアを試しました
http://mozilla.github.io/pdf.js/web/viewer.html。 それでも間違ってレンダリングされます
すべての中括弧が大きくなりすぎています。 それはまた別のコンピューターでした
Firefox22でUbuntu12.04を実行しているものもあります。
Linux固有（またはUbuntu）ですが、少なくとも3つで表示されます
別のマシン。

うーん、変だ。 その場合、Arch Linuxでは問題がないので、Ubuntu固有だと思います。 毎日何か新しいことを学ぶ:-)

アドオンのせいなのかテストをしました。 Firefoxを始めました
セーフモードで、オンラインビューアを使用してドキュメントを開きました。 ザ・
問題はまだ解決しません。 したがって、アドオンを除外することができます。

そしてもう1つテストを行いました。MozillaからFirefoxを直接ダウンロードしました。 そう
すべてのUbuntuパッチ/変更はなくなりました。 そして、私はこれを始めました
セーフモードで。 問題はまだあります。

これはUbuntu13.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）。

UbuntuベースのLinuxMintでは、このバグはGoogle Chrome 34（およびFirefox 32.0a1）でも再現可能であるため、Firefoxの排他的な問題ではありません。 ただし、Opera12.16は正しくレンダリングされます。

このコメントでは、TeXとLaTeXという単語と数学を使用して、人々がこのバグを見つけられるようにします。

これはアンチエイリアスに関連しているようです。私はDebianJessieマシンのFirefox33.0.2でgnome3.14を使用しています。 RGBとグレースケールのアンチエイリアシングの両方で、（Gnome Tweak Toolで）Slight Hintingのオプションを選択すると、同じ問題が発生します。 他のヒントオプション（フル、ミディアム、またはなし）のいずれかに変更すると、意図したとおりに表示されます。

Firefoxでは、変更を確認するには、少なくともタブを更新する必要があることに注意してください。

私（Arch Linux）の場合、このバグは、無限パッチを適用したfontconfig / freetypeを使用すると

それがパッチに関連しているのか、パッチが適用されたパッケージに付属している構成に関連しているのかわかりません。

ChromiumおよびFirefoxのUbuntu14.04で再現できます。 ドキュメントを拡大縮小すると、アーティファクトがどのように変化するかに注意してください。 このバグは、pdf.jsの数十のpdfTeXドキュメントで見られました。たとえば、合計インデックスも影響を受けます。

どこに提出すればよいかわかりませんが、これは本当に上流の問題のようです。

ディストリビューション固有のパッチをほとんど使用せずにUbuntu14.04 freetype / fontconfigを再構築しましたが、問題は解決しません。

Ubuntu15.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>

https://bugzilla.mozilla.org/show_bug.cgi?id=1200077

Chromeも影響を受けるため、Firefoxのバグではない可能性が高いことを忘れないでください。
スクリーンショット：（Ubuntuベースの）LinuxMintでのChrome44。

https://bugs.freedesktop.org/show_bug.cgi?id=91829

@jethrogb非常に多くの詳細をアップストリームに提出していただき、ありがとうございます。 うまくいけば、これで問題がすぐに修正されるでしょう。

freedesktopの人々は、これはまだ部分的にpdfjsのバグであると結論付けているようです。 したがって、おそらくここでやるべきことがまだいくつかあります。

また、それまでの間、バグが消えるまでズームインする以外の簡単な回避策はありますか？ 私はsharelatexを頻繁に使用していますが、これにはpdfjsビューアが組み込まれているようです。

これはpdf.jsの障害です。 一言で言えば、pdf.jsはそれらの数学記号に対して無効なフォントを作成します。 その後、フォントの自動ヒンターが間違った結論に達し、間違った表示がトリガーされます。

したがって、pdf.jsは、pdfフォントが変換される方法を修正する必要があります。

Firefoxの問題ではないことをさらに証明するのと同じように、 atompdfビュー拡張機能でこの問題に遭遇しました。 それがどのように見えるのスクリーンショット原子で、 PDF.jsで、そしてそれがどのように見えるべきか。

この問題がUbuntu15.10のChromeに存在することを確認できます。

このバグは、最新のFreetypeライブラリがインストールされた状態で修正されるはずです（> = 2.6.2）

いいえ、本当のバグはpdf.jsのType 1からOpenTypeへの変換にあり、無効なフォントグリフが作成されますが、これはまだ修正されていません。

ああ、私は上流のバグを読み間違えました。 悪い情報でごめんなさい。
ちなみに、私は両方の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-ultimate 2.6.3-2

これが不適切な場合はお詫びしますが、このバグが修正されたことに対して500ドルの報奨金を提供します。

ShareLaTeXでは、PDF.jsを使用してユーザーのLaTeXドキュメントから生成されたPDFをレンダリングするため、ユーザーはおそらく平均的なユーザーよりもこのバグに頻繁に遭遇します。

このプロジェクトにバグバウンティを提供することに関する前例やコメントは見つかりませんでしたので、大丈夫だと思います。 [email protected]までお気軽にご連絡くださいhttps： //www.bountysource.com/のようなものを使用して、または他の誰かが報奨金に追加したい場合は、エスクローに報奨金を設定でき

ところで：これはfreetypehttps ： //bugs.freedesktop.org/show_bug.cgi

これはFreeTypeとは何の関係もありません。人々が言い続けているように、リンクするFreeTypeの問題で徹底的に議論されているように、pdf.jsのType1からOpenTypeへのコンバーターにバグがあります。

これはFreeTypeとは何の関係もありません... pdf.jsのType1からOpenTypeへのコンバーターにバグがあります。

実際には、このエンジンのみが問題を経験するため、FreeTypeに関連する問題です。 pdf.jsのコンバーターに問題がある可能性があり、なぜそれが起こっているのかを理解するのに役立ちます。 残念ながら、上記のリンクは詳細な説明を提供していません。 FreeTypeの専門家からのより多くの入力は、このバグ解決をスピードアップするでしょう。

pdf.jsで変換されたフォントファイル
PDFに埋め込まれた元のフォントファイル

FreeTypeバグレポートからの選択の引用：

問題のフォントには、文字「s」にルート記号があります。

フォントには、位置r' (not s '、BTW）を.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が含まれています。

フォントcmapは自動ヒンターに嘘をついてはいけません！

ああ、それはおそらくpdf.jsのせいでもあります。おそらく、偽のcmapが元のフォントからではなくpdf.jsからコンピングしているのでしょう。 誰かが確認する必要があります。

位置0x72の元のファイルcmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name radicalbigg '。 FireFoxバグレポートのサブセット化された `CMEX10.pfb 'ファイルにも正しいグリフ名があります。

＃7482の暫定修正。 テストが失敗した場合にこれを詳しく調べるためのリソースはありませんが、簡単な場合があります。 PDFのフォントは、シンボリックフォントであるため少し奇妙ですが、一部のシンボルのUnicodeマッピングもあります。 通常、シンボリックフォントの場合、IDユニコードマッピングしかない場合は、すべてのグリフを私用領域に移動します。

少なくとも最初の投稿でリンクされているPDFの2ページ目で、＃7482の問題を再現できます。

@brendandahl素晴らしい、ありがとう。 パッチでできるだけ早く修正されるかどうかを確認します。 マージできますか？ （いくつかのテストが失敗しているように見えますか？）

マージできますか？ （いくつかのテストが失敗しているように見えますか？）

これは、この種のパッチで予想されます。 ただし、電話をかける前に違いを調べる必要があります。

順調です！ 私はいくつかのより広範なテストを行い、複雑さを発見しました-修正はdvips + ghostscriptによって生成された出力に対しては機能しますが、pdftexによって生成された出力に対しては機能しません-上記のテストケースのソースを取得し、pdflatexでコンパイルすると、出力が正しくレンダリングされません。

添付されているのは、元の0707.3195v1.pdfファイルの壊れた方程式の1つを含む、より徹底的なテストケースです。

最初のPDFファイルはpdflatexによって直接生成され、次に同じ出力がlatex->dvips->ps2pdfによって生成されます。 スクリーンショットは、プルリクエストが適用されたpdf.jsからのレンダリングです。pdftex出力の問題は解決されませんが、ghostscript変換用に修正されています。

おそらく、フォントがpdftexによる出力に埋め込まれる方法に何か違いがあり、バグがまだ発生しているのでしょうか。

test-pdftex.pdf-まだ壊れている

test-ps2pdf.pdf-修正済み

オリジナルのラテックスソース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- private-use-area）の場合、正しくレンダリングされます。 ただし、これは良い考えではないと思うので、これは単なるデバッグの例です。

この時点で、私たちの知識は限界に達し、私用領域に配置する正しい記号を特定する方法がわかりません。 では、これを前進させるために私たちにできることはありますか？

すべてを私用領域（例：brendandahl @ move-non-unicode-glyphs ... briangough：put-all-symbolic-chars-in-private-use-area）に単純に移動すると、正しくレンダリングされます。 ただし、これは良い考えではないと思うので、これは単なるデバッグの例です。

上記をテストしなかった場合、特定のフォントレンダラーで_all_シンボリックフォントのヒントが（基本的に）無効になる可能性があるため、実際には_many_PDFファイルのレンダリングが悪化する可能性があると思います。 （実際にはそうではない場合でも、多くのフォントがシンボリックであると主張していることに注意してください。）

この時点で、私たちの知識は限界に達し、私用領域に配置する正しい記号を特定する方法がわかりません。 では、これを前進させるために私たちにできることはありますか？

問題のあるケースでは通常のType1フォントを使用しているので、正しい解決策は、Type1フォントをType1Font_wrapに変換するときに、適切なCharset / Encoding情報を確実に提供することだと思います。

@jpallenラテックスによって生成されたフォントを認識する必要があると思います。それらのフォントは記号です（名前や作成方法など）が、それ以外の場合は認識されません。

_all_文字をプライベート領域に移動しないことで、いくつかの利点が得られます。たとえば、入力コントロールでフォントを使用できること、インストルメンテーションが改善されていること、エンジンが無効なグリフやフォントを破棄してもある程度読みやすいテキストを取得できることなどです。 したがって、グリフがシンボルであるかどうかを知ることがここでの鍵となります。

PR＃7482に基づく暫定的なアイデアは、 toUnicodeデータが正しいと信頼できない場合に、文字をPUAに移動することである可能性があります。 例： https ：

すごい！ Snuf fleupagus：issue-2594で新しいパッチを試しましたが、テストケースや試したさまざまなpdflatexドキュメントでうまく機能しているようです。 ：+1：

テストとして、 www.ShareLaTeX.comのPDFビューアで

このパッチ（https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-2594）を過去3週間にわたって本番環境でテストし、LaTeXフォントのレンダリングの問題を修正しました。他の問題は発生していません。 おかげでそれが含まれることができれば素晴らしいでしょう。 ：+1：

私は＃7705のレビューを開始し、なぜ元のパッチでもtest-pdftex.pdf修正されなかったのか疑問に思い始めました。 フォントデータを見るだけで、pdf.jsは、グリフの大部分をDVFZZA+CMEX10から私用領域に移動する必要があるように見えます。これらのほとんどは、Unicode値に対する有効なグリフ名を持っていないためです。 たとえば、問題のあるグリフの1つ（charcode = 110 name = 'braceleftBig'）にはユニコード値がありませんが、 'n'にマップされていました。 この問題は、Unicodeマップを作成するときに発生するようです。これには、Unicode値が一致するグリフを含む68個の値が正しく含まれていますが、作成後に元のエンコード値をすべて追加し直すため、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を参照して
@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で修正された