Pdf.js: Rumus digambar terlalu besar.

Dibuat pada 23 Jan 2013  ·  62Komentar  ·  Sumber: mozilla/pdf.js

Silahkan lihat
http://arxiv.org/pdf/0707.3195v1.pdf

Dari halaman 2 dan seterusnya, semua rumus tampak terlalu besar dan sebagian dicat di seluruh teks. Penampil pdf lainnya menunjukkan ini dengan benar.

Beginilah pdf.js menampilkan halaman 2:
wrong

Ini adalah bagaimana acara menunjukkan halaman 2:
right

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

Komentar yang paling membantu

Mohon maaf jika ini tidak pantas, tetapi saya akan menawarkan hadiah $ 500 untuk bug ini diperbaiki.

Di ShareLaTeX kami menggunakan PDF.js untuk merender PDF yang dihasilkan dari dokumen LaTeX pengguna, dan pengguna kami mungkin lebih sering menemukan bug ini daripada pengguna biasa.

Saya tidak dapat menemukan preseden atau komentar tentang penawaran bug bounty untuk proyek ini, jadi saya harap tidak apa-apa. Jangan ragu untuk menghubungi saya di [email protected]. Jika Anda mau, kami dapat mengatur bounty dalam escrow dengan sesuatu seperti https://www.bountysource.com/ , atau jika ada orang lain yang ingin menambahkan bounty tersebut.

Semua 62 komentar

Saya lupa menyebutkan: Saya menggunakan PDF Viewer 0.7.1 dengan Firefox 18.0.1 di Ubuntu Linux.

Sepertinya itu hanya mempengaruhi linux

Namun Windows juga menampilkan kesalahan di log:
[16: 59: 53.199] Kesalahan dalam nilai parsing untuk 'font-size'. Deklarasi dibatalkan. @ http://arxiv.org/pdf/0707.3195v1.pdf
[16: 59: 53.569] Kesalahan dalam nilai parsing untuk 'font'. Deklarasi dibatalkan. @ http://arxiv.org/pdf/0707.3195v1.pdf

@dabbeljuh , apakah menurutmu itu ada hubungannya?

@yurydelendik : Sepertinya tidak, saya telah menggunakan stepper dan kedua peringatan muncul di halaman pertama (yang pertama saat menyetel vertikal arXiV-nr di sebelah kiri, yang kedua saat menyelesaikan halaman).

@yurydelendik Saya rasa kita bisa menutup ini. Saya tidak dapat mereplikasi masalah ini pada pengembangan Arch Linux x64, Firefox 22 dan pdf.js. Juga tidak ada masalah pada Windows 7 x64.

Saya baru saja memeriksa ulang. Masalahnya masih ada di mesin saya.
(keduanya Ubuntu Linux 12.04, Firefox 22, Pdf.js 0.8.1)

Mungkin sudah diperbaiki dalam pengembangan pdf.js, saya tidak tahu.

Beri tahu saya jika Anda ingin saya menguji sesuatu.

Mungkin sudah diperbaiki dalam pengembangan pdf.js, saya tidak tahu.
Beri tahu saya jika Anda ingin saya menguji sesuatu.

@kaymes Silakan coba mengunduh file dan membukanya (dengan mengklik tombol buka file, ditempatkan di sisi kanan toolbar PDF.js) di penampil web: http://mozilla.github.io/pdf.js /web/viewer.html.
Ini selalu menggunakan versi terbaru PDF.js, jadi silakan coba dan lihat apakah file ditampilkan dengan benar.

Saya baru saja mencoba penampil online di
http://mozilla.github.io/pdf.js/web/viewer.html. Itu masih salah
dengan semua kawat gigi yang dirender terlalu besar. Itu adalah komputer lain
tetapi juga menjalankan Ubuntu 12.04 dengan Firefox 22. Jadi masalahnya mungkin
Khusus Linux (atau bahkan Ubuntu) tetapi setidaknya ditampilkan pada tiga
mesin yang berbeda.

Hmm, aneh. Dalam hal ini, saya kira itu akan menjadi khusus Ubuntu, karena tidak ada masalah di sini di Arch Linux. Mempelajari sesuatu yang baru setiap hari :-)

Saya baru saja melakukan tes apakah itu kesalahan beberapa addon. Saya memulai firefox
dalam mode aman dan membuka dokumen menggunakan penampil online. Itu
masalah masih berlanjut. Jadi addons bisa dikesampingkan.

Dan saya melakukan satu tes lagi: Saya mengunduh Firefox langsung dari Mozilla. Begitu
semua patch / modifikasi Ubuntu hilang. Dan kemudian saya mulai yang ini
dalam mode aman. Masalahnya masih ada.

Saya melihat ini juga di 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)

Apakah ini masih menjadi masalah dengan versi pengembangan PDF.js terbaru di http://mozilla.github.io/pdf.js/web/viewer.html? Saya tidak dapat mereproduksi ini di Arch Linux.

Masalah masih berlaku (Ubuntu 12.04, FF26).

selection_012

Di bawah Linux Mint berbasis Ubuntu, bug ini juga dapat direkonstruksi dengan Google Chrome 34 (dan Firefox 32.0a1), jadi ini bukan masalah Firefox eksklusif. Opera 12.16 membuatnya benar.

Saya hanya akan menggunakan kata TeX dan LaTeX dan matematika dalam komentar ini sehingga orang dapat menemukan bug ini.

Ini sepertinya terkait dengan antialiasing: Saya menggunakan gnome 3.14 di mesin Debian Jessie, Firefox 33.0.2. Dalam antialiasing RGB dan Grayscale, ketika opsi Slight hinting dipilih (di Gnome Tweak Tool), saya memiliki masalah yang sama. Ketika saya mengubah ke salah satu opsi petunjuk lainnya (Penuh, Sedang atau Tidak Ada) itu terlihat seperti yang dimaksudkan untuk dilihat.

Perhatikan bahwa di Firefox Anda setidaknya harus menyegarkan tab untuk melihat perubahannya.

Bagi saya (Arch Linux) bug ini muncul jika saya menggunakan fontconfig / freetype yang ditambal infinalitas. Menggunakan paket vanilla tidak menunjukkan bug ini.

Saya tidak tahu apakah itu terkait dengan tambalan atau konfigurasi yang dikirimkan dengan paket yang ditambal.

Dapat mereproduksi di Ubuntu 14.04 di Chromium dan Firefox. Perhatikan bagaimana artefak berubah saat menskalakan dokumen. Saya telah melihat bug ini di lusinan dokumen pdfTeX di pdf.js, misalnya, indeks jumlah juga terpengaruh.

Ini benar-benar tampaknya menjadi masalah hulu, meskipun saya tidak yakin di mana harus mengajukannya.

Saya membangun kembali Ubuntu 14.04 freetype / fontconfig tanpa sebagian besar tambalan khusus distribusi, tetapi masalahnya tetap ada.

Saya juga menginstal freetype / fontconfig terbaru dari Ubuntu 15.10, namun masalahnya tetap ada.

Mungkin ini perlu diajukan sebagai bug upstream Firefox (Linux)? Saya hanya tidak yakin apakah itu disebabkan oleh Firefox atau pustaka font Linux tertentu.

Ini kasus percobaan minimal:

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

Ini dirender secara berbeda di Ubuntu dan 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>

Jangan lupa bahwa Chrome juga terpengaruh, jadi sepertinya itu bukan bug Firefox.
Tangkapan layar: Chrome 44 di bawah Linux Mint (berbasis Ubuntu).
zwischenablage03

@jethrogb Terima kasih telah mengajukan ini dengan begitu banyak detail! Semoga masalah ini segera teratasi.

Tampaknya orang-orang freedesktop menyimpulkan bahwa ini masih merupakan bug pdfjs. Jadi mungkin masih ada pekerjaan yang harus dilakukan di sini.

Selain itu, sementara itu, apakah ada solusi mudah selain memperbesar hingga bug hilang? Saya sering menggunakan sharelatex, yang tampaknya memiliki penampil pdfjs built-in.

Ini adalah kesalahan pdf.js. Singkatnya, pdf.js membuat font yang tidak valid untuk simbol matematika tersebut. Selanjutnya, font auto-hinter sampai pada kesimpulan yang salah yang memicu tampilan yang salah.

Jadi, pdf.js harus memperbaiki cara font pdf diubah.

Saya mengalami masalah ini dengan ekstensi tampilan pdf atom , sebagai bukti lebih lanjut bahwa ini bukan masalah Firefox. Tangkapan layar dari tampilannya di atom , di PDF.js , dan bagaimana tampilannya .

Saya dapat mengonfirmasi masalah ini ada di Chrome di Ubuntu 15.10.

Bug ini sekarang harus diperbaiki dengan pustaka Freetype terbaru diinstal (> = 2.6.2)

Tidak, bug sebenarnya ada dalam konversi Tipe 1 ke OpenType dari pdf.js yang membuat glyph font tidak valid, dan AFAIK ini belum diperbaiki.

Oh, saya salah membaca bug upstream. Maaf atas informasi yang buruk.
Omong-omong, saya tidak mendeteksi bug ini di kedua mesin Debian saya (Jessie dan Stretch).

sama di sini: tidak ada masalah sama sekali!
Arch Linux x86_64 dan hal-hal font ditambal dengan infinalitas [*], firefox 45.0.2
(hal yang sama terjadi dengan chromium 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

Mohon maaf jika ini tidak pantas, tetapi saya akan menawarkan hadiah $ 500 untuk bug ini diperbaiki.

Di ShareLaTeX kami menggunakan PDF.js untuk merender PDF yang dihasilkan dari dokumen LaTeX pengguna, dan pengguna kami mungkin lebih sering menemukan bug ini daripada pengguna biasa.

Saya tidak dapat menemukan preseden atau komentar tentang penawaran bug bounty untuk proyek ini, jadi saya harap tidak apa-apa. Jangan ragu untuk menghubungi saya di [email protected]. Jika Anda mau, kami dapat mengatur bounty dalam escrow dengan sesuatu seperti https://www.bountysource.com/ , atau jika ada orang lain yang ingin menambahkan bounty tersebut.

BTW: Ini telah diperbaiki di hulu di freetype https://bugs.freedesktop.org/show_bug.cgi?id=91829

Ini tidak ada hubungannya dengan FreeType, seperti yang terus dikatakan orang dan seperti yang dibahas secara menyeluruh dalam masalah FreeType yang Anda tautkan, ada bug dalam konverter Type1 ke OpenType pdf.js.

Ini tidak ada hubungannya dengan FreeType ... ada bug dalam pengonversi Type1 ke OpenType pdf.js.

Sebenarnya, ini adalah masalah yang terkait dengan FreeType karena hanya mesin ini yang mengalami masalah. Mungkin ada masalah dengan pengonversi pdf.js, dan akan sangat membantu untuk memahami mengapa hal itu terjadi. Sayangnya tautan di atas tidak memberikan penjelasan detailnya. Lebih banyak masukan dari pakar FreeType akan mempercepat resolusi bug ini.

File font yang dikonversi oleh pdf.js
File font asli yang disematkan di PDF

Kutipan pilihan dari laporan bug FreeType:

Font yang dimaksud memiliki tanda root pada huruf 's'.

Font berisi cmap yang memetakan posisi r' (not s ', BTW) ke mesin terbang yang disebut .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' hadir

Font cmaps tidak boleh berbohong kepada auto-hinter!

Oh, itu mungkin sebagian pdf.js juga, mungkin cmap palsu adalah comping dari pdf.js, bukan dari font aslinya. Seseorang perlu memverifikasi.

File asli cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name radikalbigg 'pada posisi 0x72. File `` CMEX10.pfb '' subset dalam laporan bug FireFox juga memiliki nama mesin terbang yang benar.

Perbaikan sementara di # 7482. Saya tidak memiliki sumber daya untuk mempelajari ini lebih lanjut jika pengujian gagal, tetapi ini bisa sederhana. Font di pdf agak aneh karena memiliki font simbolik, tetapi juga memiliki pemetaan unicode untuk beberapa simbol. Biasanya untuk font simbolik kami memindahkan semua mesin terbang ke area penggunaan pribadi jika hanya ada pemetaan unicode identitas.

Saya dapat mereproduksi # 7482 memperbaiki masalah bagi saya setidaknya pada halaman kedua dari PDF yang ditautkan ke dalam posting pertama.

@brendandahl Luar biasa, terima kasih. Saya akan memeriksa untuk melihat apakah tambalan Anda memperbaikinya secepat mungkin. Apakah bisa digabungkan? (Sepertinya beberapa tes gagal?)

Apakah bisa digabungkan? (Sepertinya beberapa tes gagal?)

Itu diharapkan dengan tambalan semacam ini. Namun kita perlu memeriksa perbedaan sebelum kita menelepon.

Perkembangan yang baik! Saya melakukan beberapa pengujian yang lebih ekstensif dan menemukan komplikasi - perbaikan berfungsi untuk output yang dihasilkan oleh dvips + ghostscript tetapi tidak untuk output yang dihasilkan oleh pdftex - jika saya mengambil sumber untuk kasus uji di atas dan mengkompilasinya dengan pdflatex, output tidak ditampilkan dengan benar .

Terlampir adalah kasus uji yang lebih lengkap termasuk salah satu persamaan yang rusak dari file 0707.3195v1.pdf asli.

File pdf pertama diproduksi langsung oleh pdflatex dan kemudian output yang sama dihasilkan oleh latex->dvips->ps2pdf . Tangkapan layar adalah rendering dari pdf.js dengan permintaan tarik yang diterapkan - ini tidak menyelesaikan masalah dengan keluaran pdftex, tetapi memperbaikinya untuk konversi ghostscript.

Mungkinkah ada sesuatu yang berbeda tentang cara font disematkan dalam output oleh pdftex yang menyebabkan bug masih terjadi?

test-pdftex.pdf - masih rusak
test-pdftex pdf - google chrome - with fix

test-ps2pdf.pdf - diperbaiki
test dvi - test-ps2pdf pdf - google chrome - with fix

Test.tex.txt sumber lateks asli

Hai @jpallen , hanya ingin memberi tahu Anda bahwa tampaknya masalah di Sharelatex telah diperbaiki saat saya mengalihkan kompiler ke XeLatex.

Kami telah melakukan sedikit penggalian lebih dalam ini di ShareLaTeX, dan sepertinya tambalan di atas (https://github.com/mozilla/pdf.js/pull/7482 oleh @brendandahl) berada di baris yang benar dalam hal memindahkan karakter ke area penggunaan pribadi, tetapi tidak mencakup semua kasus yang diperlukan. PDF yang dihasilkan oleh ps2pdf berfungsi, tetapi yang dihasilkan langsung oleh pdflatex masih memiliki masalah rendering ini.

Jika kita secara naif memindahkan _everything_ ke area penggunaan pribadi (misalnya https://github.com/brendandahl/pdf.js/compare/move-non-unicode-glyphs...briangough:put-all-symbolic-chars-in- private-use-area), lalu merender dengan benar. Namun, ini hanyalah contoh debugging karena saya menganggap ini bukan ide yang bagus.

Pada titik ini pengetahuan kita mencapai batasnya dan kita tidak tahu bagaimana mengidentifikasi simbol yang benar untuk ditempatkan di area penggunaan pribadi. Jadi, adakah yang bisa kita lakukan untuk membantu memajukan ini?

Jika kita secara naif memindahkan semuanya ke area penggunaan pribadi (misalnya brendandahl @ move-non-unicode-glyphs ... briangough: put-all-symbolic-chars-in-private-use-area), maka itu akan ditampilkan dengan benar. Namun, ini hanyalah contoh debugging karena saya menganggap ini bukan ide yang bagus.

Tanpa menguji hal-hal di atas, saya curiga bahwa hal itu sebenarnya dapat menyebabkan rendering yang lebih buruk di file PDF _many_, karena itu mungkin (pada dasarnya) menyebabkan petunjuk dinonaktifkan untuk _all_ font simbolik di penyaji font tertentu. (Perhatikan bahwa banyak font yang mengklaim sebagai Simbolik, meskipun sebenarnya tidak.)

Pada titik ini pengetahuan kita mencapai batasnya dan kita tidak tahu bagaimana mengidentifikasi simbol yang benar untuk ditempatkan di area penggunaan pribadi. Jadi, adakah yang bisa kita lakukan untuk membantu memajukan ini?

Karena kasus yang bermasalah menggunakan font Type1 normal, saya masih berpikir bahwa solusi yang benar _may_ adalah memastikan bahwa kami memberikan informasi Charset / Encoding saat mengonversi font Type1 di Type1Font_wrap .

@jpallen saya rasa kita perlu mengenali fonta yang dihasilkan oleh lateks dan font tersebut adalah simbol (mis. dengan nama atau cara pembuatannya), tetapi mereka tidak akan dikenali seperti itu di kasus lainnya.

Tidak memindahkan _all_ karakter ke area pribadi memberi kita beberapa keuntungan, misalnya kemungkinan menggunakan font dalam kontrol input, instrumentasi yang lebih baik, dan kemampuan mesin untuk membuang simbol atau font yang tidak valid dan masih mendapatkan teks yang agak mudah dibaca. Jadi mengetahui apakah mesin terbang adalah simbol adalah kuncinya di sini.

Ide tentatif, berdasarkan PR # 7482, mungkin dapat memindahkan karakter ke PUA ketika kita tidak dapat mempercayai bahwa data toUnicode benar; misalnya sesuatu seperti ini: https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus : issue-2594.

Bagus! Saya telah mencoba tambalan baru di Snuf fleupagus: issue-2594 dan tampaknya berfungsi dengan baik untuk kasus pengujian saya dan berbagai dokumen pdflatex yang saya coba. : +1:

Sebagai pengujian, saya telah menerapkannya dalam produksi dalam penampil pdf di www.ShareLaTeX.com , untuk melihat apakah ada masalah tak terduga yang muncul hari ini.

Kami telah menguji tambalan ini (https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-2594) dalam produksi selama 3 minggu terakhir dan telah memperbaiki masalah rendering font LaTeX untuk kami, tanpa masalah lain yang muncul. Akan lebih bagus lagi jika bisa dimasukkan terima kasih. : +1:

Saya mulai mengulas # 7705 dan mulai bertanya-tanya mengapa tambalan asli saya tidak juga memperbaiki test-pdftex.pdf . Hanya dengan melihat data font, sepertinya pdf.js harus memindahkan sebagian besar mesin terbang dari DVFZZA+CMEX10 ke area penggunaan pribadi karena kebanyakan dari mereka tidak memiliki nama mesin terbang yang valid ke nilai unicode. Misalnya, salah satu mesin terbang bermasalah (charcode = 110 name = 'braceleftBig') tidak memiliki nilai unicode tetapi sedang dipetakan ke 'n'. Masalahnya tampaknya datang dari ketika kita membangun peta unicode, itu benar berisi 68 nilai dengan mesin terbang yang memiliki nilai unicode yang cocok, tetapi setelah membangunnya kita menambahkan kembali semua nilai pengkodean asli, maka 110 akan diisi dengan 'n'.

Saya tidak yakin apa perbaikan yang benar di sini karena jika kita menghapus kode untuk menambahkan kembali nilai pengkodean maka pemilihan teks kita akan mundur dari https://github.com/mozilla/pdf.js/commit/325f7afcca30c891ec7be06a5178c012a052bd55

Mungkin @Snuffleupagus punya beberapa pemikiran ...

_Seperti yang disarankan oleh https://github.com/mozilla/pdf.js/issues/2594#issuecomment -254289210, versi PR # 7705 sebelumnya berisi solusi yang terlalu sederhana._

Dengan demikian, saya telah mengumpulkan upaya baru (dan bagi saya kemungkinan besar terakhir) untuk memperbaiki ini, yang dapat diuji dengan: http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html.
Akan sangat membantu jika orang yang saat ini terpengaruh oleh masalah ini dapat menguji versi terbaru PR # 7705, dan melaporkan jika itu cukup untuk memperbaiki masalah ini!

Bekerja dengan baik pada test-pdftex.pdf, kami akan mencoba menerapkannya dalam produksi di www.ShareLaTeX.com minggu ini dan melihat apakah ada masalah yang dilaporkan.

Bekerja dengan baik pada test-pdftex.pdf, kami akan mencoba menerapkannya dalam produksi di www.ShareLaTeX.com minggu ini dan melihat apakah ada masalah yang dilaporkan.

Sebagaimana dibahas di IRC, silakan merujuk ke http://logs.glob.uno/?c=mozilla%23pdfjs&s=21+Nov+2016&e=21+Nov+2016#c54315 , kami ingin melanjutkan dengan PR # 7705 .
@briangough Apakah Anda sudah mendapatkan hasil dari pengujian patch dalam produksi di ShareLaTeX?

Seperti disebutkan sebelumnya di https://github.com/mozilla/pdf.js/issues/2594#issuecomment -259930252, akan sangat membantu jika mereka yang saat ini terpengaruh oleh masalah ini dapat membantu menguji solusi yang diusulkan, yang dapat dilakukan dengan menggunakan misalnya pratinjau di http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html, dan laporkan jika ini memperbaiki masalah ini!

Kami ingin mendapatkan PR # 7705, tetapi kami sangat membutuhkan konfirmasi perbaikan sebelum melakukannya.

Maaf atas keterlambatannya. Tambalan berfungsi dengan baik - tidak ada keluhan dari pengguna kami, terima kasih.

Penutupan telah diperbaiki oleh # 7705, berkat @Snuffleupagus dan @brendandahl!

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

patelsumit5192 picture patelsumit5192  ·  3Komentar

hp011235 picture hp011235  ·  4Komentar

THausherr picture THausherr  ·  3Komentar

aaronshaf picture aaronshaf  ·  3Komentar

jigskpatel picture jigskpatel  ·  3Komentar