> 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/18-how-overleaf-created-the-tex-primitive-reference-data.md).

# كيف أنشأ Overleaf بيانات مرجع بدائيات TeX

تصف هذه المقالة الأساليب والتقنيات المستخدمة لإنتاج جدولي المرجع المتقاطع لأوامر TeX البدائية:

* [أوامر TeX البدائية المدرجة حسب محرك TeX](/latex/ar/mzyd-mn-almwdhwaat/46-tex-primitives-listed-by-tex-engine.md) و؛
* [أوامر TeX البدائية المدرجة حسب محرك TeX الخاص بـ CJK](/latex/ar/mzyd-mn-almwdhwaat/45-tex-primitives-listed-by-cjk-tex-engine.md).

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

## نسخة موجزة/نظرة عامة

لإنشاء جدول المرجع المتقاطع، عالجت Overleaf الشيفرة المصدرية لـ 9 محركات TeX لاستخراج قائمة الأوامر البدائية التي يدعمها كل واحد منها: وأنتجت تلك العملية 9 ملفات نصية (ملف واحد لكل محرك TeX). جُمعت تلك المجموعات التسع من الأوامر البدائية لإنشاء «قائمة رئيسية» كانت، في الواقع، اتحادًا للمجموعات الفردية من الأوامر البدائية: ما أسفر عن إجمالي يقارب 1000 أمر بدائي فريد موزعة عبر المحركات المختلفة. ولكل محرك، جرى إجراء مرجع متقاطع لقائمته الخاصة من الأوامر البدائية مقابل الملف الرئيسي (مجموعة جميع الأوامر) لتحديد أيٍّ من تلك الأوامر البالغ عددها نحو 1000 كان يدعمه: وتُعرض تلك المقارنات في الجدولين التاليين:

* [بيانات المرجع المتقاطع لأوامر TeX البدائية](/latex/ar/mzyd-mn-almwdhwaat/46-tex-primitives-listed-by-tex-engine.md)
* [بيانات المرجع المتقاطع لأوامر TeX البدائية (للمحركات الخاصة بـ CJK)](/latex/ar/mzyd-mn-almwdhwaat/45-tex-primitives-listed-by-cjk-tex-engine.md)

## «بناء البرمجيات» 101: ماذا يعني ذلك؟

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

## النسخة الكاملة: هل تريد التفاصيل؟ تابع القراءة...

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

تُضمَّن الأوامر البدائية لمحرك TeX داخل برنامج TeX التنفيذي: فالأوامر البدائية ليست ماكروز ينشئها المستخدمون، بل هي تعليمات أساسية لا تتجزأ/ذرّية تُستخدم للتحكم في سلوك التنضيد لدى كل محرك. وبالتالي فإن الطريقة الأكثر موثوقية لإنشاء قائمة نهائية بالأوامر البدائية التي يدعمها أي محرك TeX هي فحص الشيفرة المصدرية الفعلية التي تُبنى (تُترجم) منها برامج TeX التنفيذية واستخراج قائمة الأوامر البدائية المعرّفة في الشيفرة المصدرية. يبدو أن الأمر ينبغي أن يكون سهلًا، أليس كذلك؟ غير أنه، بسبب تاريخ التطوير الممتد على 40 عامًا لـ TeX، فإن استكشاف/فحص ملفات الشيفرة المصدرية لمحركات TeX (باستثناء LuaTeX) ليس مباشرًا على الإطلاق. وترجع تلك التعقيدات إلى الأدوات، ولغة البرمجة (Pascal)، والمنهجية (البرمجة الأدبية) التي استخدمها Knuth لكتابة الشيفرة المصدرية الأصلية لـ TeX—التي تنحدر منها، في النهاية، جميع المحركات الأخرى.

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

1. LuaTeX: عملية بناء مخصصة (أكثر حداثة)
2. جميع المحركات الأخرى: عملية بناء موروثة (Web2C)

## سياق الشيفرة الموروثة: لماذا يُعد بناء (معظم) محركات TeX معقدًا

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

امتداد ملف الشيفرة المصدرية لـ TeX (`.web`) قد لا يكون مألوفًا، وقد تتساءل أي لغة استخدم Knuth لكتابة TeX؟ الجواب هو Pascal، لكن `.web` الامتداد يحتاج إلى بعض الشرح الإضافي. طور Knuth منهجية برمجية سماها [البرمجة الأدبية](https://en.wikipedia.org/wiki/Literate_programming) التي تُدمج فيها الشيفرة المصدرية للبرنامج ووثائقه معًا وتُصدر في ملف مركّب واحد (شيفرة + توثيق) بامتداد `.web`؛ ويُشار إلى هذا النوع من الملفات باسم ملف WEB. سنشرح ملفات WEB بمزيد من التفصيل أدناه.

### إنشاء محركات TeX جديدة: شروط Knuth

على الرغم من أن Knuth أتاح منذ زمن بعيد شيفرته المصدرية لـ TeX (`tex.web`) مجانًا للجميع، فقد اشترط، وهو حقه المطلق، شرطًا أساسيًا مفاده أن شيفرته المصدرية (`tex.web`) لا يجوز تحريرها/تعديلها مباشرةً وإعادة توزيعها باسم البرنامج «TeX». وفي الشيفرة المصدرية يكتب:

```
% هذا البرنامج محمي بحقوق النشر (C) 1982 بواسطة D. E. Knuth؛ جميع الحقوق محفوظة.
% لا يُصرَّح بنسخ هذا الملف إلا إذا (1) كنتَ D. E. Knuth، أو إذا
% (2) لم تُجرِ أي تغييرات إطلاقًا على نسختك. (يوفّر نظام WEB
% إمكانية إجراء تعديلات عبر ملفٍ مساعد؛ ويجب أن يبقى الملف الرئيسي كما هو.)
```

وأيضًا:

```
إذا تغيّر هذا البرنامج، فلا ينبغي أن يُسمّى النظام الناتج
`\TeX'؛ فالاسم الرسمي `\TeX' بحد ذاته محجوز
لأنظمة برمجية متوافقة تمامًا مع بعضها البعض.
تتوفر مجموعة اختبار خاصة تُسمّى اختبار ``\.{TRIP}''
للمساعدة في تحديد ما إذا كانت أي عملية تنفيذ بعينها تستحق أن تُعرف باسم
`\TeX' [قارن تقرير قسم علوم الحاسوب بجامعة ستانفورد CS1027،
نوفمبر 1984].
```

باختصار: لا تُجرِ تغييرات عبر تحرير ونشر نسخ معدلة من الشيفرة المصدرية الرئيسية لـ TeX ثم تواصل تسميتها `tex.web`. وإذا أردت فعلًا إجراء تغييرات، مثلًا إضافة أوامر بدائية جديدة إلخ، فعليك تطبيق تلك التغييرات عبر «تعديلات بواسطة ملف مساعد» وإعطاء برنامج «المشتق من TeX» اسمًا يميّزه عن «TeX»، الذي يُعد بصيغته المنضدة ($$\mathrm\TeX$$) علامة تجارية تابعة للجمعية الرياضية الأمريكية.

### وراثة الإرث القديم

على الرغم من وجود محاولات لإعادة كتابة TeX بالكامل باستخدام لغات ومنهجيات برمجة حديثة—مثل المبادرتين المعتمدتين على Java [نظام التنضيد الجديد](https://en.wikipedia.org/wiki/New_Typesetting_System) و [εχTEX](http://www.extex.org/) وأخرى مثل [واحدة بلغة Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure)، فإن أياً منها لم يحقق نجاحًا كاملًا. إن تاريخ المشاريع والمبادرات المصممة لمواصلة تطوير TeX موضوع شيق، وقد يرغب القراء في [زيارة أسئلة وأجوبة UK TeX](https://texfaq.org/FAQ-enginedev) للحصول على مزيد من المعلومات.

أما المبادرات غير LuaTeX التي نجحت أيضًا، مثل e-TeX وpdfTeX وXeTeX ومحركات أخرى، فقد بُنيت *مباشرةً على* شيفرة Knuth الأصلية: أي أخذوا شيفرته المصدرية و«طبّقوا تغييرات» لاشتقاق محرك جديد بقدرات إضافية—مثل إضافة أوامر بدائية جديدة، وإنتاج مخرجات PDF، ودعم إدخال نص UTF-8، وغير ذلك. ورغم أن هذا المسار أدى إلى نجاحات ملحوظة، فإنه يعني أيضًا أن تلك المحركات المشتقة ترث الشيفرة الموروثة وتقنيات التطوير التي أنشأها Knuth قبل 40 عامًا.

والخلاصة المهمة هنا هي أنه، باستثناء LuaTeX، فإن معظم محركات TeX المشتقة من الشيفرة المصدرية الأصلية لـ Knuth تُنشأ بأخذ ملف واحد ضخم (عادةً `tex.web`) وتطبيق تغييرات تُنتج ملفًا ضخمًا آخر منفردًا يحتوي على الشيفرة المصدرية الأساسية لذلك المحرك الجديد. قد يرغب القراء المتقدمون في الانتقال مباشرةً إلى [الملاحظات التوضيحية عن pdfTeX وXeTeX](#aside-xetex-and-pdftex).

### بعض التاريخ/الخلفية الإضافية لـ TeX

سُجِّلت لحظة ميلاد TeX [في يوميات Knuth بتاريخ 30 مارس 1977](/latex/ar/mqalat-mtamqh/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history)، أي قبل أكثر من 40 عامًا الآن. داخليًا، TeX برنامج شديد التعقيد، وقد بذل Knuth جهدًا كبيرًا في [توثيقه بتفصيل استثنائي](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). وللقيام بذلك طور Knuth أسلوبًا برمجيًا سماه [البرمجة الأدبية](https://en.wikipedia.org/wiki/Literate_programming) البرمجة الأدبية `.web` الذي تُدمج فيه الشيفرة المصدرية للبرنامج ووثائقه معًا وتُصدر في ملف مركب بامتداد `tex.web`(ويُشار إليه بملف WEB). اختار Knuth لغة Pascal كلغة لكتابة برمجيات TeX الخاصة به، وليس من المستغرب أنه استخدم لغة التنضيد TeX لكتابة الوثائق النهائية. وبالتالي فإن الشيفرة المصدرية الرئيسية لـ TeX الخاصة بـ Knuth منشورة في ملف واحد ضخم يُسمّى

: مزيج من الشيفرة المصدرية بلغة Pascal وشيفرة التنضيد TeX الخاصة بالتوثيق. `tex.web`فيجب عليك معالجة ملف WEB (مثلًا، [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) الذي يُنتج الوثائق في صورة `.tex` ملف يمكنك تنضيده. ولاستخراج الشيفرة المصدرية بلغة Pascal تستخدم أداة أخرى تُسمّى [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) التي تُخرج ملفًا بامتداد `.p` يحتوي على الشيفرة المصدرية بلغة Pascal.

وقت كتابة هذا النص (بداية 2019) أحدث إصدار من TeX الخاص بـ Knuth هو 3.14159265، بتاريخ يناير 2014. ومرة أخرى، لاحظ أن الشيفرة المصدرية لـ TeX الخاصة بـ Knuth موجودة في ملف واحد فقط يحتوي على نحو 25,000 سطر من شيفرة TeX/Pascal!

### من Pascal إلى C

خلال أكثر من 40 عامًا مضت منذ ميلاد TeX، أصبحت Pascal خارج الموضة، واليوم قلّما، إن وُجد أصلًا، يفكر الناس في بناء TeX من شيفرته المصدرية الأصلية المكتوبة بـ Pascal. ولتفادي استخدام Knuth للغة Pascal، صُمِّمت عملية عمل تُسمّى [Web2C](http://tug.org/texinfohtml/web2c.html) حوالي عام 1987)، تُحوَّل فيها الشيفرة المصدرية لـ TeX المكتوبة بـ Pascal تحويلًا آليًا (أي بواسطة البرمجيات) إلى نظيرها بلغة C، ثم تُستخدم هذه النسخة لترجمة TeX وبناء البرنامج التنفيذي. وهي تعمل جيدًا، لكن الجانب السلبي الوحيد هو أن الشيفرة المصدرية المولدة آليًا بلغة C ليست مخصصة للفحص البشري العابر: فهي *شديدة* الإسهاب وشبه مستعصية على الفهم، لأنها موجّهة إلى المترجمات، لا إلى البشر—وهنا لقطة شاشة تُظهر جزءًا صغيرًا من شيفرة C المولدة من الشيفرة المصدرية بلغة Pascal الخاصة بـ TeX:

![](/files/060bc5d8a4ce59a01752e69411cda9096774bcea)

### صيغة أخرى من كنوث: ملفات التغيير في WEB

كما ذُكر أعلاه، لبناء الشيفرة المصدرية الأصلية لـ Knuth «تطبّق تغييرات» أو، بعبارة Knuth، تُجرى «تعديلات عبر ملف مساعد»: لكن ماذا يعني هذا فعليًا؟ هنا يأتي *دور آلية ملفات التغيير*.

### ملفات التغيير: الآلية لإنشاء محركات TeX جديدة

عادةً ما يرغب المطورون الذين يريدون توسيع TeX الخاص بـ Knuth بأي شكل في إنشاء «نسخة» جديدة بالكامل من TeX أو توفير *إضافة* يمكن إلحاقها بأي محرك TeX. ومن أمثلة الإضافات [SyncTeX](https://github.com/jlaurens/synctex) و [EncTeX](https://ctan.org/pkg/enctex?lang=en)—فعلى سبيل المثال، تُعد SyncTeX إضافة مفيدة جدًا أصبحت الآن مضمنة في جميع محركات TeX. وقد حلّ تطور محركات TeX الواعية بـ Unicode إلى حد كبير محل الحاجة إلى EncTeX—لكن لاحظ أن EncTeX مضمَّنة في pdfTeX.

سواء كان الهدف إنتاج «نسخة» جديدة من TeX (أي مشتقًا من TeX الأصلي لـ Knuth)، أو إنشاء إضافة، فإن مطوريها يبدأون من الشيفرة المصدرية الأصلية لـ Knuth ويطبقون التعديلات اللازمة لإنشاء محرك TeX جديد (أو إضافة قابلة للإلحاق). ومع ذلك، كما ذُكر أعلاه، فإن أي شخص يرغب في تعديل سلوك TeX يحتاج إلى القيام بذلك باستخدام «تعديلات عبر ملف مساعد» لأن هذه التغييرات/التعديلات يجب ألا تُطبَّق عبر *تحرير* مباشرًا لشيفرة Knuth المصدرية الأصلية: إذ يُطلب من المطورين استخدام ما يُسمّى WEB *دور آلية ملفات التغيير*. ويُكتب الشيفرة اللازمة لتعديل TeX الخاص بـ Knuth بلغة WEB «البرمجية» وتُحفظ في ملف واحد أو أكثر من ملفات الشيفرة (تُسمّى *ملفات التغيير*), ثم تُ *دمج* مع الشيفرة المصدرية الأصلية الرئيسية غير الممسوسة الخاصة بـ Knuth. وتُنشئ عملية الدمج هذه ملف WEB مركبًا جديدًا يحتوي الآن على *الشيفرة* المصدرية الأساسية للبرمجية الجديدة/المعدلة المعتمدة على TeX. *ملفات التغيير* غالبًا ما يكون امتدادها `.ch` لكن عمليًا يمكن أن تحمل أي امتداد يريده المطورون.

#### كيف تستخدم/تطبّق ملفات التغيير؟

في الوقت الحاضر، أسهل طريقة لتطبيق ملفات التغيير وتعديل ملف WEB «رئيسي» هي باستخدام برنامج أداة يُسمّى [TIE](https://ctan.org/pkg/tie). على سبيل المثال، لنفترض أنك أردت تعديل TeX الخاص بـ Knuth بإضافة، مثلًا، بضعة أوامر بدائية جديدة، أو أردت تغيير سلوك أمر TeX بدائي (قياسي) موجود. عندها ستكتب شيفرتك (بلغة Pascal!) باستخدام نظام WEB للبرمجة الأدبية وتحفظها في ملف يُسمّى، مثلًا، `myprim.ch`. والخطوة التالية هي دمج شيفرتك (في `myprim.ch`) مع ملف Knuth المصدر الرئيسي `tex.web` وينتج ملف WEB مركبًا جديدًا يمثّل ما سنسميه `mytex.web`. وللقيام بذلك ما عليك سوى تنفيذ برنامج TIE على النحو التالي:

```
tie -m mytex.web tex.web myprim.ch
```

إذا نجح الدمج، فسينتج عن ذلك ملف WEB جديد، `mytex.web`، مع بقاء ملف Knuth المصدر الرئيسي `tex.web` غيرَ معدّل إطلاقًا، كما هو مطلوب.

لنفترض الآن أن شخصًا آخر أعجب بالتغييرات التي أجريتها ويريد تعديل عملك لإضافة تغييرات تخصه فوق ما قمتَ به أو إلى جانبه. وبدلًا من توزيع نسختك المعدلة من TeX (`mytex.web`) تقرر نشر/مشاركة ملف التغيير فقط، `myprim.ch`. ويمكن لأي شخص يريد البناء على عملك أن ينشئ ويشارك ملف التغيير الخاص به، وليكن مثلًا، `moreprim.ch` الذي يوسّع شيفرتك بطريقة ما. ويمكن لأي شخص آخر يريد الاستفادة من كلا ملفي التغيير أن يولّد الآن ملف WEB مركبًا جديدًا عبر دمج *كلا* ملفي التغيير داخل الأصل الخاص بـ Knuth لتوليد برنامج TeX آخر، وليكن مثلًا، `newmytex.web`:

```
tie -m newmytex.web tex.web myprim.ch moreprim.ch
```

### أنظمة TeX الحقيقية: ملفات تغيير متعددة

إن الوصف أعلاه لـ TIE قريب جدًا في الواقع من الطريقة التي تُبنى بها العديد من محركات TeX عمليًا: فهي تبدأ بـ `tex.web` وتضيف سلسلة متعاقبة من ملفات التغيير لتوليد ملف WEB المصدر لذلك المحرك. ويتطلب كل محرك TeX مجموعةً خاصة به من ملفات التغيير، التي يجب تطبيقها/معالجتها (دمجها) بترتيب صارم: وإذا أخطأت في الترتيب فسيفشل الدمج لأن كل ملف تغيير في السلسلة يعتمد على التغييرات التي أدخلتها ملفات التغيير السابقة في السلسلة.

إليك تشغيلًا نموذجيًا لـ TIE يطبّق عدة ملفات تغيير على `tex.web` من أجل توليد `ktex.web`—وهو ملف WEB المركب الذي يحتوي على تعديلات على TeX الخاص بـ Knuth تجعله جاهزًا (ملائمًا) للتحويل إلى C عبر عملية Web2C. لاحظ أيضًا ما يلي:

* `tex.ch` هو ملف تغيير كبير جدًا يعدّل TeX، من بين أمور كثيرة، لاستخدام Kpathsea؛
* تُضاف إضافة SyncTeX عبر ملفات تغيير متعددة.

```
tie -m ktex.web tex.web tex.ch enctex.ch synctex-def.ch0 synctex-mem.ch0 synctex-mem.ch2 synctex-rec.ch0 synctex-rec.ch1 synctex-rec.ch2 tex-binpool.ch
هذه هي TIE، نسخة CWEB 2.4.
حقوق النشر (c) 1989,1992 لـ THD/ITI. جميع الحقوق محفوظة.
(tex.web)
(tex.ch)
(enctex.ch)
(synctex-def.ch0)
(synctex-mem.ch0)
(synctex-mem.ch2)
(synctex-rec.ch0)
(synctex-rec.ch1)
(synctex-rec.ch2)
(tex-binpool.ch)
....500....1000....1500....2000....2500....3000....3500....4000....4500
....5000....5500....6000....6500....7000....7500....8000....8500....9000
....9500....10000....10500....11000....11500....12000....12500....13000
....13500....14000....14500....15000....15500....16000....16500....17000
....17500....18000....18500....19000....19500....20000....20500....21000
....21500....22000....22500....23000....23500....24000....24500....
(لم يتم العثور على أي أخطاء.)
```

#### ملاحظة جانبية: XeTeX وpdfTeX

ولإكمال الصورة، ينبغي أن نلاحظ أن عملية بناء pdfTeX وXeTeX لا تبدأ فعليًا من `tex.web`؛ بل تبدأ بدلًا من ذلك بملفات تُسمّى `pdftex.web` و `xetex.web` على التوالي: ويُرجَّح أن السبب هو أن التغييرات واسعة جدًا بحيث يكون من المنطقي أكثر مشاركة/نشر ملفات WEB التي تحتوي أصلًا على التعديلات الكبيرة جدًا التي أُجريت على الشيفرة الأصلية لـ Knuth.

### مثال: e-upTeX

طوّرت جماعة TeX اليابانية عددًا من محركات TeX المصممة لتلبية تعقيدات تنضيد النص الياباني:

* **pTeX**: محرك TeX الخاص بـ Knuth موسَّع لدعم التنضيد الياباني؛
* **e-pTeX**: مزيج من e-TeX وpTeX (إضافةً إلى بضعة أوامر بدائية أدخلها pdfTeX)؛
* **upTeX**: نسخة من pTeX واعية بـ Unicode بالإضافة إلى امتدادات لتحسين التعامل مع CJK (الصينية واليابانية والكورية)؛
* **e-upTeX**: مزيج (دمج) من e-TeX وupTeX.

#### توليد ملف المصدر المركب لـ e-upTeX

لإنشاء ملف WEB المصدر المركب لـ e-upTeX (مع SyncTeX) تبدأ من `tex.web` لكن تحتاج إلى تطبيق **26** ملفات تغيير منفصلة، وفق الترتيب التالي، لإنتاج ملف مركب واحد يمكن منه استخراج قائمة الأوامر البدائية:

```
etex.ch, tex.ch0, tex.ch, tex.ech, etex.ch0,
ptex-base.ch, uptex-m.ch, euptex.ch0, eptex.ech,
etex.ch1, euptex.ch1, synctex-def.ch0, synctex-ep-mem.ch0,
synctex-mem.ch0, synctex-e-mem.ch0, synctex-ep-mem.ch1,
synctex-p-rec.ch0, synctex-rec.ch0, synctex-rec.ch1,
synctex-e-rec.ch0, synctex-p-rec.ch1, fam256.ch,
pdfstrcmp-eup-pre.ch, pdfutils.ch, pdfstrcmp-eup-post.ch,
tex-binpool.ch
```

#### تطبيق ملفات التغيير: أي ملفات وبأي ترتيب؟

كما ذُكر، من المهم جدًا تطبيق/معالجة ملفات التغيير بترتيب صارم—لكن كيف تعرف أي الملفات مطلوبة وبأي ترتيب ينبغي معالجتها؟ لحسن الحظ، هذه المعلومات الحاسمة مسجلة داخل ملفات موجودة في توزيعة TeX Live، وكشف استكشاف الشيفرة المصدرية لـ TeX Live عن القواعد التي تحكم متطلبات البناء لكل محرك TeX. وباتباع تلك القواعد استطاعت Overleaf إعادة بناء ملف الشيفرة المصدرية المركب WEB لكل محرك TeX واستخراج قائمة بالأوامر البدائية لمواصلة معالجة البيانات.

## وأخيرًا: كيف نستخرج قائمة الأوامر البدائية؟

بمجرد إنشاء ملف WEB المركب، تكون مهمة استخراج قائمة الأوامر البدائية، باستخدام التعابير النمطية، سهلة لأن جميع الأوامر البدائية تُعرَّف («تُسجَّل») باستخدام دالة Pascal واحدة تُسمّى `primitive(...)`. إليك بعض الأمثلة الحقيقية المأخوذة من `tex.web` الشيفرة المصدرية لـ Knuth:

```
primitive("lineskip",assign_glue,glue_base+line_skip_code)
primitive("baselineskip",assign_glue,glue_base+baseline_skip_code)
primitive("parskip",assign_glue,glue_base+par_skip_code)
primitive("abovedisplayskip",assign_glue,glue_base+above_display_skip_code)
primitive("belowdisplayskip",assign_glue,glue_base+below_display_skip_code)
primitive("abovedisplayshortskip",assign_glue,glue_base+above_display_short_skip_code)
...
...
```

كما ترى، فإن `primitive(...)` الدالة قابلة جدًا للمعالجة النصية باستخدام التعابير النمطية: فاسم الأمر البدائي المُسجَّل يكون بين علامتي اقتباس (`"..."`) إلى جانب بيانات إضافية تصنّف سلوك كل أمر بدائي (لن نتناول ذلك بتفصيل). وبعد استخراج قائمة الأوامر البدائية لكل محرك، عولجت تلك البيانات بواسطة بعض نصوص Lua لإنشاء HTML يحتوي على النتائج في جدول.

### العودة إلى LuaTeX

لقد أشرنا إلى أن LuaTeX لا يستخدم بالضبط عمليات البناء نفسها التي تستخدمها محركات TeX الثمانية الأخرى. وبعد أن استعرضنا بإيجاز عملية Web2C، وتحويل Pascal إلى C وآلية ملفات التغيير، يمكننا الآن شرح موضع اختلاف LuaTeX: فقد قرر مطورو LuaTeX الاستغناء عن عملية تحويل Pascal إلى C المرهقة—كما ورد في [دليل LuaTeX المرجعي](http://www.pragma-ade.com/general/manuals/luatex):

> ...إطار الترجمة هو web2c ونستمر في استخدامه لكن من دون خطوة Pascal إلى C.

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

وبشكل دقيق، ينبغي أن نلاحظ أيضًا أن بعض ملفات الشيفرة المصدرية لـ LuaTeX تستخدم صيغة متغيرة من منهجية Knuth في البرمجة الأدبية، تُسمّى [CWEB](https://en.wikipedia.org/wiki/CWEB)، وهي قائمة على C وليس Pascal.

### ليس فقط ملفات WEB: بل توجد حاجة إلى شيفرة مصدرية أخرى

بعد إنشاء ملف WEB المصدر المركب لأي محرك TeX (باستثناء LuaTeX)، يجب استخراج الشيفرة المصدرية بلغة Pascal وتحويلها إلى شيفرة C، لكن هذا ليس الحل الكامل. فبالإضافة إلى شيفرة C المولدة من مصدر WEB (Pascal⮕C)، تعتمد معظم محركات TeX أيضًا (تتطلب) عددًا من ملفات الشيفرة المصدرية المساندة الإضافية (المكتبات) المكتوبة عادةً بلغة C—مثل [Kpathsea](https://www.tug.org/kpathsea/). وتنفذ ملفات المصدر المساندة (المكتبات) وظائف لا يلزم، أو لا يمكن، كتابتها في WEB (Pascal). وأي شيء يُكتب بلغة WEB الخاصة بـ TeX يجب أن يستخدم لغة Pascal التي تُستخرج بعد ذلك وتُحوَّل إلى C مولد آليًا: وإذا لم تكن بحاجة إلى القيام بذلك، فلم لا تكتبه ببساطة بلغة C أو C++ من البداية.


---

# 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/18-how-overleaf-created-the-tex-primitive-reference-data.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.