> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/ar/mzyd-mn-almwdhwaat/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md).

# مقدمة إلى ملفات PDF الموسومة: البنية الداخلية وتحديات إمكانية الوصول

## تحديث: يناير 2026

يرجى الاطلاع على [تعليمات Overleaf حول إنشاء ملفات PDF موسومة](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs).

ال [فريق LaTeX](https://latex-project.org/) أصدر ميزات جديدة تُمكّن من الوسم التلقائي لملفات PDF، وهو المتطلب الأساسي لإمكانية الوصول إلى PDF. تتوفر هذه الميزات الجديدة في Overleaf في [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available)، مع توفر تحديثات أحدث في إصدار TeX Live المتجدد المتاح عبر [Overleaf Labs](https://www.overleaf.com/labs/participate).

أصبح من الممكن الآن إنتاج ملف PDF موسوم من مصدر LaTeX متوافق مع المستوى AA من WCAG 2.1 باتباع [وثائق المستخدم الخاصة بنا](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) باستخدام إصدارات TeX Live المتاحة في Overleaf.

يمكن الاستمرار في قراءة المقالة أدناه من عام 2020، رغم أنها لم تُحدَّث بأحدث المعلومات حول إمكانية الوصول في LaTeX، بدافع الاهتمام وللحصول على معلومات خلفية حول وسم PDF.

***

## ما الذي تتناوله هذه المقالة؟

هدف هذه المقالة هو تقديم مقدمة إلى PDF الموسوم إلى جانب نظرة عامة على بعض التحديات التقنية التي تواجهها البرمجيات، بما في ذلك محركات TeX وLaTeX، والتي تهدف إلى إنتاج ملفات PDF موسومة ويمكن الوصول إليها. إن إمكانية الوصول، وبخاصة ملفات PDF، موضوع واسع ومعقد، ويطرح أيضًا تحديات تقنية لا يكون لها دائمًا حل واحد متفق عليه عالميًا أو مقبولًا — مثل كيفية تمثيل الرياضيات المعقدة داخل ملفات PDF بطريقة يمكن الوصول إليها: باستخدام MathML أم شيفرة LaTeX؟

على الرغم من أننا لا نستطيع التعمق في كل موضوع، ولا بد من تبسيط الكثير من التفاصيل، فإننا نستطيع إلقاء نظرة داخل ملفات PDF لنُبيّن ما الذي يتضمنه وسم ملف PDF فعلًا. وتأمل Overleaf أن تكون هذه المقالة مقدمة مفيدة، تقدّم خلفية كافية تمكّن القراء من فهم التحديات التقنية بشكل أفضل ودعم قراءاتهم واستكشافهم اللاحقين لـ PDF الموسوم وإمكانية الوصول. وتتضمن الموارد الواردة في هذه المقالة:

* [فيديو مدته 8 دقائق](#video-showing-the-logical-structure-of-a-tagged-pdf) يستكشف ملف PDF موسومًا أُنتج باستخدام LaTeX؛
* [مشروع Overleaf](#using-luatex-an-example-in-the-overleaf-gallery) لاستكشاف استخدام محارف المسافة في LuaTeX؛
* [تسجيلات صوتية](#tagged-yes-but-the-reading-order-is-incorrect) توضح مشكلات إمكانية الوصول في PDF.

## مقدمة

إن ضمان إمكانية الوصول إلى المحتوى الرقمي يُعترف به بحق بوصفه جانبًا مهمًا من إنتاج المحتوى ونشره. علاوة على ذلك، فإن الحكومات، بما في ذلك [المملكة المتحدة](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) و [الولايات المتحدة](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf)، تُسنّ قوانين تفرض على المحتوى المنتج ضمن نطاق ولايتها الالتزام بمعايير محددة لإمكانية الوصول. إن الامتثال عبر نشر المحتوى بصيغة HTML ليس مرهقًا بشكل غير معقول، لكن ضمان المستوى المطلوب من إمكانية الوصول للمستندات الموزعة بصيغة PDF يمكن أن يكون تحديًا تقنيًا كبيرًا — وذلك اعتمادًا على البرنامج المستخدم لإنشاء المحتوى المقرر إخراجه كملف PDF.

ظهر PDF في أوائل التسعينيات بوصفه حلًا للمشكلات المحيطة بنقل المستندات الموثوق، وقد أثبت التاريخ أنه ناجح نجاحًا باهرًا. ومع ذلك، فإن PDF أيضًا تنسيق ملفات معقد نشأ قبل الاعتراف الواسع والحاجة المقبولة إلى تسهيل إمكانية الوصول إلى محتوى المستندات. ومع ذلك، تطورت مواصفة PDF بمرور الوقت لتوفر ميزات تمكّن وتدعم إنتاج مستندات PDF يمكن الوصول إليها باستخدام صيغة «مُنسّقة» من PDF تسميها Adobe *PDF الموسوم*.

عمليًا، فإن إنتاج ملفات PDF موسومة —*ويمكن الوصول إليها بالكامل*—يفرض على البرامج التي تُخرج PDF متطلبات تقنية إضافية كبيرة، وهذا يشمل محركات TeX ومنظومة LaTeX من الماكروات وحزم LaTeX الإضافية.

## نشأة PDF بوصفه ورقًا رقميًا بصيغته النهائية

ال [نشأة تنسيق المستندات المحمول (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) يعود إلى عصر كانت فيه عملية نقل المستندات بين الحواسيب محفوفة بالصعوبات، وغالبًا ما كانت تنجم عن تحويلات الملفات التي تؤدي إلى إعادة تدفق الصفحات واختلافات أخرى تفاقمت بسبب الخطوط والترميزات النصية غير المتوافقة المستخدمة على أنظمة تشغيل مختلفة (وخاصة Windows وMacintosh). كان مؤلف هذه المقالة يعمل في مجال النشر آنذاك ولديه ذكريات حية عن التعامل مع تلك التحديات!

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

### الورق الرقمي: هل هو جيد لجميع المستخدمين؟

إن أصل PDF، بوصفه شكلًا من أشكال الورق الرقمي، يفترض بطبيعة الحال استخدام أرقام الصفحات المطبوعة والطباعة أو عناصر التصميم كدلائل للتنقل البصري في محتواه — على الشاشة أو على الورق. لكن هذه الدلائل/الآليات البصرية، بطبيعة الحال، لا معنى لها للأشخاص ذوي الإعاقة البصرية الشديدة. واليوم يُعترف بحق بتحسين إمكانية الوصول إلى المحتوى الرقمي بوصفه جانبًا مهمًا من إنتاج المحتوى ونشره. يتمثل التحدي أمام PDF في توفير آليات تيسّر الوصول غير البصري إلى المحتوى المحصور داخل «حاوية» صُممت في الأصل لمحاكاة الوسيط البصري للصفحة المطبوعة.

كان أول إصدار من مواصفة PDF (PDF 1.0) [أُصدر رسميًا في 15 يونيو 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) تبعته إصدارات جديدة مع تحديثات شملت، في عام 2001 (PDF 1.4)، إدخال «PDF الموسوم» الذي [«...مكّن مستخدمي تقنيات المساعدة»](https://www.adobe.com/accessibility/pdf.html)وقد وسّعت الإصدارات اللاحقة من مواصفة PDF وعززت ميزات PDF، وصولًا إلى أحدث إصدار (PDF 2.0) الذي، استنادًا إلى [تقارير](https://www.pdfa.org/tagged-pdf-2-0/)، أجرى إصلاحًا كبيرًا لميزات إمكانية الوصول — رغم أن PDF 2.0 لا يزال غير مدعوم جيدًا من محركات TeX.

## المحتوى داخل ملفات PDF

لإدراك القضايا المعنية، يجدر فحص الكيفية التي تمثل بها ملفات PDF فعليًا محتوى الصفحة الذي تتضمنه. في عمق ملف PDF، يوجد محتوى كل صفحة داخل *تدفق المحتوى*؛ سلسلة من معاملات PDF («أوامر») تضع النص أو الرسومات في موضع معين على الصفحة لكي تقوم البرمجيات المستخدمة بـ *عرض* PDF. في الواقع، يوفر تدفق المحتوى وصفًا رسوميًا أو «وصفة» تخبر تطبيقات عرض PDF بكيفية «رسم» كل صفحة — محددًا ما الذي يجب عرضه على الصفحة وأين. وبطبيعة الحال، تتضمن تلك السلسلة من المعاملات تعليمات لاختيار خطوط معينة بحجم محدد، واختيار الألوان، وتحديد سماكات الخطوط، ورسم الخطوط والمنحنيات، وما إلى ذلك — أي كل ما يلزم لتوفير وصف رسومي كامل لعرض الصفحة بصريًا.

لتقليل حجم الملف، تُضغط تدفقات محتوى PDF وتُخزن بصيغة ثنائية مضغوطة، لكن إذا كان لديك وصول إلى برنامج مناسب، مثل Adobe Acrobat Pro DC، فيمكنك استخدامه لعرض نسخة نصية عادية «غير مضغوطة» من تدفقات محتوى الصفحة.

لننظر في كيفية «رسم» جدول بواسطة معاملات PDF: سيحتوي تدفق محتوى PDF على تسلسل مناسب من المعاملات لإنتاج خطوط أفقية/عمودية، واختيار خطوط مختلفة، وإخراج نص موضوع في مواقع مختلفة على الصفحة لإنتاج محتوى الجدول. ولإثبات ذلك، فلننظر إلى مستند PDF بسيط جدًا غير موسوم لا يحتوي إلا على جدول أساسي مع بعض النص — أُنشئ في Microsoft Word لأسباب ستتضح لاحقًا في المقالة. إليك لقطة شاشة تعرض ملف PDF البسيط لدينا:

![جدول أُنشئ في Microsoft Word](/files/0ac00e9bba26ac5109291b21ce639cce2bd70a1c)

إذا استخرجنا تدفق محتوى الصفحة (غير المضغوط) لهذا الملف ولصقنا الأسطر القليلة الأولى في محرر نصوص، فيمكننا تلخيص بعض معاملات PDF لنأخذ «لمحة» عن كيفية «وصف» ملفات PDF للمحتوى المعروض على هذه الصفحة.

![صورة لتدفق المحتوى في ملف PDF](/files/5460c5e0138e2359d899b2282a7439028694a750)

إذا كان لديك وصول إلى Adobe Acrobat Pro DC، فيمكنك استخدامه لسرد المعاملات الموجودة في تدفق محتوى صفحة PDF. وإليك عرض Acrobat لـ *البنية الداخلية لـ PDF* الملف نفسه الذي يوفر، على نحو مفيد، وصفًا بسطر واحد لكل معاملة استُخدمت لـ«رسم» صفحتنا الوحيدة التي تحتوي على جدول أساسي — لاحظ أن هذه الأوصاف القصيرة يقدمها Adobe Acrobat Pro DC، وهي *تحتوي* غير موجودة في ملف PDF نفسه:

![صورة لتدفق محتوى PDF كما يظهر في Adobe Acrobat Pro DC](/files/c1626a0f50746d926e431f5b0fbe200dd519374a)

ومع ذلك، لاحظ أن أياً من تعليمات الرسم تلك (المعاملات) لا يخزن أي «معنى» أو «وصف» لما ينتجه بالفعل: إنها مجرد مجموعة من معاملات الرسوميات التي تؤدي إلى بناء ما يعتبره *المشاهد المبصر* بوصفه جدولًا. ومن الواضح أن عرض الجدول الناتج عن معاملات الرسوميات تلك في تدفق محتوى PDF ليس وسيلة مناسبة للوصول إلى هذا المحتوى بالنسبة لذوي الإعاقة البصرية الشديدة. والمطلوب هو آلية تُمكّن ملفات PDF من احتواء وصف غير بصري مناسب (قابل للقراءة آليًا) لذلك الجدول — وبالطبع لكل عناصر المحتوى الأخرى الموجودة داخل الصفحات في ملف PDF.

لتمكين الوصول غير البصري إلى المحتوى، تحتاج ملفات PDF إلى احتواء بيانات إضافية تضفي «معنى» أو دلالات على مجموعات أو تجمعات من المعاملات المستخدمة لـ«رسم» جزء معين من المحتوى. وبالضرورة، يجب أن يمتد هذا المبدأ المتمثل في إسناد «معنى» أو توفيره إلى جميع أشكال المحتوى الموجودة في PDF: توجد هذه الآلية وتسمى *الوسم* لـPDF لإنتاج «نسخة» من PDF تُسمّى، وليس بغريب، *PDF الموسوم*.

## مقدمة إلى PDF الموسوم

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

صممت Adobe PDF الموسوم لتحقيق عدد من الأهداف التي تضمنت جعل المحتوى متاحًا للمستخدمين ذوي الإعاقات البصرية، لكنه يشمل أيضًا القائمة التالية المأخوذة من القسم 10.7 من [مواصفة Adobe PDF 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf):

* الاستخراج البسيط للنص والرسومات للصقها في تطبيقات أخرى؛
* إعادة تدفق تلقائية للنص والرسومات المرتبطة به لتتلاءم مع صفحة بحجم مختلف عن ذلك المفترض في التخطيط الأصلي؛
* معالجة النص لأغراض مثل البحث والفهرسة والتدقيق الإملائي؛
* التحويل إلى صيغ ملفات شائعة أخرى (مثل HTML وXML وRTF) مع الحفاظ على بنية المستند ومعلومات التنسيق الأساسية.

بالإضافة إلى ذلك، يتطلب PDF الموسوم أيضًا:

* أن يُمثَّل النص داخل محتوى PDF بصيغة يمكن تحويلها إلى Unicode؛
* يجب تمثيل فواصل الكلمات صراحةً — لاحظ أن محركات TeX لا تستخدم محارف المسافة لفصل الكلمات، بل تستخدم التباعد المرن في TeX المسمى glue (انظر أدناه)؛
* يُميَّز المحتوى الفعلي («الحقيقي») عن عناصر التخطيط وترقيم الصفحات.

يقوم PDF الموسوم على مفهومين أساسيين سنراجعهما:

* تعريف البنية المنطقية للمحتوى في ملف PDF؛
* وَسم (tagging) محتوى PDF بمجموعة من أنواع المحتوى القياسية.

## البنية المنطقية

في المستندات الأطول، يُقسَّم المحتوى عادةً إلى سلسلة من عناصر المحتوى الأصغر؛ فعلى سبيل المثال، تُقسَّم الكتب عادةً إلى فصول، وتُقسَّم هذه بدورها إلى أقسام وفروع فرعية تحتوي على فقرات وجداول وأشكال/رسوم بيانية وقوائم نقطية أو مرقمة وحواشٍ سفلية ومراجع وما إلى ذلك. ويُشار إلى بنية المحتوى وتنظيمه في مثل هذا الكتاب، أو أي نوع آخر من المستندات، باسم *البنية المنطقية*.

يلعب مفهوم البنية المنطقية للمستند دورًا مهمًا في إمكانية الوصول إلى ملفات PDF، لكن كبنية مفهومية قد تبدو البنية المنطقية غامضة بعض الشيء وصعبة الفهم. ويقدم التعريف التالي من [موسوعة نظم قواعد البيانات](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) رؤية مفيدة:

> «تشير البنية المنطقية إلى الطريقة التي تُنظَّم بها المعلومات في مستند؛ فهي تحدد تسلسل المعلومات والعلاقة بين الأجزاء المختلفة من المستند. وتوضح البنية المنطقية كيف بُني المستند، على عكس ما يحتويه المستند.»

لاحظ أن هذا التعريف للبنية المنطقية لا يشير تحديدًا إلى *كيف* مكان تخزين هذه المعلومات البنيوية ماديًا؛ بل يكتفي بأنه يوفر تمثيلًا لبنية المستند وتنظيمه. أما التفاصيل الدقيقة لكيفية تخزين البنية المنطقية للمستند أو تمثيلها فتعتمد على التنفيذ: أي على البرنامج المستخدم لإنشائها ومعالجتها.

### البنية المنطقية في ملفات PDF

توفر مواصفة PDF آليات يمكن من خلالها تسجيل البنية المنطقية لمستند داخل ملف PDF — لاستخدامها من قِبل البرامج التي قد ترغب، على سبيل المثال، في تصدير محتوى PDF إلى صيغ أخرى مثل XML أو HTML أو Microsoft Word. وتحتاج عمليات التصدير تلك إلى إنتاج مستند نصي منظم على نحو صحيح يلتزم بقواعد صيغة ملف التصدير الهدف — وهذا يتحقق بأفضل صورة عندما تُوجَّه عملية التصدير بمعلومات البنية المنطقية المقدمة داخل PDF.

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

#### تسمية عناصر المحتوى

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

صُممت الآليات التي يستخدمها PDF لتعريف البنية المنطقية للمستند بحيث تكون مرنة، لذا، من حيث المبدأ، يمكن للتطبيقات المختلفة التي تنشئ ملفات PDF وتعالجها أن تستخدم أسماء لأنواع المحتوى وفق أي اصطلاح تختاره. ومع ذلك، ولتعظيم قابلية تبادل المستندات والسماح لتطبيقات معالجة PDF المختلفة بتقديم نتائج متسقة، عرّفت Adobe مجموعة من الأسماء القياسية لأنواع عناصر المحتوى التي ينبغي لبرامج إنشاء PDF الالتزام بها. وفي مواصفة PDF تُشار إلى هذه الأسماء القياسية باسم الوسوم، ومن هنا نشأ مفهوم *الموسوم* PDF.

### وسم محتوى PDF: نظرة «تحت الغطاء»

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

#### تسلسلات المحتوى الموسوم: اللبنات الأساسية لـ PDF الموسوم

على أدنى مستوى، تبدأ عملية تسجيل معنى المحتوى الموجود داخل صفحة PDF (أي داخل تدفق المحتوى الخاص بها) بـ *تسلسلات المحتوى الموسوم* التي تُستخدم لتحديد (إضفاء «معنى» على) عناقيد أو مجموعات من معاملات PDF. ويُخصَّص لتسلسلات المحتوى الموسوم معرّف رقمي يسمى `MCID` (*معرّف المحتوى الموسوم*وهو عدد صحيح يبدأ من 0 إلى قيمة قصوى N معينة في كل صفحة. وتلك `MCID` القيم توفر طريقة لتحديد تسلسلات المعاملات الموجودة داخل تدفق المحتوى الخاص بصفحة معينة على نحو فريد. وللتوضيح، ففي كل صفحة تبدأ `MCID` المعرّفات من 0 وتزداد تسلسليًا حتى قيمة قصوى تعتمد على عدد تسلسلات المحتوى الموسوم الموجودة داخل تدفق المحتوى لصفحة معينة.

تُعد تسلسلات المحتوى الموسوم، في الواقع، «لبنات بناء» أساسية تُستخدم لتجميع هياكل بيانات أعلى مستوى تُسمّى *عناصر البنية*. وتحتوي عناصر البنية تلك على وسم، وهو الاسم المستخدم لتحديد نوع عنصر المحتوى الذي تمثله.

#### مثال على عناصر البنية

هنا نتقدم قليلًا إلى الأمام، لكن من المفيد مراجعة مثال. لنفترض أن لديك 3 مقاطع نصية صغيرة من محتوى الصفحة، ويُعرَّف كل واحد منها في تدفق المحتوى بواسطة تسلسل محتوى موسوم مختلف. يمكن حزم كل واحد من تلك المقاطع النصية الثلاثة داخل عنصر بنية خاص به، مع وسم، ويمكن ربطها جميعًا معًا باستخدام عنصر بنية آخر لتمثيل عنصر محتوى أعلى مستوى مثل سطر في جدول محتويات.

![صورة تشرح عناصر البنية وتسلسلات المحتوى الموسوم](/files/849310ca3e73b0b72766d4571d04b3b9d048d2ad)

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

### ما هو تسلسل المحتوى الموسوم؟

في النقاش أعلاه استخدمنا مستند PDF بسيطًا غير موسوم يحتوي على جدول (أُنشئ في Microsoft Word)، لكن إذا طلبنا من Word إنشاء PDF موسوم فسنرى أن بعض الوسوم الإضافية قد ظهرت في تدفق محتوى الصفحة. هنا، نحن لا ننظر إلا إلى الأسطر القليلة الأولى من تدفق المحتوى (فهناك مئات الأسطر) لكن لاحظ وجود معاملات إضافية مثل `/P <</MCID 0>> BDC` و `EMC` والتي تُستخدم لتحديد تسلسل محتوى موسوم. لن نستعرض الصياغة الكاملة لتسلسلات المحتوى الموسوم، بل نحيل القارئ إلى الصفحة 862 من [مواصفة Adobe الرسمية لـ PDF 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf).

![صورة تُظهر تسلسلات المحتوى الموسوم في تدفق محتوى PDF موسوم](/files/f424773740227e69aacf8a262722894cae8906af)

ولتيسير الرجوع، نعرض النسخة غير الموسومة مرة أخرى:

![صورة تُظهر تدفق محتوى PDF](/files/5460c5e0138e2359d899b2282a7439028694a750)

في *غير موسوم* من PDF، فإن معاملات مثل `/P <</MCID 0>> BDC` و `EMC` غير موجودة، لكن المعاملات المتبقية لم تتغير: يفتقر PDF غير الموسوم إلى الوسوم الإضافية المستخدمة لتحديد بعض تسلسلات/مجموعات المعاملات. ومرة أخرى يمكننا أيضًا استخدام ميزة Adobe Acrobat *البنية الداخلية لـ PDF* لعرض تسلسلات المحتوى الموسوم داخل تدفق المحتوى — وهنا قمنا بإبرازها بإطار أخضر:

![صورة تُظهر تسلسلات المحتوى الموسوم في تدفق محتوى PDF موسوم كما تُعرض في Adobe Acrobat Pro DC](/files/078c3c395d34598a87595c05b92a6bf276b3c46b)

لاحظ أن بعض أجزاء المحتوى موسومة بـ `/Artifact` والذي يحدد المواد الموجودة على صفحة PDF التي ينبغي أن تكون *متجاهلة* من قبل تطبيقات البرمجيات المساعدة، مثل تلك التي تقرأ بصوت عالٍ للأشخاص ذوي الإعاقة البصرية.

تُظهر لقطة الشاشة التالية عرضًا موسعًا لتسلسل المحتوى الموسوم الأول — وهو الذي يحمل `MCID` قيمة `0`. ويُحدَّد نهاية تسلسل المحتوى الموسوم بواسطة معامل PDF `EMC`.

![صورة تُظهر تفاصيل المعاملات التي يضمها تدفق محتوى موسوم](/files/af47eca0475bac46e0e3c486420cc5498895ff2d)

### تخزين البنية المنطقية

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

#### البنية المنطقية: «شجرة» من عناصر البنية

أشرنا إلى أن ملفات PDF تستخدم شيئًا يسمى *عنصر بنية* لتمثيل عناصر المحتوى الفردية، وأن عنصر البنية يحتوي على وسم لتحديد نوع المحتوى الذي يمثله. ولتوفير تمثيل للبنية المنطقية للمستند، تُربط جميع عناصر البنية معًا باستخدام علاقات الأب—الابن، وتُنظم في «شجرة بنية». وداخليًا، تحتوي ملفات PDF الموسومة على كائن يسمى `StructTreeRoot` والذي يحتوي على (ويشير إلى) عناصر بنية تعمل كنقطة البداية أو «الجذر» لشجرة البنية المنطقية للمستند. وعادةً ما يبدأ «جذر» شجرة البنية بعنصر بنية واحد موسوم بـ `Document` والذي يحتوي على العديد من *فرعية* عناصر بنية تمثل، مجتمعةً، كامل محتوى المستند. يجب على أي برنامج مصمم لإنتاج ملفات PDF قابلة للوصول عبر الوسم أن يبني هذه البنية المعقدة جدًا للبيانات (وغيرها أيضًا!) — وهذا يشمل محركات TeX وLaTeX.

مثال على شجرة بنية مستند من هذا النوع (`StructTreeRoot`) يظهر في لقطة الشاشة التالية لملف PDF موسوم مفتوح في Adobe Acrobat Pro DC:

![صورة تُظهر StructTreeRoot في ملف PDF موسوم](/files/86e3eaeee21fcb44d2c6f7ac5a037e42b490db50)

قارن البنية أعلاه بالإصدار غير الموسوم من PDF:

![صورة تُظهر غياب StructTreeRoot في ملف PDF غير موسوم](/files/9c40ecef17258230dc530b0158acfc8247cfe930)

### استكشاف البنية المنطقية لملفات PDF

نبدأ ببعض الرسوم لتلخيص ما تناولناه ونختتم بفيديو يستخدم Adobe Acrobat Pro DC لإظهار مزيد من التفاصيل حول البنية المنطقية لملف PDF موسوم. أولًا، نبدأ بمخطط يوضح المبادئ العامة: صفحة PDF مع تدفق محتواها الموسوم بتسلسلات المحتوى الموسوم (MCS).

![رسم يوضح مفهوم تسلسلات المحتوى الموسوم في صفحات مستند PDF](/files/77f32e4ee004ae662d52e5c7f970d39cae2cfedb)

تُجمَّع تلك التسلسلات الموسومة لاحقًا في *عناصر البنية* والتي تشكل الأساس لأنواع محتوى أكبر، تُربط هي نفسها لاحقًا معًا لتخزين البنية المنطقية لـ PDF داخل كائن يسمى `StructTreeRoot`.

![رسم يوضح البنية المنطقية لملف PDF موسوم](/files/97ea58f2eb33083162c1f6bc4ceee7d7d14ea2ce)

#### فيديو يوضح البنية المنطقية لملف PDF موسوم

يستخدم الفيديو التالي (8 دقائق) Adobe Acrobat Pro DC ليأخذك في «جولة إرشادية» لاستكشاف تفاصيل البنية المنطقية لملف PDF موسوم أُنتج باستخدام LaTeX. يُسمى ملف PDF الموسوم المستخدم في الفيديو `tagpdf.pdf`، وهو مثال ممتاز يتضمن توثيقًا لحزمة LaTeX التجريبية [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). وهدف `tagpdf` الحزمة هو توفير «أدوات للتجريب في الوسم وإمكانية الوصول باستخدام pdfLaTeX وLuaTeX».

{% embed url="<https://videos.ctfassets.net/nrgyaltdicpt/2rD5DE49Ae27ENZ2bbnQhw/db5818f642afc48e78598ccd9b979a21/AcrobatPro.mp4>" %}

### ملاحظة حول الوسم والمرونة

توفر مواصفة HTML عددًا كبيرًا من الوسوم المعرّفة مسبقًا لاستخدامها في بناء صفحات الويب، لكنها تتيح أيضًا مرونة في كيفية جمعها لإنشاء مستند HTML الذي تختاره. وبالمثل، توفر مواصفة PDF الموسوم من Adobe مجموعة من أسماء الوسوم المعرّفة مسبقًا لكنها تفرض قيودًا قليلة جدًا على كيفية دمج تلك الوسوم لتمثيل عناصر محتوى معقدة داخل PDF — فبحكم التصميم، هناك قدر كبير من المرونة. بالإضافة إلى ذلك، ومع أي مواصفة ضخمة ومعقدة مثل PDF، من الحتمي أن تتسلل بعض أوجه الغموض أو مشكلات الوضوح إلى المواصفة المكتوبة. وقد يضطر مطورو البرمجيات المكلفون بتنفيذ مواصفة معقدة كهذه إلى اتخاذ «قرارات تقديرية» عند تفسيرها لأنهم يواجهون تحويل الأوصاف المكتوبة إلى شيفرة عاملة.

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

وربما انعكاسًا للتعقيدات التي لا مفر منها في إنتاج ملفات PDF موسومة تتوافق بالكامل مع معايير إمكانية الوصول، يزخر الويب بـ«كيفية القيام بذلك» و«نصائح» و«أفضل الممارسات» المتعلقة بإنشاء ملفات PDF موسومة عبر برامج مثل Adobe InDesign أو Microsoft Word. بالإضافة إلى ذلك، أصدرت PDF Association وثيقة مفيدة تسمى [دليل أفضل الممارسات لـ PDF الموسوم](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) كُتبت لمساعدة المطورين الذين يواجهون تحديات تنفيذ PDF الموسوم وPDF/UA.

## لديك PDF، لكن هل يمكن الوصول إليه؟

لتحديد ما إذا كان ملف PDF معين يلتزم بمعايير إمكانية الوصول المطلوبة مثل PDF/A أو PDF/UA (انظر أدناه) فيجب أن يكون قد *تم التحقق من صحته* تم التحقق منه باستخدام عملية تحقق أو أداة برمجية متفق عليها. لكن التحقق يحدث عادةً بعد اكتمال المستند، وقد لا يجريه مؤلف المستند بل متخصصون في إمكانية الوصول داخل المؤسسة أو الجهة التي طلبت الامتثال. إذا فشل PDF في التحقق فقد يحتاج إلى تدخل يدوي ماهر عبر Adobe Acrobat Pro DC لإصلاح الوسم (إن أمكن). وبديلًا عن ذلك، قد يتعين إعادته إلى المؤلف لتعديل مستنده الأصلي، ربما من خلال تجنب استخدام ميزات برنامج الإنشاء التي سببت المشكلات — وهو ما قد يكون شديد الصعوبة لأنه قد يتجاوز سيطرة المؤلف.

### ترتيب القراءة وترتيب المحتوى

كما أشرنا، فإن إنتاج ملفات PDF قابلة للوصول حقًا يفرض متطلبات تقنية إضافية على برنامج الإنشاء، وربما على مؤلفي المستندات أيضًا من خلال فرض «انضباط في التأليف» في كيفية استخدامهم/تطبيقهم لميزات برنامج الإنشاء. وعلى الرغم من أن PDF الموسوم هو الآلية التي *تمكّن* إنتاج ملفات PDF قابلة للوصول بالكامل، فإن كون ملف PDF موسومًا لا *تحتوي* يعني تلقائيًا أنه قابل للوصول بالكامل، كما سنرى في مثال أدناه.

ولإنتاج ملفات PDF قابلة للوصول بالكامل، ينبغي وسم جميع عناصر المحتوى في ملف PDF لإنشاء بنية منطقية تضمن إمكانية الوصول إلى المحتوى وقراءته بالتسلسل الصحيح — ويُسمّى ذلك *ترتيب القراءة*قد يبدو هذا «بديهيًا»، ولكن عندما يكتب البرنامج ملف PDF يمكنه إخراج الرسومات والنص إلى تدفقات محتوى الصفحة بأي ترتيب يختاره. فعلى سبيل المثال، لنفترض أن صفحة تبدأ ببعض النص، تليها جدول وتنتهي برسم، مما يمنح *ترتيب القراءة* ترتيبًا طبيعيًا لـ:

1. نص
2. table
3. رسم

وعند كتابة ذلك إلى PDF، قد يبدأ البرنامج الذي يُنشئ تدفق محتوى لتلك الصفحة بمعاملات لرسم الجدول، ثم يُخرج معاملات لإنتاج الرسم يليها معاملات للنص، وهو ما سينتج في تدفق المحتوى *ترتيب المحتوى* ترتيبًا طبيعيًا لـ:

1. table
2. رسم
3. نص

بطبيعة الحال، سيُوضَع كل شيء في الموضع الصحيح عند عرض تلك الصفحة. وبالنسبة لقارئ مبصر بالكامل، لا يهم ترتيب تخزين تلك العناصر داخل تدفق محتوى الصفحة: فهو يرى صفحة معروضة كاملة بكل شيء في موقعه الصحيح.

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

> «...أن يكون ترتيب وتعشيق عناصر المحتوى المنطقي مستقلين تمامًا عن ترتيب وموقع كائنات الرسومات على صفحات المستند.» (الصفحة 856 من [The PDF Reference، الطبعة السادسة، نوفمبر 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf))

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

#### ترتيب قراءة غير صحيح: مثال باستخدام Microsoft Word

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

![صورة لجدول أُنشئ في Microsoft Word](/files/61f33e717bba7e26e6af3d967ffaa521cf0fad23)

إذا طلبنا من Word حفظ هذا المستند إلى PDF باستخدام ميزة التصدير المدمجة لديه — وليس مكوّن Acrobat PDFMaker الإضافي — فيمكننا أن نطلب منه إنشاء PDF موسوم:

![مربع حوار الخيارات في عملية التصدير الخاصة بـ Microsoft Word](/files/29091607474c3f3a513294df7c40de2388073ed1)

إذن، كيف يوسم Word هذا التخطيط؟ في الفيديو القصير التالي جدًا (14 ثانية) نستخدم Adobe Acrobat Pro DC لفحص بنية الوسم التي أنشأها Microsoft Word.

{% embed url="<https://videos.ctfassets.net/nrgyaltdicpt/1PXPgk2ZL8mgO00cKpVzGe/a704d6bcefd808713cd80febee867a58/WordTable.mp4>" %}

لهذا المستند، أنشأ Word مستند PDF موسومًا يستخدم `Table` وسمًا يحتوي على وسمين فرعيين: `THead` لمجموعة صف رأس الجدول و `TBody` لتمثيل مجموعة الصفوف لجسم الجدول. `THead` و `TBody` كلاهما يحتوي على `TR` وسوم لتمثيل الصفوف الفردية من المحتوى. تحتوي `TR` الوسوم على وسوم إضافية لتمثيل عنصر القائمة المرقم الموجود في كل خلية. تُظهر صورة الشاشة التالية بنية الوسم المتداخلة بعمق والبنية المنطقية المعقدة المقابلة اللازمة لتمثيل حتى هذا المستند البسيط للغاية!

![صورة تُظهر بنية وسم متداخلة بعمق والبنية المنطقية لجدول بسيط تم إنشاؤه في Microsoft Word](/files/58deca3fcacbbe6aa24442608c5725c2c8750e09)

مقارنةً بملفات PDF التي يُنشئها TeX وLaTeX، فإن هذا المثال من Word مستند بسيط للغاية، لكنه لا يزال يتطلب بنية منطقية معقدة لتمثيله. تخيل مستوى تعقيد الوسم المطلوب لتمثيل ملفات PDF التي يولدها LaTeX وتحتوي على رياضيات وجداول معقدة!

#### موسوم، نعم، لكن ترتيب القراءة غير صحيح

على الرغم من أن Word يُنتج [PDF الموسوم](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) فهو يوضح أحد التحديات الأساسية التي تواجه أي تطبيق يحاول إنتاج ملفات PDF قابلة للوصول بالكامل: تمثيل ترتيب القراءة المقصود للمحتوى بشكل صحيح. أثناء إنشاء PDF الموسوم، قررت العمليات الداخلية في Word كتابة تيار المحتوى المقابل عن طريق إخراج الجدول على أساس صفًا بصف، وليس عمودًا بعمود. بالنسبة لقارئ مبصر بالكامل يعرض ملف PDF، لا تُحدث هذه التفاصيل منخفضة المستوى أي فرق: يُعرض الجدول بشكل صحيح. ومع ذلك، بالنسبة للأشخاص ذوي الإعاقة البصرية، تنتج البنية المنطقية للمستند في Word نتيجة خاطئة لأن ترتيب القراءة المطلوب (عمودًا بعمود) لا يُحافَظ عليه: إذ تتم قراءة المحتوى بصوت عالٍ بالترتيب الخاطئ.

تم إنتاج التسجيل الصوتي التالي باستخدام ميزة «القراءة بصوت عالٍ» في Adobe Reader DC. وكما هو واضح، يُقرأ النص بالتسلسل الخاطئ: صفًا بصف، وليس عمودًا بعمود:

![جدول تم إنشاؤه في Microsoft Word](/files/448137b1898b056210c181bfb2a559b49f66c612)

كما ذُكر أعلاه، هذا المثال مُصطنع إلى حد ما، لكنه يوضح مدى سهولة تطبيق مجموعات من ميزات البرامج التي تؤدي إلى مشكلات في إمكانية الوصول — ولكن كيف يُفترض بمؤلف المستند أن يعرف هذا مسبقًا؟ من المحتمل ألا يُكتشف هذا الأمر إلا إذا خضع ملف PDF الناتج لاختبارات استخدام عملية لإمكانية الوصول — على سبيل المثال، باستخدام برامج مساعدة. ومن المحتمل أن تجتاز مثل هذه المستندات اختبارات التوافق/التحقق من PDF/A لكنها تفشل في الاستخدام «العالمي» الحقيقي. إن ضمان ترتيب القراءة الصحيح لملف PDF مثل هذا سيتطلب تدخلًا يدويًا ماهرًا باستخدام أدوات تحرير PDF متقدمة مثل Adobe Acrobat Pro DC: وهي عملية تستغرق وقتًا طويلًا ومكلفة. وبديلًا عن ذلك، يمكن لمؤلف المستند الامتناع عن استخدام هذا الشكل المحدد من التعبير عن المحتوى أو التخطيط — ولكن فقط إذا كان يعرف أنه يسبب مشكلة!

### استخدام محارف المسافة لفصل الكلمات

عند كتابة النص في معالجات الكلمات أو محررات النصوص، تستخدم محرف المسافة لتمييز نهاية كلمة وبداية الكلمة التالية. إذا أنشأت لاحقًا ملف PDF من مستند كهذا، فإن محارف المسافة التي كتبتها ستظهر بالطبع وتصبح جزءًا من النص المخزن في PDF. ومع ذلك، لا تستخدم محركات TeX محارف المسافة لفصل الكلمات في النص المُنسَّق؛ بل إنها تحول محارف المسافة إلى شكل من أشكال التباعد المرن يُسمى glue (انظر هذا [مقالة Overleaf](/latex/ar/mqalat-mtamqh/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) للمزيد من المعلومات عن صناديق TeX وglue).

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

لهذا الجانب من التنضيد في TeX آثار على نسخ/لصق النص من ملفات PDF الخاصة به وعلى البرامج المساعدة التي تحاول قراءة النص المنسق بصوت عالٍ في ملفات PDF الناتجة عن محركات TeX. يجب على البرامج المساعدة تحليل تيار المحتوى لصفحة PDF لاستخراج النص الذي تحتاج إلى معالجته. ومن الواضح أن مثل هذه البرامج تحتاج إلى آلية ما لاكتشاف بداية الكلمات ونهايتها — وأوضح حل هو استخدام محرف مسافة. ومع أخذ ذلك في الاعتبار، تتطلب معايير إمكانية الوصول أن تُنهى الكلمات الفردية بوضوح (مثلًا بمحارف المسافة)، وهو أمر إشكالي لمحركات TeX بسبب استخدامها glue بين الكلمات.

#### لكن ليس كل شيء ضائعًا!

في عام 2014 قدّم pdfTeX بدائيين جديدين لتحسين دعم إمكانية الوصول من خلال تمكين استخدام محارف المسافة بين الكلمات في ملفات PDF التي يُخرجها:

* `\pdfinterwordspaceon`
* `\pdfinterwordspaceoff`

تستخدم هذه الأوامر «خطًا وهميًا» يحتوي فقط على رمز للمسافة. يمكن العثور على التفاصيل ومثال في الصفحة 29 من [دليل مستخدم pdfTeX](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf).

#### استخدام LuaTeX: مثال في معرض Overleaf

لا يدعم LuaTeX تلك البدائيات الخاصة بـ pdfTeX، لكنه يمكن برمجته لتحقيق نتائج مشابهة جدًا لـ pdfTeX باستخدام آلية الاستدعاءات المعروفة في LuaTeX. يتوفر مشروع Overleaf لتحويل glue إلى محارف مسافة في معرض Overleaf تحت عنوان [استخدام LuaTeX لتحويل glue بين الكلمات إلى مسافات وkerns](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv).

إذا قمت بتنسيق كود LaTeX الخاص بك باستخدام LuaTeX (أي خيار المترجم LuaLaTeX على Overleaf) فيمكنك، باستخدام كود Lua، معالجة فقرة منسقة لاحقًا للعثور على أي glue بين الكلمات واستبداله بمحرف مسافة بالإضافة إلى kern مناسب. ويمكن إضافة (أو تقليل) التباعد الذي يوفره عرض محرف المسافة بحساب قيمة kern مناسبة للحفاظ على مقدار المسافة التي يوفرها glue بين الكلمات، مما يؤدي إلى عدم وجود فرق بصري في نتيجة التنضيد.

لفهم الفرق الذي يحدثه هذا لمستخدمي برامج إمكانية الوصول، استمع إلى هذا التسجيل الصوتي الملتقط من ميزة Adobe Reader DC *القراءة بصوت عالٍ* يُسجل سطري النص في ذلك المشروع وهما يُقرآن بصوت عالٍ، قبل وبعد تحويل glue إلى مسافات. لاحظ كيف يُقرأ السطر الثاني، الذي يستخدم المسافات، بصوت عالٍ بسرعة وسلاسة مقارنة بالسطر الذي يستخدم glue بين الكلمات.

مشروع Overleaf هو ملف TeX بسيط مُجمَّع باستخدام LuaTeX ومقدم للاستخدام التجريبي فقط؛ وليس المقصود منه أن يكون حلاً كاملًا أو جاهزًا للإنتاج. وهو مصمم أساسًا للمساعدة في فهم القضايا التقنية المتعلقة بملفات PDF القابلة للوصول. ويعتمد كود Lua المستخدم في ذلك المشروع على عمل موجود في مقال Overleaf أقدم بكثير [الصناديق والغراء: مقدمة موجزة، لكنها مرئية، باستخدام LuaTeX](/latex/ar/mqalat-mtamqh/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md).

ملاحظة: من أجل البساطة، يستخدم المشروع محمّل خطوط OpenType شديد البساطة خاصًا به، مشتقًا من هذا الكود: <http://wiki.luatex.org/index.php/Use_a_TrueType_font>.

### مشكلات أخرى في إمكانية الوصول وPDF الموسوم

على الرغم من أن الوسم يتيح التعرف على عناصر المحتوى الموجودة داخل ملف PDF، فإن بعض أنواع المحتوى، مثل الرسومات أو الرياضيات المعقدة، تتطلب بيانات أو معلومات إضافية إذا أُريد جعلها قابلة للوصول عبر برامج مصممة لدعم الأشخاص ذوي الإعاقة البصرية. ولتوفير ودعم إمكانية الوصول لمجموعة واسعة من أنواع المحتوى، تتيح مواصفات PDF إمكانية إرفاق «أوصاف بديلة» أو «ActualText» بعناصر المحتوى، مما يوفر أوصافًا نصية مناسبة أو تمثيلات أخرى قابلة للقراءة آليًا. على سبيل المثال، تم اعتماد MathML لهذا الغرض ضمن مواصفة PDF 2.0.

#### هل هو «محتوى حقيقي» أم مجرد أثر؟

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

## نظرة عامة على معايير PDF/A

غالبًا ما تشير طلبات إنتاج ملفات PDF قابلة للوصول إلى معيار ISO يُسمى [ISO 19005](https://www.iso.org/standard/38920.html)، ويُشار إليه أكثر باسم PDF/A. ومع ذلك، لأن PDF/A هو *عائلة* مجموعة من المعايير، فإن مجرد طلب «الامتثال لـ PDF/A» قد لا يحدد المتطلبات الفعلية بالكامل. ولرؤية السبب، لنبدأ بمخطط قصير لـ PDF/A من [موقع جمعية PDF](https://www.pdfa.org/resource/iso-19005-pdfa/) (تم الوصول إليه في 21 مايو 2020) الذي يصف ISO 19005 (PDF/A) على النحو التالي:

> «الهدف الرئيسي من ISO 19005 هو تعريف تنسيق ملف يعتمد على PDF، ويُعرف باسم PDF/A، ويوفر آلية لتمثيل المستندات الإلكترونية بطريقة تحافظ على مظهرها البصري الثابت عبر الزمن، بشكل مستقل عن الأدوات والأنظمة المستخدمة لإنشاء الملفات أو تخزينها أو عرضها.
>
> ويتمثل هدف ثانٍ لـ ISO 19005 في تعريف إطار لتمثيل البنية المنطقية وغيرها من المعلومات الدلالية للمستندات الإلكترونية داخل الملفات المتوافقة.
>
> وهناك هدف آخر لـ ISO 19005 هو توفير إطار لتسجيل سياق المستندات الإلكترونية وتاريخها في البيانات الوصفية داخل الملفات المتوافقة.»

من الواضح أن PDF/A له عدة أهداف أساسية.

### تطور ونمو PDF

ال [مواصفة PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) نُشرت في عام 1993 وكانت تحتوي على 230 صفحة فقط. ومع ذلك، بعد 13 عامًا، أصبحت مواصفة [إصدار Adobe من PDF 1.7](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) تتجاوز 1000 صفحة بكثير! ومع مرور الوقت، نما حجم وتعقيد مواصفة PDF من خلال إضافة مزيد إلى مجموعة الميزات المدعومة: لتشمل تقنيات جديدة ومتطلبات سير العمل وحالات الاستخدام القائمة على PDF التي أصبحت أكثر تطورًا ضمن أسواق ومجتمعات مختلفة. ومع ذلك، فمن غير المرجح أن أي مستخدم، أو مجموعة من المستخدمين، تستفيد من كل الإمكانيات: يجب على PDF أن «يغطي جميع القواعد» للتأكد من أنه يمكنه خدمة احتياجات أوسع سوق ممكنة. فعلى سبيل المثال، كثير من ميزات PDF المصممة لدعم الطباعة التجارية عالية المستوى ليست مطلوبة في الاستخدام المكتبي اليومي المعتاد كتنسيق لتخزين أو مشاركة الوثائق.

### PDF/A: «العودة إلى الأساسيات» في PDF

الهدف الأساسي من PDF/A هو التأكد من أن ملفات PDF المتوافقة مناسبة للأرشفة طويلة الأجل أو تحتوي على محتوى يمكن الوصول إليه بواسطة الأشخاص الذين يستخدمون مختلف تقنيات المساعدة «لاستهلاك» تلك الملفات. ولتحقيق هذه الأهداف، يقيّد PDF/A مجموعة ميزات PDF المسموح بها في ملفات PDF المتوافقة، ويحظر استخدام الميزات التي قد تضر بإمكانية الأرشفة أو إمكانية الوصول. يمكنك التفكير في PDF/A على أنه مجموعة من المعايير التي تحدد كيفية استخدام ملفات PDF المتوافقة *مجموعة فرعية* من المواصفة الكاملة لـ PDF لإنتاج ملفات مناسبة للأرشفة طويلة الأجل أو لضمان إمكانية الوصول إلى محتواها. وتتيح قيود PDF/A استخدام ملفات PDF باعتبارها «ورقًا رقميًا أرشيفيًا» مستقلًا عن تقنية قراءة PDF وبيئة الحوسبة المستخدمة للوصول إلى محتواها. ويجب ألا تحتوي ملفات PDF المتوافقة على أي شيء يكون سلوكه «معتمدًا على التنفيذ» — أي يعتمد على البرامج أو أنظمة التشغيل المحددة المستخدمة لعرضها أو معالجتها. كما يجب أن تكون ملفات PDF أيضًا *مكتملة*: يجب تضمين موارد المستند الأساسية في الملف — مثل الخطوط أو ملفات تعريف الألوان.

### إصدارات PDF/A ومستويات المطابقة

هناك *إصدارات* مختلفة من معيار PDF/A، يعكس كل منها إصدارًا محددًا من مواصفة PDF الرسمية (PDF 1.4 و1.7 و2.0). بالإضافة إلى ذلك، هناك مستويات *مطابقة* تحدد أي جانب/جوانب من معيار PDF/A يتوافق معها ملف PDF. وبالتالي، عند الادعاء أو اشتراط «الامتثال لـ PDF/A» يجب أن تفكر في ملفات PDF التي تتوافق مع

**PDF/A-**

على سبيل المثال

* PDF/A-1a: تعني إصدار PDF/A 1، مستوى المطابقة a
* PDF/A-2b: تعني إصدار PDF/A 2، مستوى المطابقة b

سنستعرض هذه المسائل بمزيد من التفصيل.

#### إصدارات PDF/A

يخضع معيار PDF/A لإشراف ISO، ويُنشر كمعيار يُسمى ISO 19005. وكما ذُكر، تطورت مواصفة PDF مع مرور الوقت، وهذا استلزم بدوره تحديثات لـ ISO 19005، مما أسفر عن الجدول أدناه:

|                 |                  |                        |
| --------------- | ---------------- | ---------------------- |
| **إصدار PDF/A** | **معيار ISO**    | **مبني على إصدار PDF** |
| PDF/A-1         | ISO 19005-1:2005 | PDF 1.4                |
| PDF/A-2         | ISO 19005-2:2011 | PDF 1.7                |
| PDF/A-3         | ISO 19005-3:2012 | IS0 32000-1 (PDF 1.7)  |

في وقت كتابة هذا النص (أبريل/مايو 2020) كان هناك PDF/A-4 محدَّث (ISO 19005-4) [قيد الإعداد](https://www.iso.org/standard/71832.html).

#### مستويات المطابقة في PDF/A

بالإضافة إلى ثلاثة إصدارات من PDF/A (PDF/A-1 وPDF/A-2 وPDF/A-3) هناك ثلاثة *مطابقة*:

* المستوى A (قابل للوصول) لإتاحة الوصول (يتضمن متطلبات الأرشفة الخاصة بالمستوى B)
* المستوى B (أساسي) للأرشفة
* المستوى U (Unicode) (= الأرشفة بالإضافة إلى استخدام Unicode للنص)

فيما يلي وصف قصير لمستويات المطابقة هذه:

* **المستوى B (أساسي)** هو الحد الأدنى من المتطلبات للمطابقة في PDF/A. وهو يحدد متطلبات لضمان أن مستندات PDF المتوافقة مناسبة للأرشفة طويلة الأجل — بحيث يمكن دائمًا عرضها أو طباعتها بشكل موثوق بشكل مستقل عن البرامج أو الأدوات أو أنظمة التشغيل المحددة.
* **المستوى A (قابل للوصول)** يتضمن متطلبات المطابقة للمستوى B، لكنه بالإضافة إلى ذلك يتطلب استخدام PDF الموسوم لتوفير البنية المنطقية ومعلومات ترتيب القراءة إلى جانب استخدام Unicode لتمكين الوصول إلى نص المستند.
* **المستوى U (Unicode)** أُضيفت المطابقة إلى PDF/A-2، وهي تبني على المستوى B من خلال اشتراط استخدام Unicode لنص المستند أيضًا، لكنها لا تصل إلى مستوى A الذي يفرض معلومات البنية.

يمكن تلخيص إصدارات PDF/A ومستويات المطابقة في جدول:

|                         |                                      |          |          |
| ----------------------- | ------------------------------------ | -------- | -------- |
| **مستوى المطابقة**      | **PDF/A-**                           |          |          |
| المستوى A (قابل للوصول) | PDF/A-1a                             | PDF/A-2a | PDF/A-3a |
| المستوى B (أساسي)       | PDF/A-1b                             | PDF/A-2b | PDF/A-3b |
| المستوى U (Unicode)     | لا ينطبق (لم يكن موجودًا في PDF/A-1) | PDF/A-2u | PDF/A-3u |

### PDF/UA («إتاحة الوصول الشاملة»)

على الرغم من أن الامتثال للمستوى A في معيار PDF/A يذهب إلى حد ما نحو تحديد متطلبات ملفات PDF القابلة للوصول، فإن معيار ISO آخر يُسمى [ISO 14289](https://www.iso.org/standard/64599.html)، ويُشار إليه باسم PDF/UA، يذهب أبعد من ذلك. يعزز PDF/UA متطلبات إمكانية الوصول ويوضح الإرشادات الواردة في معايير PDF/A، وقد أصبح المعيار المفضل لملفات PDF القابلة للوصول.

#### بروتوكول Matterhorn

قد يهتم القراء الذين لديهم اهتمام عميق بمعرفة المزيد عن الامتثال لـ PDF/UA بـ [بروتوكول Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) وهو «قائمة بجميع الطرق الممكنة للفشل في الامتثال لـ PDF/UA».

### برامج التحقق

للتحقق مما إذا كان ملف PDF متوافقًا مع معيار معين، يجب أن يتم *تم التحقق من صحته* باستخدام برامج الامتثال التي تمسح ملف PDF للتحقق مما إذا كان محتواه وبنيته يتوافقان مع متطلبات ذلك المعيار — مثل PDF/UA أو PDF/A-*x*a (حيث *x* = 1 أو 2 أو 3). لاحظ أن التحقق من ملفات PDF — أي معالجتها بأداة تحقق مفضلة — يمكن أن ينتج رسائل تشخيصية أو تحذيرات قد تكون غامضة جدًا للمستخدم غير الخبير — ربما بسبب بعض البيانات (أو البنية) منخفضة المستوى في PDF التي لا تفي بالمعيار ذي الصلة. بالنسبة للعديد من المؤلفين، قد يكون تفسير تلك التحذيرات وتحويلها إلى إصلاح عملي لمستنداتهم تحديًا كبيرًا.

#### برامج تحقق مجانية

* [veraPDF](https://verapdf.org/) والذي، وفقًا لموقعهم الإلكتروني (تم الوصول إليه في 28 مايو 2020)، هو «أداة تحقق مخصصة مفتوحة المصدر لصيغة الملفات تغطي جميع أجزاء PDF/A ومستويات المطابقة».
* (لنظام Windows فقط) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) وهو «...أداة مجانية لفحص إمكانية الوصول في PDF تم اختبارها وتجريبها منذ عام 2010».

#### برامج التحقق التجارية

* [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) يوفر مجموعة من اختبارات التحقق من PDF إلى جانب أدوات لتحرير وإصلاح الوسوم في ملفات PDF غير المتوافقة.

### جمعية PDF: مصدر رائع للمعلومات

ال [جمعية PDF](https://www.pdfa.org/) تنتج العديد من *الوثائق الممتازة* الموارد عن PDF/A وPDF/UA والعديد من الموضوعات الأخرى المتعلقة بـ PDF — بما في ذلك مقاطع الفيديو على [قناة YouTube الخاصة بهم](https://www.youtube.com/user/ThePDFAssociation/playlists) إلى جانب المقالات والمنشورات التقنية المجانية المتاحة على موقعهم الإلكتروني. أحد هذه المنشورات هو [PDF/UA in a Nutshell](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) الذي يوفر مقدمة لا تقدر بثمن لمعيار PDF/UA ومتطلباته.

## ملفات PDF القابلة للوصول من محركات TeX وLaTeX

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

كأداة تأليف، يمنح LaTeX المؤلفين مرونة شبه غير محدودة في نطاق المستندات وتعقيدها التي يمكنهم إنشاؤها — وربما يكون هذا هو السبب نفسه لاختياره منذ البداية. يدعم LaTeX أيضًا قابلية التوسعة عبر آلاف الحزم الإضافية التي يمكن للمؤلفين استخدامها ضمن مستنداتهم. وفوق ذلك كله، يتمتع المؤلفون بحرية كتابة وحدات TeX أو LaTeX macros جديدة، أو إعادة تعريف الموجودة منها، لتحقيق تأثيرات محددة. ومع ذلك، ربما يكون لهذه الحرية والمرونة ثمن، لأن المحتوى الناتج عن التفاعلات الهائلة لكل تلك الحزم والـ macros الخاصة بـ LaTeX يحتاج «بشكل ما» إلى تنسيق إذا أُريد لـ LaTeX أن يولد تلقائيًا مخرجات PDF موسومة وقابلة للوصول بشكل صحيح.

عمليًا، فإن قابلية التوسعة والقوة والتنوع و«حرية» التأليف التي يمنحها LaTeX تطرح تحديات تقنية أمام الإنتاج السلس والشفاف («التلقائي») لمستندات PDF موسومة قابلة للوصول بالكامل ومتوافقة مع معايير PDF/UA أو PDF/A-{1|2|3}a. ويبذل مجتمع TeX وLaTeX الأوسع جهودًا كبيرة لمواجهة هذه التحديات، ويقوم The TeX User Group (TUG) بتنسيق جهود البحث والتطوير من خلال إمكانية الوصول إلى PDF وPDF standards [مجموعة العمل](https://www.tug.org/twg/accessibility/). وهناك [قائمة نقاش](https://tug.org/mailman/listinfo/accessibility) توفر وسيلة للأطراف المهتمة لمناقشة إنتاج ملفات PDF موسومة باستخدام TeX وLaTeX.

في هذه المناقشات، من الجدير التذكر أن LaTeX ليس في الحقيقة برنامج تنضيد قابلًا للتنفيذ، بل هو مجموعة كبيرة من الوحدات الماكروية المتطورة (أوامر) مكتوبة بلغة أدنى تُسمى TeX. وبين مستند LaTeX المصمم بعناية وملف PDF المنضد النهائي توجد قطعة برمجية تُسمى محرك TeX، ومهمتها «تنفيذ» مجموعة أوامر LaTeX (أي الوحدات الماكروية) المستخدمة لكتابة وبناء مستندك — وتحويلها إلى التمثيل المنضد لمستندك المحفوظ كملف PDF. غالبًا ما يشعر القادمون الجدد إلى منظومة TeX/LaTeX بالحيرة، وهذا مفهوم، بسبب كثرة الأسماء الغامضة التي يواجهونها للأدوات: TeX، LaTeX، pdfTeX، pdfLaTeX، XeTeX، XeLaTeX، LuaTeX وLuaLaTeX. إذا شعرت بالمثل، فهناك مساعدة متاحة في مقال Overleaf [ما في الاسم: دليل إلى الأنواع العديدة من TeX](/latex/ar/mqalat-mtamqh/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) الذي يشرح أصل ومعنى كل تلك المصطلحات.

محركات TeX مثل pdfTeX أو XeTeX أو LuaTeX هي فئة من البرمجيات تُسمى *مترجمات المستندات*: فهي تأخذ كود LaTeX الخاص بك وتترجمه إلى شكله المنضد عن طريق «تحويل» وحدات LaTeX الماكروية (الأوامر) مرة أخرى إلى تعليمات لغة TeX منخفضة المستوى، والتي يتم «تنفيذها» لإنتاج النتيجة المنضدة. إن أنظمة التنضيد القائمة على TeX قادرة على إنتاج محتوى معقد للغاية — بما في ذلك الرياضيات المتقدمة، والترميز الموسيقي، والبنى الكيميائية، والرسومات، والنص متعدد اللغات المتقدم. ولضمان امتثال تلك المستندات المعقدة لمعايير ولوائح إمكانية الوصول، تحتاج محركات TeX، إلى جانب مجموعة ماكرو LaTeX وحزم LaTeX، إلى توليد ملفات PDF موسومة بشكل مناسب من خلال تضمين قدر كبير من البيانات الإضافية في ملفات PDF التي تنشئها.

على الرغم من أن محركات TeX يمكنها إنشاء ملفات PDF معقدة للغاية، فإن عملياتها وخوارزمياتها ووظائفها الداخلية لا تحتوي على *الدعم* ميزات *مصممة خصيصًا* لدعم إنتاج ملفات PDF موسومة وقابلة للوصول. وبدلًا من ذلك، يجب تحقيق دعم الوسم وإمكانية الوصول عبر برمجة ماكرو معقدة «تُدرِج» بيانات إضافية في ملفات PDF التي تنشئها محركات TeX — لتنشئ تسلسلات المحتوى المعلَّم وعناصر البنية وهياكل البيانات المنطقية المخزنة في `StructTreeRoot`. وهنا تصبح تلك «العملية التنسيقية» في بؤرة التركيز: يجب أن تتعاون التعليمات البرمجية داخل النواة الأساسية لـ LaTeX مع التعليمات البرمجية في آلاف الحزم وعدد لا يحصى من الماكروات التي ينشئها المؤلفون بعناية فائقة لضمان أن يؤدي تنفيذ الماكروات إلى وسم صحيح لمحتوى المستندات الناتجة. ويجب أن تكون تلك «العملية التنسيقية» موثوقة — مهما كانت الطريقة التي يختار بها المؤلفون الجمع بين ميزات LaTeX وأوامره ووظائفه، ونظام الحزم الخاص به، وقوة ماكروات TeX.

### احتياجات المؤلفين

بالنسبة لمعظم الناس، لا يعد LaTeX سوى أداة تتيح لك إنشاء مستندات منسقة بشكل جميل مع حرية اختيار الحزم التي تساعدك على تحقيق ذلك. الغالبية العظمى من مؤلفي LaTeX يريدون ببساطة أن «يعمل» مستندهم: أن يُنسَّق دون أخطاء لكي يتمكنوا من تقديم الأطروحة أو المقال أو التقرير أو إنهاء ذلك الكتاب المنتظر منذ زمن طويل. وليس من غير المعقول أن يتوقع مستخدمو LaTeX أن تتعايش مجموعة الحزم التي اختاروها بسلام، وأن تتفاعل معًا بسلاسة وشفافية لتوفير الأوامر والميزات اللازمة لإنتاج مستنداتهم. ومن المرجح أن تظهر تلك الرغبات نفسها عند مواجهة متطلب إنتاج PDF موسوم من LaTeX: ينبغي أن «يعمل فقط»، بشفافية ومع تدخلٍ أدنى من المؤلف. ولسوء الحظ، ما زلنا بعيدين عن تجربة «ها هي! يحدث الوسم مهما فعلت من أشياء غريبة». إن ربط المتطلبات التقنية لإمكانية الوصول مع PDF الموسوم وحرية التأليف في LaTeX أمر معقد بطبيعته، وربما لا مفر من وجود نوع من «انضباط المؤلف» إذا أريد لهذه التحديات التقنية أن تصبح قابلة للتنفيذ العملي والحل.

ومسألة أخرى منفصلة، لكنها ذات صلة، هي أن الوسم غير الصحيح قد لا يكون له أي أثر بصري على ملف PDF النهائي: فقد يبدو بصريًا مثاليًا، وربما يُطبع أيضًا دون مشكلات، لكن دون علم المؤلف، قد يكون الوسم «معطوبًا»، ولا يُكتشف إلا من خلال فشل لاحق في اختبارات الامتثال/التحقق من PDF/A و/أو عبر مزيد من الاختبارات العملية باستخدام برامج إمكانية الوصول مثل قارئات الشاشة.

### ملفات PDF المنتجة على Overleaf

يوفر Overleaf لمجتمع مستخدميه محرر LaTeX قائمًا على المتصفح إلى جانب أدوات إدارة المشاريع والمستندات التي تسهّل التأليف التعاوني — وكل ذلك مبني فوق تثبيت TeX Live قياسي. عمليًا، يتيح Overleaf للمستخدمين «تشغيل LaTeX عن بُعد» عبر متصفح ويب، موفرًا طبقة عزل عن تعقيدات إدارة وصيانة نظام TeX Live كامل.

تتمثل إحدى نتائج استخدام Overleaf لتثبيت TeX/LaTeX قياسي في أن ملفات PDF الناتجة من كود LaTeX المكتوب في محرر Overleaf تُنشأ باستخدام التقنيات نفسها الموجودة تمامًا في أي تثبيت TeX Live آخر من الإصدار نفسه — بما في ذلك الإعدادات التي يثبتها المستخدمون على أجهزتهم المحلية. والفرق الوحيد هو أن محركات TeX التي تترجم وتعالج كود LaTeX الخاص بـ Overleaf تعمل على خوادم بعيدة، وليس على الأجهزة المحلية. يقوم Overleaf بتسطيح PDF الناتج عن TeX من أجل التحميل/العرض الفعال في المتصفح، لكن تلك العملية لا علاقة لها بإمكانية الوصول إلى محتوى PDF نفسه.

يعتمد إنتاج ملفات PDF قابلة للوصول عبر Overleaf على القدرات والميزات المضمنة في محركات TeX القياسية إلى جانب توفر حزم ماكرو LaTeX المناسبة التي يمكن للمستخدمين توظيفها كجزء من مستندهم. يجب أن تظل مستندات LaTeX المنشأة باستخدام Overleaf متوافقة مع تثبيتات TeX وLaTeX الأخرى لأن المستخدمين غالبًا ما يحتاجون إلى تصدير مشروع LaTeX الخاص بهم من Overleaf لتقديمه إلى مجموعة واسعة من أنظمة المجلات لدى الناشرين. إن إدخال ميزات خاصة بـ Overleaf في مستندات LaTeX الخاصة به، أو في محركات TeX الأساسية، من شأنه أن يعيق بشدة حرية المستخدمين في استخدام عملهم في مكان آخر.

يدرك Overleaf ويدعم الحاجة إلى ملفات PDF قابلة للوصول بالكامل ومولدة من أنظمة التأليف TeX/LaTeX: نحن نستثمر الوقت في البحث في مشكلات إمكانية الوصول، واستكشاف أحدث التطورات في محركات TeX وحزم LaTeX التجريبية التي تدعم PDF الموسوم. وفي نهاية المطاف، وفي وقت كتابة هذا النص، لا يوجد حل «جاهز من الصندوق» يمكن لمؤلفي LaTeX استخدامه (عبر `\usepackage`) لتوليد ملفات PDF قابلة للوصول بالكامل ومتوافقة مع PDF/UA من مستندات LaTeX عامة بشكل سلس وشفاف. وعندما تتوفر تلك الحلول من خلال تحديثات TeX Live، فستصبح بالطبع متاحة لمجتمع مستخدمي Overleaf.

### بعض حزم LaTeX لاستكشاف الوسم وإمكانية الوصول

بالنسبة لكثير من الناس، [tex.stackexchage](https://tex.stackexchange.com/) هو الوجهة الأولى لطلب المساعدة في TeX أو LaTeX أو ConTeXt. إنه مورد مذهل ويحتوي على الكثير من الأسئلة حول موضوع [إمكانية الوصول](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) والإنتاج من خلال LaTeX لملفات PDF قابلة للوصول. إذا قرأت هذه الأسئلة وتصفحتها، ثم سلسلة الإجابات والتعليقات اللاحقة، فلن يكون هناك إلا استنتاج واحد لا مفر منه: في الوقت الحالي لا يوجد حل كامل بمستوى الإنتاج لإنشاء ملفات PDF موسومة قابلة للوصول بالكامل ومتوافقة مع المعايير بشكل تلقائي من كل نوع من مستندات LaTeX. ومع ذلك، توجد بعض الحزم التي تدعم الوسم — وإن كان ذلك ربما ضمن نطاق محدود من حالات الاستخدام وأنواع المستندات. تُقدَّم القائمة التالية للقراء الراغبين في استكشاف وسم PDF القائم على LaTeX:

* [`tagpdf` الحزمة](https://ctan.org/pkg/tagpdf) (Ulrike Fischer): حزمة عالية القدرة مصممة للتجريب في وسم PDF. تدعم pdfTeX وLuaTeX وتوفر وثائق مفيدة ومثيرة للاهتمام للغاية تحتوي على ملاحظات ممتازة حول التحديات التقنية لإنشاء ملفات PDF موسومة عبر محركات TeX؛ وهي قراءة موصى بها بشدة لأي شخص مهتم بفهم القضايا المطروحة بشكل أفضل. ومن المرجح أن يكون التركيز المستقبلي على LuaTeX.
* [`axessibility` الحزمة](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov وجامعة تورينو): توفر الوصول إلى الصيغ في ملفات PDF بواسطة التقنيات المساعدة.
* [`إمكانية الوصول` الحزمة](https://ctan.org/pkg/accessibility) (Andy Clifton): تنشئ ملفات PDF موسومة ومنظمة. وتذكر ملاحظات CTAN أن هذه الحزمة «موجهة لمستخدمي فئات مستندات KOMA-Script».
* [`accsupp` الحزمة](https://ctan.org/pkg/accsupp) (Heiko Oberdiek): حزمة تجريبية لتوفير دعم أفضل لإمكانية الوصول لملفات PDF.

مرجع آخر جدير بالملاحظة هو ورقة بحثية من عام 2018 [تطبيق معايير PDF للنشر الرياضي](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) بقلم الدكتور Ross Moore من قسم الرياضيات بجامعة Macquarie. وفي تلك الورقة يضمّن الدكتور Moore مخططًا موجزًا للتحديات المتعلقة بوسم ملفات PDF في LaTeX:

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

والدكتور Moore أيضًا هو الصيانة الحالية لـ [`pdfx`](https://ctan.org/pkg/pdfx) الحزمة وهو خبير ورائد في PDF الموسوم باستخدام TeX/LaTeX. وجدير بالبحث في أعماله — بما في ذلك هذا الفيديو على YouTube الذي يقدم رؤى مثيرة للاهتمام:

{% embed url="<https://www.youtube.com/embed/mPBtkCsChJw>" %}

#### ملاحظة حول حزمة pdfx

ال [`pdfx`](https://ctan.org/pkg/pdfx) تقدم الحزمة (Ross Moore وآخرون) دعمًا ممتازًا لـ PDF/A-1|2|3b (الأرشفة)، وخيارات أخرى، لكنها لا تنتج PDF موسومًا بعد.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/ar/mzyd-mn-almwdhwaat/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
