Pdf.js: عشوائية / ظاهرية "جريئة" / فساد

لا يمكنني "عدم" تعطيل العامل بسبب التنزيل الهائل الذي يسببه هذا في كل عرض

هل يمكنك شرح هذا الجزء؟

إذا كنت تحاول استخدام getDocument عدة مرات ، فاستخدم مثيل PDFWorker واحدًا. من الصعب معرفة سبب تلف الخطوط ، ولكن قد يؤدي الارتباط بمثال العمل إلى إلقاء بعض الضوء. هل يمكنك إنشاء / نشر مثال يسبب المشكلة؟

حسنًا ، لا يمكنني نشر ارتباط بسهولة. إذا قمت بتشغيل مع تمكين العمال ، فإنه يعمل بنسبة 100 ٪. إذا قمت بتعيين علامة التعطيل ، فسترى المشكلة الموضحة أعلاه ، بشكل عشوائي ، ربما مثيل واحد من 4.

كنت أقوم بإيقاف استجابة "فقط تمكين العمال" من خلال تفصيل "لماذا" أقوم بتعطيل العامل ، وهو أنني أعرض الكثير من ملفات PDF الصغيرة بسرعة إلى حد ما ، وأضيف تنزيل 1.2 ميغا بايت لـ pdf_worker.js لـ كل عرض غير عملي. لقد كنت أبحث في كود عامل الويب لمعرفة ما إذا كان هناك خيار للعاملين للتخزين المؤقت للنص .js الذي تم استدعاؤهم عليه ، لكنني لم أتمكن من العثور على أي شيء.

تخميني الأولي (استنادًا إلى التأثير) هو أن هناك شيئًا ما في مكان ما بنطاق عالمي يتم مسحه بشكل صحيح إذا تم تحميل البرنامج النصي لكل حالة ، وهذا يسبب مشكلة إذا تمت إعادة استخدام البرنامج النصي للعامل بشكل متكرر. ومع ذلك (!) نظرًا لأن المشكلة يمكن أن تحدث على شاشة FIRST pdf ، فأنا في حيرة من أمري لمعرفة ما يجب النظر إليه.

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

oddjobz ما زلت لا أفهم القلق. مع العامل المعوق _ مازلت_ تقوم بتنزيل pdf.worker.js ولكنه يحدث في الموضوع الرئيسي. يسمح الإعداد الصحيح على خادم الويب بالتخزين المؤقت لملف جافا سكريبت الثابت وتجنب تنزيل 1.2 ميغابايت لكل طلب دون بذل جهد إضافي. يجب أن يساعد PDFWorker في التخزين المؤقت لمثيلات عامل الويب على صفحة واحدة (على سبيل المثال عند تنفيذ getDocuments متعددة).

لست متأكدًا مما إذا كانت هذه المشكلة قد اكتملت بدون رمز للحل الخاص بك ، بشكل افتراضي ، يقوم PDF.js بتخزين رمز عامل الويب مؤقتًا عند استخدامه على خادم ويب قياسي مع متصفح قياسي (في التكوينات الافتراضية).

حسنًا ، لا أعرف ما هو الفرق بين الكود الذي أستخدمه والكود الذي لديك ، ولكن يوجد فرق في مكان ما. أولاً ، مع تعطيل العامل ، يتم تحميل pdf_worker.js مرة واحدة على أول نتيجة "فقط". مع تمكين العمال ، فإنه يقوم بتحميل الكود في كل مستند جديد ولا يبدو أن أي شيء أفعله له أي تأثير على التخزين المؤقت. (على سبيل المثال ، لم يتم تخزينها مؤقتًا) أظن أنه نظرًا لأن مطوري Chrome كانوا يواجهون مشاكل مع العاملين على الويب والرمز المخزن مؤقتًا ، فقد قاموا بإيقاف تشغيل التخزين المؤقت. بقدر ما أستطيع أن أرى جميع الرؤوس الخاصة بي كما ينبغي أن تكون للتخزين المؤقت ، لكن التخزين المؤقت لا يحدث. .

لدي ثلاث أجزاء ذات صلة ؛
أ. كتلة التعليمات البرمجية الرئيسية مع علامة البرنامج النصي
ب. Onload الذي يحدد المتغيرات العالمية
ج. فئة مستقلة تعرض ملف PDF في DIV

كتلة التعليمات البرمجية الرئيسية

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

كود التحميل

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

تعريف الطبقة

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();
        }
    });

وانا كذلك؛

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

وأحصل على المستند الافتراضي هو DIV مع معرف "pdf-canvas".

دعنا نجرب هذا:

1. افتح http://mozilla.github.io/pdf.js/web/viewer.html في Chrome
2. افتح أدوات devtools على صفحة الشبكة وأظهر وحدة التحكم المنقسمة (اضغط على "esc" في علامة التبويب هذه)
3. تأكد من عدم وقوعه في استثناء (تعطيل كسر الاستثناء والتحديث بخلاف ذلك)
4. تأكد من إيقاف تشغيل "تعطيل ذاكرة التخزين المؤقت" (قم بإلغاء التحديد والتحديث بخلاف ذلك)
5. في وحدة التحكم ، قم بتنفيذ PDFJS.getDocument('http://mozilla.github.io/pdf.js/web/compressed.tracemonkey-pldi-09.pdf')
6. لاحظ الثانية "pdf.worker.js" لها حالة "200 OK (from cache)"

مقتطفات التعليمات البرمجية ليست مفيدة. يرجى نشر مثال صغير في مكان ما (على سبيل المثال في صفحات جيثب)

نعم ، أراه .. يبدو أن هذا إصدار أحدث من PDF.js مما أستخدمه .. بافتراض أن الاختلاف ليس المشكلة ، سأقارن الرؤوس التي يضعها Varnish مقابل خادم الويب الخاص بي لمعرفة ما إذا يمكنني تحديد سبب عدم تخزينها مؤقتًا.

أظن أنه نظرًا لأن مطوري Chrome كانوا يواجهون مشكلات مع العاملين على الويب والرمز المخزن مؤقتًا ، فقد قاموا بإيقاف تشغيل التخزين المؤقت.

لا أرى أي اتصال بين هذا وخيار تعطيل العامل. يُطلب ملف pdf.worker.js بغض النظر عن صحته أو خطأه. لذلك يجب أن تكون المشكلة غير ذات صلة بالتخزين المؤقت.

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

حسنًا ، هذا مثير للاهتمام .. الاختبار ضد المضيف المحلي: 8443 على شهادة وهمية (حيث اسم المضيف! = المضيف المحلي) ، لا يتم تخزينه مؤقتًا. عندما أقوم بإجراء اختبار مقابل الخادم المباشر ، المنفذ 443 بشهادة تجارية صالحة ، فإنه يقوم بالتخزين المؤقت (!) ... لست متأكدًا تمامًا مما أفعله .. سأقوم ببعض الاختبارات الإضافية عندما أحصل على بعض الوقت ، ولكن من أجل الآن سأقوم بتمكين العاملين على الويب وأرى ما سيحدث. (لكنني أعتقد أنه لا تزال هناك مشكلة في مكان ما ...)

لست متأكدًا تمامًا من أنني أصدقني .. لذا أضفت بعض لقطات الشاشة ...

لا يتم تحديد تعطيل ذاكرة التخزين المؤقت بالتأكيد ...
(تكوين خادم الويب متطابق)

هل هناك شيء آخر يجب القيام به هنا؟ مما أفهمه لا يبدو هذا خطأ في PDF.js ، بل في التنفيذ المخصص.

سيكون من الجيد أن يكون لديك حالة اختبار يمكننا إعادة إنتاج هذا الفشل (المتقطع؟).

إنه خطأ ، سأقدم عرضًا توضيحيًا عبر الإنترنت ، لكنه سيستغرق بعض الترميز وقليلًا من الوقت ...

مرحبًا ، لدي نفس المشكلة.

لم تكتب شيئًا مخصصًا هنا ، فقط قم بتنزيل الريبو من Github

@ subhadip-codeclouds لا أعتقد أن لديك نفس المشكلة. يرجى فتح قضية منفصلة وتقديم التفاصيل المطلوبة.

@ subhadip-codeclouds أين يمكنني العثور على ملف pdf هذا؟ أواجه مشكلة مماثلة وأود استخدامها كحالة اختبار.

أعتقد أنني أواجه نفس مشكلة عرض الخط على Ubuntu مع Chrome (لم تختبر الأنظمة الأساسية الأخرى). أنا أستخدم أحدث ملفات pdf.js من الإصدار الرئيسي ، وفي بعض الأحيان سيبدو ملف PDF مثل ملفoddjobz 's PDF وأحيانًا سيبدو مثل ملف @ subhadip-codeclouds. يبدو أن هذا يحدث بشكل عشوائي على ملفات PDF العشوائية.

لا أعرف حقًا ما هو الخطأ أو كيفية إعادة إنتاجه بشكل موثوق. لكن هذا هو السيناريو. أنا أستخدم React لبناء موقع ديناميكي من صفحة واحدة. غالبًا ما ينقر المستخدمون على علامة تبويب وسيؤدي ذلك إلى إنشاء إطار iframe وعرض pdf.js داخل إطار iframe. نظرًا للطريقة التي يعمل بها React وموقع الويب الخاص بي ، يتم إنشاء إطار iframe وإتلافه مرارًا وتكرارًا. قد يستغرق الأمر بعض الوقت ولكن في النهاية سأحصل دائمًا على تلف في عرض الخط. وبمجرد حدوث ذلك لملف PDF واحد ، سيبدأ في الظهور لملفات PDF الأخرى بشكل عشوائي. البعض دائما بخير والبعض الآخر ليس كذلك.

هل هناك أي شيء (مثل علامات التصحيح) يمكنني تشغيله أو القيام به للمساعدة في اكتشاف ما يجري؟ لا أرى أي أخطاء أو تحذيرات في وحدة التحكم.

هنا ملف PDF ينتهي به الأمر دائمًا مع تلف عرض الخط عند بدء تشغيله.
https://datalanche-sec-public.s3.amazonaws.com/filings/0001047469-15-008315/a2226328zex-31_2.htm.pdf

شيء اخر. إذا فتحت علامة تبويب جديدة في Chrome بنفس عنوان URL ، فسيتم إصلاح ملفات PDF. ومع ذلك ، إذا بقيت في نفس علامة التبويب ، فانتقل إلى موقع ويب مختلف تمامًا ، ثم انتقل إلى موقع الويب الخاص بي (بدون استخدام زر الرجوع) ، فلا تزال ملفات PDF ذات الخطوط الفاسدة تالفة. يبدو أن كل ما يحدث يفسد ذاكرة علامة التبويب و / أو ذاكرة التخزين المؤقت.

من المحتمل أن تكون مشكلة التخزين المؤقت في Chrome (راجع https://github.com/mozilla/pdf.js/issues/7751#issuecomment-256683285 لمزيد من التفاصيل).

أي تحديث على هذا؟ تواجه نفس المشكلة

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

يحدث لي ذلك طوال الوقت ، ولكنه عشوائي بما يكفي بحيث لا يمكنني إنشاء حالة اختبار. ومع ذلك ، فمن المحتمل تمامًا أن يكون هناك تلف في الذاكرة من الترابط في حالتي أيضًا ، لكنني اعتقدت أن Javascript كان مترابطًا واحدًا؟

اعتقدت أن Javascript كان مترابطة واحدة

أنه. أعتقد أن ما يعنيه oddjobz (؟) أنه قد يكون هناك خطأ في Chrome عندما ترسم على أكثر من لوحة HTML5 في وقت يكون للعيب فرصة كبيرة لحدوثه. ولكن بدون حالة اختبار قابلة للتكرار ، من الصعب التكهن وإنشاء تقرير مفيد إلى أخطاء Chromium.

أعتقد (من الذاكرة) أنها توظف خيار استخدام ميزة متصفح جديدة تسمى "عمال الويب" ، والتي تتيح لك بشكل فعال إنشاء سلاسل جافا سكريبت .. إذا قمت بإيقاف تشغيل هذه الميزة ، فحاول عرض ملف PDF "كبير" ، انظر "لماذا" هذه الميزة قيد الاستخدام ... :)

يستخدم خيار استخدام ميزة متصفح جديدة تسمى "عمال الويب" ...
إذا قمت بإيقاف تشغيل هذه الميزة ، ثم حاول عرض ملف PDF "كبير" ، سترى "لماذا" هذه الميزة قيد الاستخدام

يرجى ملاحظة أن OP يوجه لإيقاف تشغيل هذه الميزة ، ويعني عدم استخدام عمال الويب ، مما ينقل اللوم إلى المتصفح ، وليس له علاقة بـ "خيوط" JavaScript.

إنه دقيق بعض الشيء ، Javascript عبارة عن سلسلة واحدة ، لكن Chrome متعدد الخيوط ، ويسمح لك العاملون على الويب بتشغيل عمليتي Chrome وتسهيل الاتصال بينهما. أعتقد أن المعلم فقط هو الذي يحصل على وصول إلى DOM ، ولكن يمكنك استخدام سلاسل فرعية للأشياء المكثفة للمعالج دون حظر سلسلة UI. يصبح الأمر أكثر متعة عندما تجد أنه يمكنك إنشاء عمال ويب غير مرتبطين بسلسلة أو علامة تبويب معينة ، بحيث ينجون بشكل فعال من إعادة تحميل الصفحة (أي أنهم مستمرون). أرى الكثير من المشاكل تنبع من هذا ...

بالتأكيد - لكن تعليقي هو أنه بدون استخدام خيوط المعالجة (أي من خلال تنفيذ قفل مستوى مؤشر الترابط الخاص بي) ، فإن 99٪ من هذه المشكلة تختفي. (لي).

oddjobz ، @ rpedela حاول تعطيل تسريع الأجهزة / وحدة معالجة الرسومات ومعرفة ما إذا كانت المشكلة لا تزال تحدث.

yurydelendik ، نعم ، كان هذا واضحًا ، أحد أول الأشياء التي

yurydelendik ، تم نشر طلبي

Javascript عبارة عن سلسلة واحدة ، ولكن Chrome متعدد الخيوط ، ويسمح لك العاملون على الويب بتشغيل عمليتين على Chrome وتسهيل الاتصال بينهما. أعتقد أن المعلم فقط هو الذي يحصل على وصول إلى DOM ، ولكن يمكنك استخدام سلاسل فرعية للأشياء المكثفة للمعالج دون حظر سلسلة UI.

هذا البيان مع مصطلح "عامل الويب" محير. هل يمكنك توفير مراجع للتحقق من البيانات أعلاه؟ لا يمكن لعمال الويب الوصول إلى DOM حسب التصميم ، ويقوم PDF.js بالرسم على السلسلة الرئيسية. هل تقصد عملية عرض Chrome؟ لا تزال الطريقة الوحيدة لتحديث DOM هي من الخيط الرئيسي وليس من العاملين على الويب.

تبدأ rocess قبل الانتهاء من السابق - الخيوط أم لا ، وضع قفل يدوي لمنع بدء العمليات قبل أن تنتهي العملية السابقة من إصلاحها.

ماذا تقصد بالضبط بـ "العمليات" في هذا السياق ، هل هو عمر استدعاء API render() ؟

oddjobz لقد قرأت الموضوع مرة أخرى وهناك الكثير من العبارات المتضاربة في فترات زمنية مختلفة. كما أن قسم التكوين متعارض أيضًا ، على سبيل المثال لا يمكنني إعادة إنتاج ذلك محليًا على أي متصفح على نظام التشغيل Mac OSX. ما زلت غير متأكد مما إذا كان يمكنك إعادة إنتاجه باستخدام العارض القياسي (وليس العارض المخصص). سأغلق هذا الخطأ باعتباره غير صالح / غير مكتمل لعدم الخلط بين المشاركين الآخرين في سلسلة المحادثات.

oddjobz ، rpedela ، badams ، pholisma ، @ subhadip-codeclouds هل يمكنك تقديم تقرير خطأ منفصل مع التهيئة (التكوينات) الدقيقة التي تواجهك بها والخطوات الدقيقة متى يمكن إعادة إظهار المشكلة (بما في ذلك ملف PDF)؟ إذا كان حلًا مخصصًا ، فقدم رابطًا عامًا إليه.

حسنًا ، هذا هو الرمز المعني - يمكنك رؤية الإصلاح في مكانه.

على وجه التحديد للقفل ، لدي روتين مثل ذلك ؛

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;
    });
},

نعم ، هذا هو السبب في أنني لم أتطرق إلى النقطة في ذلك الوقت ، يبدو أن هناك إحجامًا كبيرًا حتى عن قبول وجود مشكلة - ناهيك عن الحاجة إلى إصلاحها.

تمت معالجة مشكلة المقتطف أعلاه من خلال https://github.com/mozilla/pdf.js/pull/6571

حسنًا ، ماذا يمكنني أن أقول ، كنت أستخدم أحدث إصدار في منتصف عام 2016 وما زلت أواجه المشكلة. يبدو أنني أتذكر أنه تم إخباري في ذلك الوقت (بشكل متكرر) أنه تم إصلاحه. (ومثل عدد من الأشخاص الآخرين ، كان بإمكاني أن أرى أنه لم يكن كذلك)

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

yurydelendik يحدث هذا باستمرار لمستخدمينا (باستخدام Windows 7 بشكل أساسي) ، لكنني تمكنت من إعادة إنتاجه على OSX بأحدث إصدار ، ولكن ليس بنسبة 100٪ باستمرار.

نحن لا نستخدم أي كود مخصص ، ببساطة نقوم بما يلي

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

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

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

badams ، يمكنني أن أؤكد أن التكبير كان أيضًا بمثابة إصلاح بالنسبة لي ، كما كانت الصفحة التالية / السابقة. كان لدي أيضًا انطباع بأن الغموض يجعل المشكلة أكثر احتمالًا.

سأحاول تخصيص بعض الوقت للتوصل إلى حالة اختبار قابلة للتكرار

شكرًا على badams ،

اهلا ياجماعة،

لم أفهم هذه القصة كاملة بشكل صحيح.
هل يوجد حل بالفعل؟ أو نوع من التنفيذ يجب أن أفعله؟

مع تحياتي،
تارسيسيو بيريرا

لم أفهم هذه القصة كاملة بشكل صحيح.

لا أعتقد أن أي شخص يفعل.

هذا الموضوع مغلق لأنه لا يوفر خطوات دقيقة لإعادة إظهار المشكلة (وبسبب بعض التوصيات المضللة في التعليقات). لا نتوقع أن تكون المشكلة قابلة للتكرار بنسبة 100٪ ، ولكن إظهارها مرة واحدة على الأقل كل 10 مرات سيكون أمرًا رائعًا.

العناصر المحتملة التي يمكن أن تؤدي إلى تنفيذ PDF.js بهذه الطريقة أو وجود خطأ في التعليمات البرمجية الخاصة به:

• لا يعالج خادم أو متصفح HTTP طلبات نطاق HTTP بشكل صحيح
• لا يتعامل المستعرض بشكل صحيح مع تحميل الخط أو عملية لوحة الرسم
• يتعارض حل مخصص مع العمليات أعلاه

FWIW لقد رأيت هذا الفساد في مواقف نادرة مع نشرنا pdf.js (v1.7.376). يبدو التعامل مع طلب النطاق لدينا صحيحًا. سأقدم تقريرًا إذا كان بإمكاني العثور على خطوات إعادة موثوقة ...

لدينا هذه المشكلة فقط على Chrome ، بعد تغيير التكبير يختفي. لذلك قمنا بتعيين showPreviousViewOnLoad على false ولم نواجه هذه المشكلة مرة أخرى.

TZanke هل يمكن أن توضح لماذا تؤدي إزالة showPreviousViewOnLoad إلى تغيير التكبير / التصغير؟ شكر!

يحسب التكبير التلقائي tonyjin pdf.js قيمة التكبير ويحفظها في التخزين المحلي. بعد إعادة تحميل الصفحة ، لا يتم استخدام التكبير التلقائي ، وبدلاً من ذلك يتم استخدام قيمة التكبير المحسوبة السابقة. ويبدو أن هناك مشكلة في تحميل هذه القيمة مرة أخرى.

لذلك عند تعطيل showPreviousViewOnLoad تشغيل ميزة التكبير التلقائي في كل مرة ، وتكبير الصفحة بشكل صحيح ، ولا تحدث مشاكل في العرض.

TZanke - لقد جربت