عمل برزنتيشن بالذكاء الاصطناعي عربي: ماذا يصلح فعلًا

عمل برزنتيشن بالذكاء الاصطناعي عربي عبر مكتبة مثل python-pptx يُخرج نصًا عربيًا صحيحًا، لكن اتجاه الشريحة نفسه يبقى إنجليزيًا: الفقرات محاذاة لليسار، والنقاط على الجهة الخطأ، وفي الجداول يبقى العمود الأول من جهة اليسار حتى بعد إصلاح محاذاة النص.

السبب ليس في الترجمة؛ خاصية اتجاه الفقرة التي يسمّيها تنسيق الملف rtl لا تُضبط تلقائيًا لمجرد أن النص عربي.

يجب ضبطها صراحة في شيفرة كل فقرة على حدة، ولكل خلية جدول على حدة أيضًا.

بنيتُ نسختين من العرض نفسه بـ python-pptx، واحدة بإعدادات التوليد الافتراضية وأخرى بإصلاح كل خاصية اتجاه يدويًا، وفحصت شيفرة XML للملفين وصوّرت الفرق بينهما داخل PowerPoint نفسه.

ما الذي يخرج فعلًا من عمل برزنتيشن بالذكاء الاصطناعي عربي بلا تدخل؟

كتبتُ شيفرة تبني عرضًا من أربع شرائح (عنوان، محاور، جدول مؤشرات، خلاصة) بالطريقة التي تكتبها أي أداة توليد كود حين تُطلب منها “اعمل عرض تقديمي” من غير أن تذكر أنه عربي. لم أضف أي سطر خاص بالاتجاه، واكتفيت بكتابة النص العربي داخل الفقرات كما هو.

النتيجة بعد فتح الملف: العنوان والنقاط كلها محاذاة لليسار، وعلامة التعداد (•) ظهرت على يسار كل سطر لا على يمينه، فصار شكل الشريحة كتلة نص تبدأ من أقصى يسار الشاشة رغم أن كل كلمة فيها تُقرأ من اليمين لليسار داخليًا. فتحتُ ملف الشريحة من الداخل (كل ملف pptx هو أرشيف ZIP من ملفات XML) وبحثت عن الخاصية rtl في عنصر الفقرة a:pPr، فلم أجدها مطلقًا في النسخة الافتراضية. هذه الخاصية تحديدًا هي التي تُخبر PowerPoint أن هذه الفقرة تُحاذى وتُرتَّب من اليمين، لا مجرد أن حروفها عربية.

الفرق بين الحالتين في الصورة ناتج عن سطرين فقط من الشيفرة، لا عن إعادة كتابة العرض.

ولم أفتح الملفين إلا في PowerPoint المثبّت على جهازي، لا في Google Slides ولا في LibreOffice Impress؛ فبرنامج آخر قد يتعامل مع خاصية rtl الناقصة بطريقة مختلفة، تعويضًا أو تجاهلًا.

كيف تضبط اتجاه النص يدويًا في شيفرة العرض؟

مكتبة python-pptx لا تملك خاصية جاهزة اسمها rtl تضبطها بسطر واحد؛ أعلى مستوى تصل إليه هو محاذاة الفقرة (يسار، وسط، يمين)، وهذه وحدها لا تكفي. اضطررت إلى الوصول مباشرة إلى عنصر XML للفقرة وإضافة الخاصية بنفسي:

from pptx.enum.text import PP_ALIGN

paragraph.alignment = PP_ALIGN.RIGHT
pPr = paragraph._p.get_or_add_pPr()
pPr.set('rtl', '1')

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

ولم تتضمن تجربتي شريحة تخلط عنوانًا إنجليزيًا مع متن عربي في السطر نفسه. هذا نص ثنائي الاتجاه (bidi) وله قواعد ترتيب مختلفة عن مجرد ضبط rtl على فقرة عربية خالصة.

لماذا قد يتغيّر شكل الخط العربي رغم أنك اخترت خطًا بنفسك؟

ملف PowerPoint الواحد يحمل ثلاث خاصيات خط منفصلة لكل قطعة نص: خط للحروف اللاتينية (a:latin)، وخط لحروف شرق آسيا (a:ea)، وخط للنص المعقّد complex script (a:cs)، والعربية تقع في الفئة الثالثة لا الأولى. حين تضبط اسم الخط عبر الخاصية المعتادة في python-pptx (run.font.name = "اسم الخط")، فإنها تكتب القيمة في a:latin فقط، ولا تلمس a:cs إطلاقًا. فحصت هذا بنفسي في شيفرة الملف الناتج: الاسم ظهر في عنصر a:latin وحده، وa:cs لم يكن موجودًا في النسخة التي لم أتدخّل فيها يدويًا.

عمليًا هذا يعني أن اختيار خط لاتيني لا يدعم العربية (كثير من خطوط العناوين التسويقية كذلك) يترك عرض الحروف العربية لخط النص المعقّد الافتراضي في قالب العرض، وقد يكون مختلفًا تمامًا عن الخط الذي اخترته، فتظهر فجوة شكل واضحة بين الأرقام والعلامات اللاتينية والنص العربي في السطر نفسه. لإصلاحه، أضفت عنصر a:cs يدويًا بنفس اسم الخط:

from lxml import etree

rPr = run._r.get_or_add_rPr()
cs = etree.SubElement(
    rPr, '{http://schemas.openxmlformats.org/drawingml/2006/main}cs'
)
cs.set('typeface', 'Calibri')

بعد هذا التعديل عرض Calibri الحروف العربية متصلة وبلا كسر في النسخة المُصلَحة، وهذا ما تؤكده الصورة السابقة؛ لا يعني هذا أن كل خط يحمل هذا الاسم يدعم العربية على كل جهاز، بل أن النظام المحدّد الذي اختبرت عليه يحمل نسخة من Calibri تدعمها.

هل المشكلة في اختيار الخط ولا في الاتجاه؟

الاثنان منفصلان تمامًا ويمكن أن يحدث أحدهما بلا الآخر. مشكلة الاتجاه تُظهر النص كله منحازًا لجهة خاطئة، ومشكلة الخط تُظهر فجوة شكل بين حرف وآخر أو بين النص والأرقام في السطر نفسه حتى لو كان الاتجاه صحيحًا.

هل ضبط rtl على الفقرة يكفي لإصلاح الجداول أيضًا؟

كررت التجربة على شريحة جدول من ثلاثة أعمدة (المؤشر، الشهر الحالي، الهدف)، وضبطت rtl ومحاذاة اليمين على فقرة كل خلية بالضبط كما فعلت مع النص العادي. النص داخل كل خلية صار يمينًا كما هو متوقع، لكن عمود “المؤشر” بقي في أقصى يسار الجدول، وعمود “الهدف” بقي في أقصى اليمين، تمامًا كما وُلد الجدول أول مرة.

السبب أن جدول PowerPoint (عنصر a:tbl في تنسيق الملف) لا يملك خاصية اتجاه على مستوى الجدول كله؛ ترتيب الأعمدة هو ترتيب فيزيائي ثابت في شيفرة الملف، وrtl يؤثر فقط في محاذاة النص داخل كل خلية، لا في مكان العمود نفسه. الإصلاح الوحيد هو بناء الجدول بترتيب أعمدة معكوس من البداية: إذا كان القارئ العربي يتوقع “المؤشر” في أقصى اليمين، فيجب أن يكون هو العمود الأخير الذي تُضيفه الشيفرة، لا الأول. هذا تفصيل يغيب عن أغلب الشرح الذي يقتصر على “فعّل rtl وانتهى الأمر”، بينما الجداول تحتاج خطوة إضافية مستقلة.

هل تكتب الأرقام 1200 أم ١٢٠٠ داخل العرض؟

في كل شريحة بنيتها كتبت الأرقام بصيغتها الغربية المعتادة (1200، 18، 40، 3000)، وظهرت هذه الأرقام في الشريحة الناتجة كما كتبتها بالضبط، في النسخة الساذجة وفي النسخة المُصلَحة، بلا أي تحويل تلقائي من المكتبة إلى الأرقام الهندية (١٢٠٠، ١٨). جرّبت أيضًا أن أكتب رقمًا واحدًا بالصيغة الهندية داخل نفس الفقرة لأرى هل يُعيد PowerPoint ترتيبه مع النص المحيط به بشكل غريب، فظهر الرقم كما هو بلا أي تحريك، لأن الأرقام في الحالتين تُعامَل كنص عادي لا كعنصر له قواعد اتجاه خاصة. هذا يعني أن القرار بين الصيغتين قرار بشري بالكامل يُتَّخذ وقت كتابة النص أو البرومبت، لا شيء في python-pptx ولا في أدوات التوليد المبنية عليها يحسمه نيابة عنك.

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

هل يكفي كل ما سبق حتى تظهر النقطتان والأرقام في مكانها؟

لا. بعد ضبط الاتجاه والمحاذاة والخط في النسخة المُصلَحة، بقي عيب ظهر في سطر عادي جدًا من شريحة المحاور: «الوضع الحالي: 1200 زائر و 18 طلبًا في الشهر». النقطتان اللتان تلتصقان بكلمة «الحالي» في النص الأصلي ظهرتا بعد الرقم 1200، فصار السطر يُقرأ «الوضع الحالي 1200 :زائر». العيب ظاهر في الصورة التي صدّرها PowerPoint نفسه، فهو ليس من طريقة عرضي للصورة.

لم أعرف السبب من أول نظرة، فجرّبت أربع صيغ للسطر نفسه في شريحة واحدة بالإعدادات المُصلَحة ذاتها: السطر كما هو، ثم السطر مع علامة الاتجاه من اليمين إلى اليسار (حرف غير مرئي رقمه U+200F) بعد النقطتين مباشرة، ثم العلامة نفسها قبل كل رقم، ثم الأرقام الهندية بدل الغربية.

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

LABEL_END = ":" + "‏"   # النقطتان ثم علامة الاتجاه
text = "• الوضع الحالي" + LABEL_END + " 1200 زائر و 18 طلبًا في الشهر"

وبقي في الصيغة الثانية عيب أصغر لم يعالجه شيء مما جرّبته: الرقم 18 يلتصق بالكلمة التي بعده («18طلبًا») رغم وجود مسافة بينهما في النص. وجرّبتُ هذا في PowerPoint على جهازي فقط، فلا أعرف إن كانت العلامة تعمل بالطريقة نفسها في Google Slides أو Keynote.

هل يبقى الإصلاح بعد التصدير إلى PDF؟

صدّرتُ النسختين من PowerPoint نفسه بأمر الحفظ بصيغة PDF، وفحصتُ الصفحة الثانية (شريحة المحاور) في كل ملف بمكتبة PyMuPDF التي تقرأ مواضع الكلمات داخل الملف. في النسخة الساذجة تبدأ الكلمات الست الأولى من 6% إلى 19% من عرض الصفحة، أي من جهة اليسار، وفي المُصلَحة من 76% إلى 92%، أي من جهة اليمين. فإصلاح الاتجاه يبقى في الـ PDF كما هو.

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

ماذا تفعل إن كنت تستعمل أداة جاهزة لا تكتب فيها كودًا؟

كل ما سبق صحيح بصرف النظر عن الأداة التي ولّدت الملف، لأن المشكلة في تنسيق ملف PowerPoint نفسه (OOXML) لا في طريقة التوليد. إن كنت تستعمل أداة ويب في عمل برزنتيشن بالذكاء الاصطناعي عربي وتُصدِّره كملف pptx، افتح كل شريحة بعد التصدير وتحقق من أربعة أشياء في أقل من دقيقة: اتجاه النص (يمين لا يسار)، موضع علامة التعداد، ترتيب أعمدة أي جدول، وتطابق شكل الخط بين الكلمات العربية والأرقام في السطر نفسه. أربعتها عيوب بصرية تُلاحَظ بالعين المجردة بلا حاجة لفتح الملف أو فحص شيفرته.

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

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

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

أقدر أصلح ملف PowerPoint جاهز بإيدي من غير برمجة؟

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