Pdf.js: يتم رسم الصيغ بشكل كبير جدًا.

لقد نسيت أن أذكر: أنا أستخدم PDF Viewer 0.7.1 مع Firefox 18.0.1 على Ubuntu 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 : لا يبدو أنني استخدمت السائر وكلا

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://mozilla.github.io/pdf.js /web/viewer.html.
يستخدم هذا دائمًا أحدث إصدار من PDF.js ، لذا يرجى تجربة ذلك ومعرفة ما إذا تم عرض الملف بشكل صحيح.

لقد جربت للتو المشاهد عبر الإنترنت في
http://mozilla.github.io/pdf.js/web/viewer.html. لا يزال يجعل من الخطأ
مع كل الأقواس جعلها كبيرة جدًا. كان جهاز كمبيوتر آخر
ولكن أيضًا واحد يعمل بنظام التشغيل Ubuntu 12.04 مع Firefox 22. لذلك قد تكون المشكلة
Linux محدد (أو حتى Ubuntu) لكنه يظهر على ثلاثة على الأقل
آلات مختلفة.

هممم ، غريب. في هذه الحالة ، أعتقد أنه سيكون خاصًا بـ Ubuntu ، لأنه لا توجد مشاكل هنا على Arch Linux. تعلم شيء جديد كل يوم :-)

لقد أجريت الاختبار للتو ما إذا كان هذا خطأ أحد الملحق لقد بدأت فايرفوكس
في الوضع الآمن وفتح المستند باستخدام العارض عبر الإنترنت. ال
المشكلة لا تزال قائمة. لذلك يمكن استبعاد الوظائف الإضافية.

وقمت بإجراء اختبار آخر: قمت بتنزيل Firefox مباشرة من Mozilla. وبالتالي
اختفت جميع تصحيحات / تعديلات 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)

هل ما زالت هذه مشكلة في أحدث إصدار من تطوير PDF.js على http://mozilla.github.io/pdf.js/web/viewer.html؟ لا يمكنني إعادة إنتاج هذا على Arch Linux.

لا تزال المشكلة قائمة (Ubuntu 12.04 ، FF26).

ضمن Linux Mint المستند إلى Ubuntu ، يمكن تكرار هذا الخطأ أيضًا مع Google Chrome 34 (و Firefox 32.0a1) ، لذلك فهي ليست مشكلة حصرية في Firefox. بالرغم من ذلك ، يتم عرض Opera 12.16 بشكل صحيح.

سأستخدم الكلمات TeX و LaTeX والرياضيات في هذا التعليق حتى يتمكن الناس من العثور على هذا الخطأ.

يبدو أن هذا مرتبط بمنع التشويش: أستخدم جنوم 3.14 في جهاز Debian Jessie ، Firefox 33.0.2. في كل من تنسيقات RGB و Grayscale ، عند تحديد خيار تلميح طفيف (في Gnome Tweak Tool) ، لدي نفس المشكلة. عندما أقوم بالتغيير إلى أي من خيارات التلميح الأخرى (كامل أو متوسط ​​أو لا شيء) يبدو أنه من المفترض أن يظهر.

لاحظ أنه في Firefox عليك على الأقل تحديث علامة التبويب لرؤية التغيير.

بالنسبة لي (قوس لينكس) يظهر هذا الخطأ إذا كنت تستخدم infinality مصححة fontconfig / راسم FreeType. استخدام حزم الفانيليا لا يظهر هذا الخطأ.

لا أعرف ما إذا كان مرتبطًا بالتصحيحات أو التكوين المشحون مع الحزم المصححة.

يمكن التكاثر في Ubuntu 14.04 في Chromium و Firefox. لاحظ كيف تتغير القطع الأثرية عند قياس المستند. لقد رأيت هذا الخطأ في العشرات من مستندات pdfTeX في pdf.js ، على سبيل المثال ، تتأثر مؤشرات المجموع أيضًا.

يبدو أن هذه مشكلة أولية حقًا ، على الرغم من أنني لست متأكدًا من مكان حفظها.

لقد أعدت بناء Ubuntu 14.04 freetype / fontconfig بدون معظم التصحيحات الخاصة بالتوزيع ، لكن المشكلة استمرت.

لقد قمت أيضًا بتثبيت أحدث freetype / fontconfig من Ubuntu 15.10 ، ومع ذلك استمرت المشكلة.

ربما يجب تقديم هذا باعتباره خطأ المنبع في 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.
لقطة الشاشة: Chrome 44 ضمن Linux Mint (المستندة إلى Ubuntu).

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

jethrogb شكرًا لك على ملء هذا المنبع بالعديد من التفاصيل! نأمل أن يتم حل المشكلة قريبًا.

يبدو أن مستخدمي سطح المكتب الحر استنتجوا أن هذا لا يزال جزئيًا خطأ في pdfjs. لذلك ربما لا يزال هناك بعض العمل الذي يتعين القيام به هنا.

أيضًا ، في هذه الأثناء ، هل هناك أي حلول سهلة بخلاف التكبير حتى يختفي الخطأ؟ أستخدم Sharelatex بشكل متكرر ، والذي يبدو أنه يحتوي على عارض pdfjs مدمج.

إنه خطأ pdf.js. باختصار ، ينشئ pdf.js خطوطًا غير صالحة لتلك الرموز الرياضية. بعد ذلك ، يصل التلميح التلقائي للخط إلى استنتاجات خاطئة تؤدي إلى عرض خاطئ.

وبالتالي ، يجب أن يصلح pdf.js طريقة تحويل خطوط pdf.

لقد واجهت هذه المشكلة مع امتداد عرض atom pdf ، تمامًا كدليل إضافي على أنها ليست مشكلة في Firefox. لقطات شاشة لكيفية ظهورها في atom ، في PDF.js ، وكيف يجب أن تبدو .

يمكنني التأكد من وجود هذه المشكلة في Chrome في Ubuntu 15.10.

يجب الآن إصلاح هذا الخطأ من خلال تثبيت مكتبة Freetype محدثة (> = 2.6.2)

لا ، الخطأ الحقيقي يكمن في تحويل النوع 1 إلى OpenType من pdf.js مما يؤدي إلى إنشاء صور رمزية غير صالحة للخط ، و AFAIK لم يتم إصلاح هذا بعد.

أوه ، لقد أخطأت في قراءة علة المنبع. آسف للمعلومات السيئة.
بالمناسبة ، لم أكتشف هذا الخطأ على جهازي دبيان (Jessie و Stretch).

الشيء نفسه هنا: لا توجد مشاكل على الإطلاق!
Arch Linux x86_64 وعناصر الخط مصححة مع اللانهائية [*] ، فايرفوكس 45.0.2
(نفس الشيء يحدث مع الكروم 50.0.2661.75-1)

[*] القاهرة- اللانهائية- 1.14.6-1
fontconfig-infinality-Ultimate 2.11.95-4
freetype2-infinality-Ultimate 2.6.3-2

أعتذر إذا كان هذا غير مناسب ، لكنني سأقدم مكافأة قدرها 500 دولار مقابل إصلاح هذا الخطأ.

في ShareLaTeX ، نستخدم PDF.js لعرض ملف PDF الذي تم إنتاجه من مستندات LaTeX الخاصة بالمستخدمين ، وبالتالي ربما يواجه المستخدمون هذا الخطأ أكثر من المستخدم العادي.

لم أتمكن من العثور على أي سابقة أو تعليقات بخصوص تقديم مكافأة خطأ لهذا المشروع ، لذلك آمل أن يكون الأمر جيدًا. لا تتردد في الاتصال بي على [email protected]. إذا كنت تفضل ذلك ، فيمكننا إعداد المكافأة في حساب الضمان بشيء مثل https://www.bountysource.com/ ، أو إذا كان أي شخص آخر يرغب في الإضافة إلى المكافأة.

راجع للشغل: تم إصلاح هذا في المنبع في freetype https://bugs.freedesktop.org/show_bug.cgi؟id=91829

هذا ليس له علاقة بـ FreeType ، حيث يستمر الناس في القول وكما تمت مناقشته بدقة في قضية FreeType التي تربطها ، هناك خطأ في محول Type1 إلى OpenType الخاص بـ pdf.js.

هذا لا علاقة له بـ FreeType ... هناك خطأ في محول pdf.js من Type1 إلى OpenType.

في الواقع ، إنها مشكلة متعلقة بـ FreeType لأن هذا المحرك هو الوحيد الذي يواجه المشكلة. قد تكون هناك مشكلة في محول pdf.js ، وسيكون من المفيد فهم سبب حدوث ذلك. لسوء الحظ ، لا يوفر الرابط أعلاه تفسيرات مفصلة. سيؤدي المزيد من المدخلات من خبراء FreeType إلى تسريع حل هذا الخطأ.

ملف خط تم تحويله بواسطة pdf.js
ملف الخط الأصلي المضمن في PDF

علامات اقتباس من تقرير أخطاء FreeType:

يحتوي الخط المعني على علامة جذر عند الحرف 's'.

يحتوي الخط على cmap يقوم بتعيين الموضع 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' موجودة

يجب ألا تقع ملفات cmaps للخطوط على التلميح التلقائي!

أوه ، ربما يكون خطأ pdf.js جزئيًا أيضًا ، ربما يكون cmap الزائف عبارة عن ملف pdf.js ، وليس من الخط الأصلي. شخص ما يحتاج للتحقق.

الملف الأصلي cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name rootbigg 'في الموضع 0x72. يحتوي الملف "CMEX10.pfb" الفرعي في تقرير خطأ FireFox أيضًا على اسم الصورة الرمزية الصحيح.

إصلاح مبدئي في # 7482. ليس لدي موارد للنظر في هذا أكثر إذا فشل الاختبار ، ولكن قد يكون الأمر بسيطًا. الخط في ملف pdf غريب بعض الشيء لأنه يحتوي على خط رمزي ، ولكنه يحتوي أيضًا على تعيينات يونيكود لبعض الرموز. عادة للخطوط الرمزية ، نقوم بنقل كل الحروف الرسومية إلى منطقة الاستخدام الخاص إذا كان هناك فقط تعيين هوية يونيكود.

يمكنني إعادة إنتاج # 7482 لإصلاح المشكلة بالنسبة لي على الأقل في الصفحة الثانية من ملف PDF المرتبط في المنشور الأول.

brendandahl رائع ، شكرًا. سأتحقق لمعرفة ما إذا كان التصحيح الخاص بك يعمل على إصلاحه في أسرع وقت ممكن. هل هي قادرة على الاندماج؟ (يبدو أن بعض الاختبارات فاشلة؟)

هل هي قادرة على الاندماج؟ (يبدو أن بعض الاختبارات فاشلة؟)

هذا متوقع مع هذا النوع من التصحيح. ومع ذلك ، نحتاج إلى فحص الاختلافات قبل إجراء مكالمة.

تقدم جيد! لقد أجريت بعض الاختبارات المكثفة ووجدت تعقيدًا - يعمل الإصلاح للإخراج الذي تم إنتاجه بواسطة dvips + ghostscript ولكن ليس للإخراج الذي تم إنتاجه بواسطة pdftex - إذا أخذت المصدر لحالة الاختبار أعلاه وقمت بتجميعه باستخدام pdflatex ، يتم تقديم الإخراج بشكل غير صحيح .

تم إرفاق حالة اختبار أكثر شمولاً بما في ذلك إحدى المعادلات المعطلة من ملف 0707.3195v1.pdf الأصلي.

يتم إنتاج أول ملف pdf مباشرة بواسطة pdflatex ثم يتم إنتاج نفس الناتج بواسطة latex->dvips->ps2pdf . لقطات الشاشة هي العرض من pdf.js مع تطبيق طلب السحب - فهي لا تحل مشكلة إخراج pdftex ، ولكنها تصلحها لتحويل ghostscript.

من المفترض أن هناك شيئًا مختلفًا حول الطريقة التي يتم بها تضمين الخط في الإخراج بواسطة pdftex والذي يتسبب في استمرار حدوث الخطأ؟

test-pdftex.pdf - لا يزال مكسورًا

test-ps2pdf.pdf - ثابت

اختبار مصدر اللاتكس الأصلي.

مرحبًا jpallen ، أريد فقط أن

لقد قمنا بالمزيد من البحث في هذا الأمر في ShareLaTeX ، ويبدو أن التصحيح أعلاه (https://github.com/mozilla/pdf.js/pull/7482 بواسطةbrendandahl) موجود في الخطوط الصحيحة من حيث نقل الشخصيات إلى منطقة الاستخدام الخاص ، ولكنها لا تغطي جميع الحالات اللازمة. ملفات PDF التي تم إنشاؤها بواسطة عمل ps2pdf ، لكن تلك التي تم إنشاؤها بواسطة pdflatex لا تزال تواجه مشكلة العرض هذه.

إذا انتقلنا بسذاجة _ كل شيء_ إلى منطقة الاستخدام الخاص (على سبيل المثال 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 ، لأنه قد يتسبب (بشكل أساسي) في تعطيل التلميح لجميع الخطوط الرمزية في بعض برامج عرض الخطوط. (لاحظ أن الكثير من الخطوط تدعي أنها رمزية ، حتى وإن لم تكن كذلك في الواقع).

في هذه المرحلة ، تصل معرفتنا إلى الحد الأقصى ولا نعرف كيفية تحديد الرموز الصحيحة لوضعها في منطقة الاستخدام الخاص. إذن ، هل هناك أي شيء يمكننا فعله للمساعدة في المضي قدمًا؟

نظرًا لأن الحالات الإشكالية تستخدم خطوط Type1 العادية ، ما زلت أعتقد أن الحل الصحيح _may_ هو التأكد من أننا نقدم معلومات Charset / Encoding عند تحويل خطوط Type1 في Type1Font_wrap .

jpallen أعتقد أننا بحاجة إلى التعرف على الخطوط التي تم إنشاؤها بواسطة اللاتكس وهذه الخطوط هي رموز (على سبيل المثال بالاسم أو طريقة إنشائها) ، ولكن لن يتم التعرف عليها على هذا النحو في بقية الحالات.

يمنحنا عدم نقل _all_ الأحرف إلى منطقة خاصة بعض المزايا ، على سبيل المثال إمكانية استخدام الخطوط في عناصر التحكم في الإدخال ، وتحسين الأدوات ، وقدرة المحرك على تجاهل الحروف الرسومية أو الخطوط غير الصالحة والحصول على نص يمكن قراءته إلى حد ما. لذا فإن معرفة ما إذا كان الحرف الرسومي هو رمز هو مفتاح هنا.

قد تكون الفكرة المبدئية ، استنادًا إلى PR # 7482 ، هي نقل الأحرف إلى PUA عندما لا نثق في صحة بيانات toUnicode ؛ على سبيل المثال شيء من هذا القبيل: https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus : issue-2594.

عظيم! لقد جربت التصحيح الجديد في Snuf fleupagus: الإصدار 2594 ويبدو أنه يعمل بشكل جيد لحالة الاختبار الخاصة بي ومستندات pdflatex المختلفة التي جربتها. : +1:

كاختبار قمت بنشره في الإنتاج في عارض pdf على www.ShareLaTeX.com ، لمعرفة ما إذا كانت هناك أية مشكلات غير متوقعة تظهر اليوم.

لقد اختبرنا هذا التصحيح (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 ، لكننا نحتاج حقًا إلى تأكيد الإصلاح قبل القيام بذلك.

نأسف على التأخير. التصحيح يعمل بشكل جيد - لا توجد شكاوى من مستخدمينا ، شكرًا لك.

يتم الإغلاق كما تم تحديده بواسطة # 7705 ، بفضل Snuffleupagus وbrendandahl!