Pdf.js: Jalur SVG salah dipecah menjadi 2 node

Dibuat pada 6 Feb 2019 · 4Komentar · Sumber: mozilla/pdf.js

Lampirkan (disarankan) atau Tautkan ke file PDF di sini:
tes4.pdf

Konfigurasi:

Peramban web dan versinya: Chrome 56.0.2924.76
Sistem operasi dan versinya: Linux Mint 18.3
Versi PDF.js: komit c0d6e46e392b327996eb0964b7932cb5bdde1727
Apakah ekstensi browser: tidak

Langkah-langkah untuk mereproduksi masalah:

jalankan "simpul pdf2svg.js test4.pdf"
muat hasil test4.1.svg ke Chrome
Periksa log kesalahan konsol. Anda akan melihat ini:

Apa perilaku yang diharapkan? (tambahkan tangkapan layar)
Tidak ada kesalahan.

Apa yang salah? (tambahkan tangkapan layar)
Satu jalur di output dipecah menjadi 2 bagian.
"M" awal ada di satu simpul dan "L" berikutnya ada di simpul berikutnya.
Ini harus berada di simpul yang sama.
bad_svg_node

Tautan ke pemirsa (jika dihosting di situs selain mozilla.github.io/pdf.js atau sebagai ekstensi Firefox/Chrome):

4-svg

Sumber

johnkingsley

Komentar yang paling membantu

Saya tidak begitu akrab dengan cara kerja OperatorList tetapi sepertinya daftar operator dibagi menjadi beberapa bagian sekitar 1000 operator.

Benar; ini untuk memungkinkan rendering dimulai sebelum seluruh OperatorList (yaitu halaman) telah diuraikan, sehingga mengurangi keseluruhan waktu yang dibutuhkan dari pemuatan halaman hingga dirender sepenuhnya.

Apakah ini terdengar masuk akal?

Ya, dan itu harus mudah diverifikasi (cukup tingkatkan nilainya banyak , secara efektif menonaktifkan chunking ini).

Alih-alih memodifikasi OperatorList dan konstanta CHUNK_SIZE , svg.js harus diperbaiki.

Setuju, memodifikasi konstanta jelas bukan solusi yang dapat diterima. Pertama-tama, itu tidak akan melakukan apa pun selain memindahkan kesalahan ke tempat lain. Kedua, dan yang lebih penting, mengubahnya dapat memiliki implikasi luas untuk kinerja rendering umum di back-end kanvas.

Mungkin seperti ini: Operator OPS.constructPath berurutan harus digabungkan menjadi satu simpul <svg:path> jika tidak ada operator pengecatan jalur yang mengintervensi...

Sekali lagi, itu terdengar sangat masuk akal.

Snuffleupagus pada 12 Feb 2019

👍3

Semua 4 komentar

Ini mungkin terkait dengan bug #9167.

johnkingsley pada 6 Feb 2019

Saya pikir pelakunya ada di sini:
https://github.com/mozilla/pdf.js/blob/a045a00af34b764edda5991d2bcd18541ed60536/src/core/operator_list.js#L533 -L534
Saya tidak begitu akrab dengan cara kerja OperatorList tetapi sepertinya daftar operator dibagi menjadi beberapa bagian sekitar 1000 operator. Terkadang batas potongan ditempatkan di tengah definisi jalur PDF. Ini menghasilkan dua OPS.constructPath operator dan yang terakhir tidak dimulai dengan moveTo .

Apakah ini terdengar masuk akal?

Alih-alih memodifikasi OperatorList dan konstanta CHUNK_SIZE , svg.js harus diperbaiki. Mungkin seperti ini: Operator OPS.constructPath berurutan harus digabungkan menjadi satu simpul <svg:path> jika tidak ada operator pengecatan jalur yang mengintervensi...

janpe2 pada 12 Feb 2019

👍3

Saya tidak begitu akrab dengan cara kerja OperatorList tetapi sepertinya daftar operator dibagi menjadi beberapa bagian sekitar 1000 operator.

Apakah ini terdengar masuk akal?

Ya, dan itu harus mudah diverifikasi (cukup tingkatkan nilainya banyak , secara efektif menonaktifkan chunking ini).

Alih-alih memodifikasi OperatorList dan konstanta CHUNK_SIZE , svg.js harus diperbaiki.

Mungkin seperti ini: Operator OPS.constructPath berurutan harus digabungkan menjadi satu simpul <svg:path> jika tidak ada operator pengecatan jalur yang mengintervensi...

Sekali lagi, itu terdengar sangat masuk akal.

Snuffleupagus pada 12 Feb 2019

👍3

Saya dapat mengonfirmasi bahwa jika saya meningkatkan CHUNK_SIZE menjadi 10000000 maka masalahnya akan hilang.
(dan saya setuju bahwa ini bukan solusi yang tepat)
Terima kasih atas bantuan Anda.

johnkingsley pada 13 Feb 2019

Apakah halaman ini membantu?

0 / 5 - 0 peringkat