Pdf.js: "Cetak tebal" / korupsi acak / jelas

Dibuat pada 31 Mar 2016  ·  46Komentar  ·  Sumber: mozilla/pdf.js

Tautan ke file PDF:
default.pdf

Konfigurasi:

  • Browser web dan versinya: Versi 49.0.2623.87 (64-bit) [masalah bukan pada browser tertentu]
  • Sistem operasi dan versinya: Linux Ubuntu 15.10 [bukan OS khusus]
  • Versi PDF.js: [all / 1.3.91]
  • Merupakan ekstensi: pdf.js tertanam dalam aplikasi

Langkah-langkah untuk mereproduksi masalah:

  1. Buka penampil berulang kali
  2. Terkadang tampilan Oke, terkadang ada "cetak tebal" acak
  3. Frekuensi tampaknya Acak
  4. Ini DISEBABKAN dengan menyetel "PDFJS.disableWorker = true;" (menghapus masalah perbaikan ini)
  5. Saya tidak bisa "tidak" menonaktifkan pekerja karena unduhan besar-besaran ini menyebabkan tampilan _every_
  6. Konten dimuat dari string dalam memori
  7. Saya telah memverifikasi konten string konsisten antara tampilan Ok dan korup
  8. Pada dokumen multi-halaman, memajukan satu halaman lalu kembali selalu memperbaiki masalah

Apa perilaku yang diharapkan? (tambahkan tangkapan layar)
ok

Apa yang salah? (tambahkan tangkapan layar)
corrupt

1-other 4-chrome-specific

Semua 46 komentar

Saya tidak bisa "tidak" menonaktifkan pekerja karena unduhan besar-besaran ini menyebabkan di setiap tampilan

Bisakah Anda menjelaskan bagian ini?

Jika Anda mencoba menggunakan getDocument beberapa kali, gunakan satu instance PDFWorker. Sulit untuk mengetahui apa yang menyebabkan font menjadi rusak, tetapi memiliki tautan ke contoh yang berfungsi mungkin memberi penjelasan. Bisakah Anda membuat / menerbitkan contoh yang menyebabkan masalah?

Oke, saya tidak bisa memublikasikan link dengan mudah. Jika saya menjalankan dengan pekerja diaktifkan, ini berfungsi 100%. Jika saya mengatur flag disable, Anda melihat masalah yang ditunjukkan di atas, secara acak, mungkin 1 contoh 4.

Saya memulai tanggapan "aktifkan saja pekerja" dengan menjelaskan "mengapa" saya menonaktifkan pekerja, yaitu saya menampilkan banyak PDF kecil dengan cukup cepat, dan menambahkan unduhan 1,2 MB untuk pdf_worker.js untuk setiap tampilan tidak praktis. Saya telah melihat kode web-worker untuk melihat apakah ada opsi bagi pekerja untuk meng-cache skrip .js tempat mereka dipanggil, tetapi saya belum berhasil menemukan apa pun.

Dugaan awal saya (berdasarkan efek) adalah bahwa ada sesuatu di suatu tempat dengan cakupan global yang dihapus dengan benar jika skrip dimuat untuk setiap contoh, yang menyebabkan masalah jika skrip pekerja berulang kali digunakan kembali. Namun (!) Mengingat masalah dapat terjadi pada tampilan pdf PERTAMA, saya agak bingung untuk mengetahui apa yang harus dilihat.

Saya memulai tanggapan "aktifkan saja pekerja" dengan menjelaskan "mengapa" saya menonaktifkan pekerja, yaitu saya menampilkan banyak PDF kecil dengan cukup cepat, dan menambahkan unduhan 1,2 MB untuk pdf_worker.js untuk setiap tampilan tidak praktis.

@oddjobz Saya masih tidak memahami kekhawatirannya. Dengan pekerja yang dinonaktifkan Anda _still_ mengunduh pdf.worker.js tetapi itu terjadi di utas utama. Penyiapan yang benar di server web memungkinkan penyimpanan file javascript statis dan menghindari unduhan 1,2 MB untuk setiap permintaan tanpa upaya tambahan. PDFWorker akan membantu dengan caching contoh pekerja web di satu halaman (misalnya ketika beberapa getDocuments dilakukan).

Tidak yakin apakah masalah ini selesai tanpa kode untuk solusi Anda, secara default PDF.js menyimpan cache kode pekerja web saat digunakan di server web standar dengan browser standar (dalam konfigurasi default).

Yah, saya tidak tahu apa perbedaan antara kode yang saya gunakan dan kode yang Anda miliki, tetapi ada perbedaan di suatu tempat. Pertama, dengan pekerja dinonaktifkan, pdf_worker.js dimuat sekali pada klik pertama "hanya". Dengan pekerja diaktifkan, itu memuat kode pada setiap dokumen baru dan tidak ada yang saya lakukan yang berpengaruh pada caching. (yaitu tidak disimpan dalam cache) Saya agak curiga bahwa karena pengembang Chrome mengalami masalah dengan pekerja web dan kode cache, mereka telah menonaktifkan cache. Sejauh yang saya bisa lihat semua tajuk saya sebagaimana mestinya untuk penyimpanan dalam cache, tetapi penyimpanan dalam cache tidak terjadi. (sedangkan hal lain _dis_ cache)

Saya memiliki tiga bagian yang relevan;
Sebuah. Blok kode utama dengan tag script
b. Onload yang menetapkan variabel global
c. Kelas berdiri sendiri yang menampilkan PDF dalam DIV

blok kode utama;

<script type="text/javascript" src="js/compatibility.js"></script>
<script type="text/javascript" src="js/pdf.js"></script>

kode onload;

    PDFJS.disableWorker = true;
    PDFJS.verbosity = PDFJS.VERBOSITY_LEVELS.debug;
    PDFJS.workerSrc = "/js/pdf.worker.js";

definisi kelas;

JS.require('JS.Class',function(Class) {

    CLASS.PDFViewer = new Class({

        locked  : false,
        page        : 0,
        pages   : 0,
        pdf     : null,
        doc_id  : null,

        initialize: function(prefix) {
            this.canvas   = prefix+'-canvas';           // Canvas element ID we'll be rendering to
            this.prefix   = prefix;
            this.id_page  = '#'+this.canvas+'-page';    // Ident of page number
            this.id_pages = '#'+this.canvas+'-pages';   // Ident of page count
            this.setfocus(null);                        // Element to focus after render
        },
        reset:      function() { this.now_showing = null; console.log("PDF Reset")},
        set:        function(doc_id) { this.doc_id = doc_id; console.log("Docid:",doc_id) },
        load:       function() { this.fetch(this.doc_id); },
        set_doc:    function() {},
        setfocus: function(field_id) { this.focuson = field_id; },

        decode: function(base64) {
            var raw = atob(base64);
            var uint8Array = new Uint8Array(raw.length);
            for (var i = 0; i < raw.length; i++) {
                uint8Array[i] = raw.charCodeAt(i);
                }
          return uint8Array;
        },

        full_screen: function() {
            if( $('#'+this.prefix+'-hide-me').is(':visible') ) {
                $('#'+this.prefix+'-hide-me').hide();
                $('#'+this.prefix+'-full-screen').removeClass("col-sm-7");
                $('#'+this.prefix+'-full-screen').addClass("col-sm-12");
            } else {
                $('#'+this.prefix+'-hide-me').show();
                $('#'+this.prefix+'-full-screen').removeClass("col-sm-12");
                $('#'+this.prefix+'-full-screen').addClass("col-sm-7");
            }
            this.turn_page();
        },
        focus: function() {
            if(this.focuson) {
                console.log("SetFocus>>",this.focuson);
                setTimeout("$('"+this.focuson+"').focus()",100);
                this.focuson = null;
            }
        },
        display: function(pdf) {
            this.pdf = pdf;
            $(this.id_pages).text(this.pdf.numPages);
            this.pages = this.pdf.numPages;
            this.page = 1;
            this.turn_page();
        },
        fetch: function(rid) {
            if(this.locked) return false;
            var self = this;
            var src = '/images/default.pdf';
            function success(data) {
                if(!LIB.check_error(data)) return false;
                if(data.pdf) src = self.decode(data.pdf);
                self.locked = true;
                PDFJS.getDocument(src).then(function(pdf){ self.display(pdf); });
                return true;
            }
            ionman.call('nac.rpc.pdf_spec',{'rid': rid},success)
            return true;
        },
        turn_page: function() {
        var self = this;
            self.pdf.getPage(self.page).then(function(page) {
                var canvas = document.getElementById(self.canvas);
        var ctx = canvas.getContext('2d');
        var unscaledViewport = page.getViewport(1.0);
                canvas.width = $('#'+self.canvas).width();
                var scale = canvas.width / unscaledViewport.width;
                var viewport = page.getViewport(scale);
                canvas.height = viewport.height;
            var renderContext = { canvasContext: ctx, viewport: viewport };
        page.render(renderContext).promise.then(function(){
                setTimeout(function(){
                    self.locked = false;
                        self.focus();
                    },250);
                });
                $(self.id_page).text(self.page);
            });
        },
        next: function() {
            if( this.page == this.pages) return;
            this.page += 1;
            this.turn_page();
        },
        prev: function() {
            if( this.page == 1) return;
            this.page -= 1;
            this.turn_page();
        }
    });

Jadi saya lakukan;

var viewer = CLASS.PDFViewer('pdf');
viewer.fetch();

Dan dokumen default yang saya dapatkan adalah DIV dengan ID "pdf-canvas".

Ayo coba ini:

  1. Buka http://mozilla.github.io/pdf.js/web/viewer.html di Chrome
  2. Buka alat pengembang di halaman Jaringan dan tampilkan konsol terpisah (tekan 'esc' di tab ini)
  3. Pastikan itu tidak terperangkap dalam pengecualian (nonaktifkan jeda pengecualian dan segarkan sebaliknya)
  4. Pastikan "Disable Cache" tidak aktif (hapus centang dan segarkan jika tidak)
  5. Di konsol, jalankan PDFJS.getDocument('http://mozilla.github.io/pdf.js/web/compressed.tracemonkey-pldi-09.pdf')
  6. Perhatikan kedua "pdf.worker.js" memiliki status "200 OK (dari cache)"

screen shot 2016-03-31 at 10 51 26 am

Potongan kode tidak membantu. Harap terapkan contoh kecil di suatu tempat (misalnya di halaman github)

Ya, saya melihatnya .. ini tampaknya versi PDF.js yang lebih baru daripada yang saya gunakan .. dengan asumsi perbedaannya bukan masalahnya, saya akan membandingkan tajuk yang dipasang oleh Varnish terhadap server web saya untuk melihat apakah Saya dapat melihat mengapa ini tidak disimpan dalam cache.

Saya agak curiga karena pengembang Chrome mengalami masalah dengan pekerja web dan kode cache, mereka telah menonaktifkan caching.

Saya tidak melihat hubungan antara ini dan opsi disableWorker. Pdf.worker.js diminta terlepas dari benar atau salah. Jadi masalahnya pasti tidak relevan dengan cache.

Untuk kesederhanaan, saya berasumsi bahwa ini terkait dengan cara kerja pesan dalam mode disableWorker (yang tidak benar-benar diuji, dan dibuat hanya untuk mendukung browser lama dan kemudahan debugging). Ini akan membantu mempersempit masalah untuk memiliki kasus uji minimal di mana masalah terlihat (lebih disukai dapat diakses secara online).

Ok, jadi ini menarik .. pengujian terhadap localhost: 8443 pada sertifikat tiruan (di mana nama host! = Localhost), itu tidak cache. Ketika saya menguji terhadap server langsung, port 443 dengan sertifikat komersial yang valid, itu melakukan cache (!) ... tidak begitu yakin apa yang membuatnya .. akan melakukan pengujian lagi ketika saya punya sedikit waktu, tetapi untuk sekarang saya akan mengaktifkan pekerja web dan melihat apa yang terjadi. (tapi saya pikir masih ada masalah di sana di suatu tempat ...)

Saya tidak sepenuhnya yakin saya mempercayai saya .. jadi saya telah menambahkan beberapa tangkapan layar ...

live

dev

Nonaktifkan cache pasti _tidak_ dicentang ...
(konfigurasi server web identik)

Apakah ada hal lain yang harus dilakukan di sini? Dari apa yang saya pahami ini tidak terdengar seperti bug di PDF.js, melainkan dalam implementasi khusus.

Akan menyenangkan untuk memiliki kasus uji kami dapat mereproduksi kegagalan (intermiten?) Ini.

Ini bug, saya akan membuat demonstrasi online, tetapi akan membutuhkan beberapa pengkodean dan sedikit waktu ...

Hai, saya mengalami masalah yang sama.

Tidak ada yang tertulis khusus di sini, cukup unduh repo dari Github
screencapture 7

@ subhadip-codeclouds Saya rasa Anda tidak memiliki masalah yang sama. Harap buka masalah terpisah dan berikan detail yang diminta.

@ subhadip-codeclouds Di mana saya dapat menemukan pdf ini? Saya mengalami masalah serupa dan ingin menggunakannya sebagai kasus uji.

Saya yakin saya mengalami masalah render font yang sama di Ubuntu dengan Chrome (belum menguji platform lain). Saya menggunakan pdf.js terbaru dari master, dan terkadang PDF akan terlihat seperti PDF @oddjobz dan terkadang terlihat seperti PDF @ subhadip-codeclouds. Ini tampaknya terjadi secara acak pada PDF acak.

Saya tidak benar-benar tahu apa yang salah atau bagaimana mereproduksinya dengan andal. Bagaimanapun ini adalah skenario. Saya menggunakan React untuk membangun situs web satu halaman yang dinamis. Pengguna akan sering mengklik tab dan itu akan membuat iframe dan menampilkan pdf.js di dalam iframe. Mengingat cara React dan situs web saya bekerja, iframe dibuat dan dihancurkan berulang kali. Mungkin perlu beberapa saat tetapi akhirnya saya akan selalu mendapatkan korupsi render font. Dan begitu ini terjadi pada satu PDF, itu akan mulai terjadi pada PDF lain secara acak. Beberapa selalu baik-baik saja, dan beberapa tidak.

Apakah ada sesuatu (misalnya tanda debug) yang dapat saya aktifkan atau lakukan untuk membantu mencari tahu apa yang sedang terjadi? Saya tidak melihat kesalahan atau peringatan apa pun di konsol.

Berikut adalah PDF yang hampir selalu berakhir dengan kerusakan render font saat dimulai.
https://datalanche-sec-public.s3.amazonaws.com/filings/0001047469-15-008315/a2226328zex-31_2.htm.pdf

Satu hal lagi. Jika saya membuka tab baru di Chrome dengan URL yang sama maka PDF diperbaiki. Namun jika saya tetap di tab yang sama, menavigasi ke situs web yang sama sekali berbeda, dan kemudian menavigasi ke situs web saya (tidak menggunakan tombol kembali) PDF dengan font yang rusak masih rusak. Sepertinya apa pun yang terjadi merusak memori dan / atau cache tab.

Ini mungkin masalah cache di Chrome (lihat https://github.com/mozilla/pdf.js/issues/7751#issuecomment-256683285 untuk lebih jelasnya).

Ada pembaruan tentang ini? mengalami masalah yang sama

Meskipun saya masih melihat ini (entah kenapa) kadang-kadang, ini sangat jarang dan, memang cukup jarang saya benar-benar berhenti mengkhawatirkannya. Masalah yang sepertinya saya alami adalah operasi yang tumpang tindih. Ini "tampaknya" memungkinkan untuk beroperasi pada dokumen pdf (halaman berikutnya misalnya) sementara operasi lain masih berlangsung, dan tampaknya inilah yang menyebabkan masalah. Solusi saya adalah membungkus semua operasi dalam sebuah kelas, kemudian memasukkan kunci master pada titik masuk dan keluar sehingga tidak ada operasi terkait pdf yang dapat konflik - ini "tampaknya" telah memperbaiki beberapa hal untuk saya. Saya berasumsi secara samar bahwa barang-barang pdf berjalan di utas terpisah atau proses pekerja, karenanya kemungkinan konflik. Itu beberapa waktu yang lalu, tetapi dari memori saya pikir hal threading adalah sebuah opsi dan saya menemukan solusinya dengan menonaktifkannya, yang berdampak negatif pada kinerja, tetapi menyelesaikan masalah.

Itu terjadi pada saya sepanjang waktu, tetapi cukup acak sehingga saya tidak dapat membuat kasus uji. Namun sangat mungkin bahwa itu adalah kerusakan memori dari threading dalam kasus saya juga, tetapi saya pikir Javascript adalah single threaded?

Saya pikir Javascript adalah single threaded

Ini. Menurut saya, apa artinya @oddjobz (?) Bahwa mungkin ada bug di Chrome saat Anda melukis di lebih dari satu kanvas HTML5 pada saat cacat tersebut memiliki peluang besar untuk terjadi. Tetapi tanpa kasus uji yang dapat direproduksi, sulit untuk berspekulasi, dan membuat laporan yang berarti untuk bug Chromium.

Saya pikir (dari memori) ini menggunakan opsi untuk menggunakan fitur browser baru yang disebut "pekerja web", yang secara efektif memungkinkan Anda untuk membuat utas javascript .. jika Anda mematikan fitur ini, maka coba lihat PDF "besar", Anda lihat "mengapa" fitur ini digunakan ... :)

itu menggunakan opsi untuk menggunakan fitur browser baru yang disebut "pekerja web" ...
jika Anda mematikan fitur ini, kemudian mencoba melihat PDF "besar", Anda melihat "mengapa" fitur ini digunakan

Harap perhatikan bahwa OP menginstruksikan untuk mematikan fitur ini, berarti Web Workers tidak digunakan, yang memindahkan kesalahan ke browser, dan tidak ada hubungannya dengan "threading" JavaScript.

Agak halus, Javascript adalah satu utas, tetapi Chrome multi-utas, dan pekerja web memungkinkan Anda menjalankan dua proses Chrome dan memfasilitasi komunikasi di antara mereka. Saya pikir hanya master yang mendapat akses DOM, tetapi Anda dapat menggunakan sub-utas untuk hal-hal intensif prosesor tanpa memblokir utas UI. Ini menjadi lebih menyenangkan ketika Anda menemukan Anda dapat membuat pekerja web yang tidak terikat ke utas atau tab tertentu, sehingga mereka secara efektif bertahan dari pemuatan ulang halaman (yaitu mereka gigih). Saya melihat banyak masalah yang muncul dari sini ...

Tentu - tetapi komentar saya adalah bahwa tanpa threading (yaitu dengan menerapkan penguncian level thread saya sendiri), 99% masalah ini akan hilang. (untuk saya).

@oddjobz , @rpedela coba nonaktifkan akselerasi hardware / gpu dan lihat apakah masalah masih terjadi.

@yurydelendik , yup, itu sudah jelas, salah satu hal pertama yang saya coba. (tidak ada perbedaan)

@yurydelendik , aplikasi saya telah

Javascript adalah satu utas, tetapi Chrome multi-utas, dan pekerja web memungkinkan Anda menjalankan dua proses Chrome dan memfasilitasi komunikasi di antara mereka. Saya pikir hanya master yang mendapat akses DOM, tetapi Anda dapat menggunakan sub-utas untuk hal-hal intensif prosesor tanpa memblokir utas UI.

Pernyataan dengan istilah "pekerja web" ini membingungkan. Bisakah Anda memberikan referensi untuk memverifikasi pernyataan di atas? Pekerja Web tidak memiliki akses ke DOM berdasarkan desain, dan PDF.js melakukan lukisan di utas utama. Apakah yang Anda maksud adalah proses rendering Chrome? Masih satu-satunya cara untuk memperbarui DOM adalah dari utas utama dan bukan dari pekerja web.

rocess dimulai sebelum yang sebelumnya selesai - threading atau tidak, memasang kunci manual untuk mencegah operasi dimulai sebelum yang sebelumnya selesai memperbaikinya.

Apa sebenarnya yang Anda maksud dengan "operasi" dalam konteks ini, apakah ini seumur hidup panggilan API render() ?

@oddjobz Saya baru saja membaca

@oddjobz , @rpedela , @badams , @pholisma , @ subhadip-codeclouds dapatkah Anda memberikan laporan bug terpisah dengan konfigurasi yang tepat Anda mengalami masalah dan langkah-langkah yang tepat kapan dapat mereproduksi masalah (termasuk PDF)? jika itu adalah solusi khusus, berikan tautan publik ke sana.

Oke, ini kode yang dipermasalahkan - Anda dapat melihat perbaikannya di tempatnya.

Khusus untuk penguncian, saya punya rutinitas seperti itu;


this.locked = true;
PDFJS.getDocument(path+doc_id).then(function(pdf) {
    $('#pdf-canvas-pages').text(pdf.numPages);
    self.pages = pdf.numPages;
    self.page = 1;
    self.pdf = pdf;
    pdf.getPage(1).then(function(page) { self.turnpage(); });
})

turnpage: function() {
    var self = this;
    self.pdf.getPage(self.page).then(function(page) {
        var canvas = document.getElementById('pdf-canvas');
        var ctx = canvas.getContext('2d');
        var unscaledViewport = page.getViewport(1);
        canvas.width = $('#pdf-canvas').width();
        var scale = canvas.width / unscaledViewport.width;
        var viewport = page.getViewport(scale);
        canvas.height = viewport.height;
        var renderContext = { canvasContext: ctx, viewport: viewport };
        page.render(renderContext);
        $('#pdf-canvas-page').text(self.page);
        self.locked = false;
    });
},

Ya, inilah mengapa saya tidak memaksakan diri pada saat itu, tampaknya ada keengganan yang besar bahkan untuk menerima bahwa ada masalah - apalagi itu perlu diperbaiki.

Masalah dengan cuplikan di atas telah diatasi oleh https://github.com/mozilla/pdf.js/pull/6571

Apa yang bisa saya katakan, saya menggunakan versi terbaru pertengahan 2016 dan masih ada masalah. Sepertinya saya ingat pernah diberitahu pada saat itu (berulang kali) bahwa itu sudah diperbaiki. (dan seperti beberapa lainnya, saya dapat melihat bahwa ternyata tidak)

Bagaimanapun, bagi siapa pun di luar sana yang melihat masalah yang sama, coba tempelkan kunci seperti di atas dan lihat apakah ada bedanya .. itu hanya dua baris ...

@yurydelendik Ini terjadi cukup konsisten untuk pengguna kami (terutama yang menggunakan Windows 7), tetapi saya telah dapat mereproduksinya di OSX dengan versi terbaru, tetapi tidak 100% secara konsisten.

Kami tidak menggunakan kode khusus apa pun, cukup melakukan hal berikut

<iframe
    style="height: 650px; width: 600px"
    src="/path/to/pdfjs/web/viewer.html?file=/path/to/file.pdf"
/>

Tampaknya bergantung pada sejumlah faktor, seperti apakah ada teks tebal lainnya di dokumen, dan tingkat zoom awal (memperbesar dan memperkecil terkadang akan memperbaikinya) Saya juga memperhatikan bahwa ini hanya memengaruhi pratinjau, dan mencetak, saat mengunduh pdf tampaknya dirender dengan sempurna (saya rasa itu karena pdf.js hanya meneruskan file yang disediakan kepada pengguna).

Kami telah memutuskan untuk tidak menggunakan solusi ini dan mengunduh file ke mesin pengguna secara langsung, tetapi saya akan mencoba meluangkan waktu untuk membuat kasus uji yang dapat direproduksi meskipun saya sudah menghabiskan sepanjang hari kemarin untuk mengejar bug ini ..

@badams , saya dapat mengonfirmasi bahwa zoom juga merupakan perbaikan bagi saya, seperti halaman berikutnya / sebelumnya. Saya juga mendapat kesan bahwa huruf tebal membuat masalah lebih mungkin terjadi.

Saya akan mencoba meluangkan waktu untuk membuat kasus uji yang dapat direproduksi

@badams terima kasih, apa pun yang mengambil semua variasi saat kontributor mencoba mereproduksi masalah di komputer mereka akan berfungsi, dan contoh lengkap yang diterbitkan bekerja paling baik (Anda dapat menerbitkan contoh lengkap di cabang gh-pages repo github).

Hai kawan,

Saya tidak mengerti keseluruhan cerita ini dengan benar.
Apakah sudah ada perbaikan? Atau semacam implementasi yang harus saya lakukan?

Salam,
Tarcisio Pereira

Saya tidak mengerti keseluruhan cerita ini dengan benar.

Saya tidak berpikir ada yang melakukannya.

Utas ini ditutup karena tidak memberikan langkah yang tepat untuk mereproduksi masalah (dan karena beberapa rekomendasi yang menyesatkan di komentar). Kami tidak berharap masalah dapat direkonstruksi 100%, tetapi membuatnya muncul setidaknya sekali dalam 10 kali akan bagus.

Kemungkinan item yang dapat menyebabkan PDF.js melakukan cara ini atau memiliki bug dalam kodenya:

  • Server atau browser HTTP tidak menangani permintaan rentang HTTP dengan benar
  • Browser tidak menangani pemuatan font atau operasi kanvas dengan benar
  • Solusi khusus bentrok dengan pengoperasian di atas

FWIW Saya telah melihat korupsi ini dalam situasi yang jarang terjadi dengan penerapan pdf.js kami (v1.7.376). Penanganan permintaan jangkauan kami tampaknya benar. Akan melaporkan kembali jika saya dapat menemukan langkah-langkah repro yang dapat diandalkan ...

Kami hanya mengalami masalah ini di Chrome, setelah mengubah zoom, masalah itu menghilang. Jadi kami menetapkan showPreviousViewOnLoad menjadi false dan tidak pernah mengalami masalah ini lagi.

@TZanke dapatkah Anda menjelaskan mengapa menghapus showPreviousViewOnLoad akan mengubah zoom? Terima kasih!

@tonyjin pdf.js autozoom menghitung nilai zoom dan menyimpannya ke penyimpanan lokal. Setelah memuat ulang halaman, zoom otomatis tidak digunakan, sebagai gantinya nilai zoom yang dihitung sebelumnya digunakan. Dan sepertinya ada masalah saat memuat nilai ini lagi.

Jadi ketika menonaktifkan showPreviousViewOnLoad fitur zoom otomatis muncul setiap saat, memperbesar halaman dengan benar, dan tidak ada masalah render yang terjadi.

@TZanke - Saya mencoba pendekatan Anda, tetapi sayangnya, masalah tersebut terkadang masih muncul .. :(

Apakah halaman ini membantu?
0 / 5 - 0 peringkat