Pdf.js: تضمين دعم لملفات PDF ذات العلامات

تمت إضافة تسمية [الفرز حسب الحاجة]. هل نحتاج إلى ملصق جديد (4-tagged-pdf) للتطوير المتعلق بملفات PDF ذات العلامات؟

هل لدينا أمثلة على ملفات PDF؟ أنا شخصياً لم أر ملفات PDF من قبل. كم مرة يتم استخدامها في الممارسة؟

نعم ، لدينا نوعان من هؤلاء:

$ cd test/pdfs/
$ grep -rla '/Marked true'
i9.pdf
fips197.pdf
issue1169.pdf
smaskdim.pdf
issue3879.pdf
bug816075.pdf
pdf.pdf
issue1709.pdf
f1040.pdf
wdsg_fitc.pdf
annotation-border-styles.pdf
ecma262.pdf
bug887152.pdf
issue1133.pdf
issue2442.pdf
issue1796.pdf
type4psfunc.pdf

إذا كنت بحاجة إلى المزيد ، https://encrypted.google.com/search؟q=filetype٪3Apdf+ "٪ 2FMarkInfo" + "٪ 2FMarked + true"

شكرا لك! في هذه الحالة ، من المثير للاهتمام بالتأكيد النظر في هذا الأمر.

أعتقد أنه قد يكون من السهل نسبيًا تنفيذ ذلك باستخدام مزيج من سمات HTML و ARIA - لا يلزم إجراء تغييرات على العرض - ما عليك سوى إضافة بعض السمات الجديدة.

يتم تخزين معلومات علامات PDF في شجرة StructTreeRoot ، والتي تحتوي على عناصر هيكلية مع معلومات إمكانية الوصول مثل النص البديل واللغة والنوع الدلالي (H1 ، TH ، LI ، إلخ). تحتوي عناصر الهيكل على مراجع للكائنات في دفق محتوى الصفحة. يوجد رسم يوضح هذا هنا:
https://stackoverflow.com/a/34047585

أعتقد أنه يمكنك إدخال معلومات علامات PDF في _layoutText(textDiv) باستخدام شيء مثل هذا:

1) ابحث عن عنصر الهيكل المقابل في شجرة StructTreeRoot لكائن PDF الذي يتم تقديمه
2) أضف سمة role إلى div إذا كان عنصر البنية له نوع هيكل مثل H1 و H2 و LI وما إلى ذلك.
3) أضف سمة aria-label إلى div إذا كان عنصر البنية يحتوي على إدخال / Alt
4) أضف سمة aria-level إلى div المقابلة لمستوى العنوان لأنواع البنية H1-H6

يجب أن يجعل هذا العناوين والقوائم والصور في متناول قارئ الشاشة. قد يكون تنفيذ الجداول أكثر تعقيدًا.

يتم سرد أنواع بنية PDF في القسم 14.8.4.3. من
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

بالنسبة إلى العنوان ، سيتغير العرض من هذا:

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);">
7.  Evaluation
</span>

الى هذا:

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);" 
role="heading" aria-level="1">
7.  Evaluation
</span>

سيقرأ قارئ الشاشة ذلك بعد ذلك على أنه "7. التقييم ، مستوى العنوان 1" والأهم من ذلك أنه يتيح للمستخدم التنقل بين العناوين باستخدام مفتاح "العنوان التالي" (مما يجعل التنقل بين المستندات الكبيرة أسهل بكثير)

لقد لاحظت أنه قد تمت إزالة تسمية pdf ذات 4 علامات. هل لا يزال هذا شيئًا يتم متابعته؟

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

واو هذا رائع! هل تتضمن هذه الميزة قيد النظر دعمًا لإنشاء ملفات PDF ذات علامات تمييز؟ يمكن أن يسهل تنفيذ شيء مثل المحلل اللغوي / المحلل لملفات PDF الحالية ، ولكنه سيوفر أيضًا دعمًا لإنشاء ملفات PDF 508c.

الوظائف الأساسية المطلوبة لإنشاء ملفات PDF 508c:

• ضع علامة على المستند (بلغة وعنوان ، وربما علامات أخرى)
• قم بتمييز الكائنات الهيكلية داخل PDF (رأس ، جدول ، th ، td ، قوائم ، إلخ.)
• إضافة نص بديل إلى الوسائط المرئية (الصور ، الفيديو ، الأشكال ، إلخ.)
• إنشاء / الحفاظ على ترتيب عناصر الجدولة

إذا كانت الوظائف الأساسية موجودة لهذه الأشياء الأربعة ، فسيكون من الممكن تطبيق المنطق في عملية إنشاء PDF التي من شأنها إنتاج 508c PDFs. لنكون صادقين ، سيكون هذا ضخمًا ، لأنني لم أجد حتى الآن أي أداة جافا سكريبت مفتوحة المصدر تدعم هذه الوظيفة.

بعد كتابة هذا ، لست متأكدًا مما إذا كان هذا مؤهلًا كطلب ميزة منفصل أم لا ... يسعدني إنشاء مشكلة جديدة إذا كان هذا هو الحال.

لقد كنت أعمل مع cuhaller لتوفير توافق أفضل مع SC 2.4.10 و 1.1.1 من WCAG 2.0 لحالات الاستخدام الخاصة بالتطبيق الذي يعمل عليه فريقه.

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

لدي تغييرات في مفترق من 2.3.200 من PDF.js لتوفير مستويات العناوين ونص صورة بديل (بدون تحديد الموضع) الموجود في فرع العناوين و img-alt-text لهذا الريبو .

أنا متردد في فتح علاقات عامة نظرًا لوجود نزاعات دمج ضد السيد وليس لدي الوقت حاليًا لحلها.

إذا كان لدى أي شخص متاح لتحديث هذا الفرع مع الماستر ، فدعنا نتواصل معك!

روجت شركة Edge للدعم الأصلي لملفات PDF ذات العلامات. يدعمها Chrome الآن أيضًا ، وقد روج أيضًا لقدرته القادمة على تصدير ملفات PDF ذات العلامات من صفحات الويب.

اليوم ، لا يعرض Firefox العلامات في ملفات PDF لشجرة الوصول / واجهات برمجة تطبيقات الوصول. ومع ذلك ، يوجد هذا النص في قائمة ميزات Firefox 80 :

يمكن الآن تعيين Firefox ليكون عارض PDF الافتراضي للنظام.

إذا قام المستخدم الذي يعتمد على AT بهذا ، أو قام مسؤول النظام الذي لا يعرف تكوين المستخدمين بذلك ، فقد يكون من الصعب بالنسبة لهؤلاء المستخدمين الذين اعتمدوا بطريقة أخرى على Edge أو Chrome أو Adobe Reader لتحليل ملفات PDF المميزة لهم. .

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

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

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

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

بدون هذا الدعم ، لدينا مخاوف بشأن تنفيذ PDF JS على نطاق واسع. هل هناك أي تحديث أو مخطط زمني حول دعم ميزة لتوفير الترميز الدلالي؟ نطلب اعتبار هذه المشكلة ذات أولوية أعلى لأنها تؤثر على قدرة المستخدمين على إدراك المحتوى والتفاعل معه.

وبقدر ما أعلم ، فإن المساهمات موضع ترحيب كبير

شكرا @ trjohnst لعملك على هذا.

لقد بدأت في إعادة تأسيس فرع trjohnst يدويًا على ملف pdf.js الرئيسي. يعمل هذا الأسلوب جيدًا مع العلامات التي تحتاج فقط إلى مستوى واحد ؛ على سبيل المثال ، العناوين أو الصور التي تحتوي على نص بديل. عند السير في دفق المحتوى ، إذا واجه تسلسل محتوى محدد ، فإنه يبحث عن عنصر الهيكل المرتبط ويضع دور ARIA المناسب على امتداد النص في إخراج HTML بواسطة طبقة نص pdf.js.

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

بدلاً من محاولة القيام بذلك في طبقة النص ، أعتقد أننا سنحتاج إلى السير في شجرة الهيكل وتقديم العقد بناءً على ذلك ، ووضع خصائص ARIA على العناصر التي نخرجها. يمكن لشجرة البنية أن تشير إلى البيانات في كل من طبقات النص والتعليقات التوضيحية. يمكننا إما إعادة ترتيب عقد DOM للنص وطبقة التعليقات التوضيحية بناءً على شجرة البنية (قد يكون الأمر صعبًا دون كسر العرض المرئي؟) أو استخدام خصائص aria لإعادة ترتيب شجرة a11y فقط دون إعادة ترتيب DOM.

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

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

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