Pdf.js: دعم مفقود لمعلمة "العرض الصحيح" في معرفات جزء عنوان URL

أهلا،
أنا جديد هنا ، وأبحث عن مشكلة يجب إصلاحها ، وأود إصلاح هذه المشكلة ما لم يكن شخص ما قد قام بذلك بالفعل. وقرأت أيضًا التوثيق حول viewRect ، لست متأكدًا تمامًا ، إلى ماذا يشير wd و ht.
يمكن لأي شخص أن ينورني حول هذا wd ، و ht ، من فضلك؟ شكرا لك مقدما.

لا تتردد في العمل على هذا. أعتقد أن wd هو "العرض" و ht هو "الارتفاع".

مرحبًا AndrewMyint ، أردت فقط zoom " (المسماة بشكل خاطئ): https: // github .com / mozilla / pdf.js / issues / 10773 و https://github.com/mozilla/pdf.js/issues/2843.

شكرًا markmatney على أنني كنت أبحث في pdf_link_service.js ، وأنا مندهش من أن المعلمة " zoom " تتعامل مع وسيطة Fit بينما يجب التعامل معها في " view " المعلمة وفقا للوثائق .

markmatney إذا لم أكن مخطئًا ، كوسيطات مثل (left, top, scale, Fit, ...) في BaseViewer.scrollPageIntoView . وهناك عدد من حالات التبديل (Fit, FitB, FitH,......) معالجة في scrollPageIntoView . وهناك حالة واحدة مثيرة وجدتها وهي FitR التي لا أرى فيها حتى الوسيطة FitR في التوثيق .

ولكن يبدو لي أن " FitR " ينتج سلوك " viewrect " إذا قمت بإلحاق #zoom=FitR,72,72,288,432 بشريط عنوان URL.

هل يمكنك تأكيد أن هذا هو السلوك المتوقع لـ viewrect ، من فضلك؟ شكرا لك.

نعم ، أعتقد أن BaseViewer.scrollPageIntoView هي الطريقة التي تبحث في كل هذه الحجج ثم تقوم بطريقة ما بتحويل إطار العرض بناءً عليها.

أتذكر أيضًا أنني رأيت FitR عندما نظرت في هذا الأمر في البداية. تم تقديمه في master في d30fac0 (4 سبتمبر 2011) مع باقي Fit* args ، وهو محدد في مواصفات مرجع PDF . لست متأكدًا من سبب حذفه من مواصفات "معلمات فتح ملفات PDF" (أو سبب وجود مواصفات منفصلة لهذه المسألة).

على أي حال ، لدي رأي قوي بأنه يجب تطبيق viewrect بشكل مختلف عن FitR . هذا بالتأكيد قابل للنقاش ، ولكن:

• مجرد معاملتهم بالطريقة نفسها سيكون زائداً عن الحاجة وسيحد من عدد حالات الاستخدام التي يمكن أن يحققها هذا البرنامج ، و
• نظرًا لأن مواصفات PDF تحدد دلالات كل منها بشكل مختلف ، فنحن بالتأكيد _يمكننا_ تنفيذها بشكل مختلف مع استمرار الالتزام بالمواصفات.

أتمنى أن أرى تطبيقًا viewrect حيث ، على عكس FitR ، لا يعتمد العرض الناتج على أبعاد نافذة متصفح الويب الخاصة بالمستخدم. لمعرفة ما أعنيه ، انتقل إلى https://mozilla.github.io/pdf.js/web/viewer.html#zoom = FitR، 0،0،144،144. يطلب جزء عنوان URL من العارض عرض منطقة مربعة مقاس 2 × 2 بوصة تقريبًا (_w_ x _h_ ، 1 بوصة ~ 72 بكسل). حاليًا ، إذا كان المتصفح في وضع ملء الشاشة بدقة 1080 × 720 (نسبة 3: 2) أفقيًا موجهًا ، فسيظهر لي في الواقع منطقة 3 × 2. إذا قمت بتدوير الشاشة 90 درجة وعرضت نفس المستطيل في متصفح ملء الشاشة ، فستظهر لي منطقة 2 "× 3". هذا بسبب يملأ PDF.JS بقية المساحة المتاحة ، وفقًا لمواصفات PDF المرجعية ص 583:

[_page_ / FitR _left_ _bottom_ _right_ _top_]

اعرض الصفحة المحددة بواسطة _page_ ، بمحتوياتها مكبرة بما يكفي لملاءمة المستطيل المحدد بواسطة الإحداثيات [...] بالكامل داخل النافذة [...] إذا كانت عوامل التكبير الأفقية والرأسية المطلوبة مختلفة ، فاستخدم أصغر الاثنان [...]

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

عند قراءة تعليقي ، أدركت للتو أن تطبيق PDFjs FitR يختلف عن المواصفات المرجعية لـ PDF. يفسر المستطيل كـ _x ، y ، w ، h_ عندما يجب تفسيره على أنه _ يسار ، أسفل ، يمين ، أعلى_.