Pdf.js: tidak ada dukungan untuk parameter "viewrect" di pengidentifikasi fragmen URL

Hai,
Saya baru di sini, mencari masalah untuk diperbaiki, dan saya ingin memperbaiki masalah ini kecuali seseorang sudah melakukannya. Dan saya juga membaca dokumentasi tentang viewRect, saya tidak begitu yakin, apa yang dimaksud dengan wd dan ht.
Adakah yang bisa mencerahkan saya tentang wd itu, dan ht? Terima kasih sebelumnya.

Jangan ragu untuk mengerjakan ini. Saya pikir wd adalah "lebar" dan ht adalah "tinggi".

Hai @AndrewMyint , Saya hanya ingin mengarahkan Anda ke beberapa masalah yang terkait dengan yang satu ini, yang mendokumentasikan perilaku yang salah dari implementasi saat ini dari parameter " zoom " (yang salah nama): https://github .com/mozilla/pdf.js/issues/10773 dan https://github.com/mozilla/pdf.js/issues/2843.

Terima kasih @markmatney Saya telah mencari melalui pdf_link_service.js, dan saya terkejut bahwa parameter " zoom " menangani argumen Fit padahal seharusnya ditangani di " view " parameter sesuai dengan dokumentasi .

@markmatney Jika saya tidak salah, semua nilai yang diberikan sebagai argumen seperti (left, top, scale, Fit, ...) digunakan dalam BaseViewer.scrollPageIntoView . Dan, ada sejumlah penanganan switch case (Fit, FitB, FitH,......) di scrollPageIntoView . Dan, satu kasus menarik yang saya temukan adalah FitR yang saya bahkan tidak melihat argumen FitR dalam dokumentasi .

Tetapi menurut saya " FitR " menghasilkan perilaku " viewrect " jika Anda menambahkan #zoom=FitR,72,72,288,432 ke bilah alamat URL.

Bisakah Anda mengonfirmasi bahwa itu adalah perilaku yang diharapkan untuk viewrect ? Terima kasih.

Ya, saya percaya BaseViewer.scrollPageIntoView adalah metode yang melihat semua argumen itu dan kemudian entah bagaimana mengubah viewport berdasarkan argumen tersebut.

Saya juga ingat pernah melihat FitR ketika saya pertama kali melihat ini. Itu diperkenalkan ke master pada d30fac0 (4 Sep 2011) bersama dengan argumen Fit* , dan didefinisikan dalam spesifikasi Referensi PDF . Saya tidak yakin mengapa itu dihilangkan dari spesifikasi "Parameter untuk Membuka File PDF" (atau mengapa bahkan ada dua spesifikasi terpisah, dalam hal ini).

Bagaimanapun, saya memiliki pendapat yang kuat bahwa viewrect harus diimplementasikan secara berbeda dari FitR . Ini tentu bisa diperdebatkan, tetapi:

• hanya memperlakukannya sama akan menjadi mubazir dan akan membatasi jumlah kasus penggunaan yang dapat dipenuhi oleh perangkat lunak ini, dan
• karena spesifikasi PDF mendefinisikan semantik masing-masing secara berbeda, kami tentu _dapat_ mengimplementasikannya secara berbeda sambil tetap mengikuti spesifikasi.

Saya berharap untuk melihat implementasi viewrect mana, tidak seperti FitR , tampilan yang dihasilkan tidak bergantung pada dimensi jendela browser web pengguna. Untuk melihat apa yang saya maksud, buka https://mozilla.github.io/pdf.js/web/viewer.html#zoom =FitR,0,0,144,144. Fragmen URL tersebut meminta pemirsa untuk menunjukkan area persegi kira-kira 2" x 2" (_w_ x _h_, 1" ~ 72 px). Saat ini, jika browser saya adalah layar penuh dalam tampilan 1080 x 720 (rasio 3:2) berorientasi lanskap, maka saya sebenarnya diperlihatkan wilayah 3" x 2". Jika saya memutar layar 90 derajat dan melihat persegi panjang yang sama di browser layar penuh, maka saya diperlihatkan wilayah 2" x 3". Ini karena PDF.JS mengisi sisa ruang yang tersedia, sesuai spesifikasi Referensi PDF hlm. 583:

[_page_ /FitR _left_ _bottom_ _right_ _top_]

Tampilkan halaman yang ditunjuk oleh _page_, dengan konten yang diperbesar secukupnya agar sesuai dengan persegi panjang yang ditentukan oleh koordinat [...] seluruhnya di dalam jendela [...] Jika faktor perbesaran horizontal dan vertikal yang diperlukan berbeda, gunakan yang lebih kecil dari kedua [...]

"Parameter untuk Membuka File PDF" mendefinisikan viewrect jauh lebih longgar (lihat komentar pembuka pada masalah ini untuk definisi). Saya ingin melihat implementasi yang menampilkan wilayah yang sama terlepas dari ukuran jendela browser, sehingga apa pun _di luar_ wilayah yang ditentukan akan menjadi tidak fokus ("berwarna abu-abu" atau "dihitamkan"). Kecuali saya melewatkan sesuatu, implementasi seperti itu masih akan memenuhi spesifikasi.

Membaca komentar saya, saya baru menyadari bahwa implementasi PDFjs dari FitR menyimpang dari spesifikasi Referensi PDF. Ini menafsirkan persegi panjang sebagai _x,y,w,h_ ketika harus ditafsirkan sebagai _kiri,bawah,kanan,atas_.