الطباعة العربية في واجهات المنتجات: اختيار الخطوط التي تُعرض بشكل صحيح فعلاً

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

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

أبرز النقاط

• العربية كتابة اتصالية سياقية: معظم الحروف تأخذ أشكالًا متصلة مختلفة تبعًا لجاراتها، وبحسب ملاحظات W3C حول قواعد الإملاء العربي، فإن "أشكال الحروف في العربية شديدة التنوّع" — والخط، لا CSS الخاص بك، هو من يقوم بمعظم هذا العمل.
• لا توجد في العربية حالة أحرف (كبيرة/صغيرة). أي جزء من نظام التصميم لديك يفترض وجود مفتاح تبديل بين الحالتين (الأحرف الصغيرة الكبيرة، أزرار بأحرف كبيرة كليًا، text-transform: uppercase) لا يُحدث أثرًا ذا معنى في النص العربي، ويجب أن يقتصر على النص اللاتيني فقط.
• سلوك الاتصال الأساسي — الأشكال الابتدائية والوسطى والنهائية والمنفردة — يُطبَّق تلقائيًا عبر محرّك تشكيل النص في المتصفح بمجرد إعلان lang="ar"، وليس شيئًا تُفعِّله عبر font-feature-settings. دليل Typotheque حول ميزات OpenType في CSS يذكر صراحة أن "جميع الميزات المطلوبة للعربية تُفعَّل تلقائيًا إذا أُعلنت اللغة".
• نتوءات الحروف العربية وذيولها والتشكيل تمتد من خط الأساس أبعد مما هو معتاد في اللاتينية، ولذلك تحتاج الأسطر مساحة رأسية أكبر. توجيه W3C نفسه نوعي لا رقمي محدد — "يحتاج ارتفاع السطر أن يكون أعلى بشكل ملحوظ مما هو عليه في النص اللاتيني" — ولا يوجد رقم واحد موثوق بما يكفي لتثبيته في الكود.
• تستضيف Google Fonts عدة عائلات خطوط عربية مُصانة بفاعلية ولكل منها فلسفة تصميم مختلفة فعلًا — Noto Sans Arabic وCairo وAlmarai وIBM Plex Sans Arabic — لكن بعضها فقط (Noto Sans Arabic وCairo، حتى وقت كتابة هذا المقال) يُشحن كخط متغيّر (variable font) حقيقي؛ تحقق من كل عائلة على حدة بدل افتراض ذلك.
• مجموعة الحروف العربية كبيرة بما يكفي (يغطي Noto Sans Arabic وحده أكثر من ألف حرف موزّعة على ستة نطاقات يونيكود) بحيث تنطبق عليها ذات ممارسات تجزئة unicode-range وWOFF2 التي توصي بها web.dev لخطوط شرق آسيا (CJK).

ما الذي تفعله الكتابة العربية ويجب أن تُحسب له استراتيجية تحميل الخطوط لديك

ثلاث حقائق بنيوية عن العربية تفسّر تقريبًا كل قرار طباعي لاحق، وليست واحدة منها رأيًا شخصيًا — بل خصائص موثَّقة للكتابة نفسها.

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

لا توجد حالة أحرف، ولا أي تأثيرات ملحقة بها. لم تعرف الكتابة العربية يومًا تمييزًا بين أحرف كبيرة وصغيرة. يبدو هذا تفصيلًا بديهيًا حتى تتفحص كل ما يعتمد على "الحالة" في نظام تصميم نمطي: text-transform: uppercase على الأزرار، الأحرف الصغيرة الكبيرة (small caps) للاختصارات، أدلة أسلوب "حالة الجملة" للعناوين. لا شيء من هذه المفاهيم موجود في العربية، فمكوّن زر يفرض الأحرف الكبيرة يحتاج استثناءً واعيًا باللغة، لا خطًا "يدعم" أحرفًا عربية كبيرة — إذ لا يمكن لأي خط أن يدعم تمييزًا لا تملكه الكتابة أصلًا.

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

اختيار الخط: ما هو موثَّق فعلًا، لا ما هو شائع فقط

النصيحة الشائعة "استخدم Noto Sans Arabic، فهو الخيار الآمن" ليست خاطئة، لكنها تتجاهل أن Google Fonts تستضيف الآن عدة عائلات عربية مُصانة بفاعلية ولكل منها فلسفة تصميم مختلفة فعلًا. إليك ما هو موثَّق عن الخطوط التي تلجأ إليها فرق المنتج الأكثر شيوعًا.

Noto Sans Arabic جزء من مشروع Noto من Google، الذي يعلن هدفه بأن يكون عائلة خطوط بلا "التوفو" — المربعات الفارغة التي تظهر حين يفتقر الخط لحرف ما — عبر كتابات العالم كلها. بحسب توثيق Noto الرسمي للخط، يُشحن Noto Sans Arabic الحالي كخط متغيّر بمحوري wght وwdth، ويغطي نحو 1600 رمز (glyph) تقابل أكثر من ألف حرف موزّعة على ستة نطاقات يونيكود، ويوفّر نحو اثنتي عشرة ميزة من ميزات OpenType. إنه أقرب ما يكون إلى خيار محايد بأعلى قدر من التوافق، ولهذا السبب بالذات يُعد نقطة انطلاق معقولة ونادرًا ما يكون الخيار الأكثر تميّزًا لهوية علامة تجارية.

Cairo، بحسب وصفه في مستودع Google Fonts، صمّمه محمد جابر كامتداد للخط اللاتيني Titillium Web إلى العربية، مستلهِمًا الطراز الكوفي، بـ"عيون حروف مفتوحة واسعة ونتوءات وذيول قصيرة تقلل الطول مع الحفاظ على سهولة القراءة". يُشحن الخط في ثمانية أوزان ثابتة إضافة إلى نسخة متغيّرة، وتغطي مجموعة حروفه العربية العربية والفارسية والأردية — وهو أمر يستحق التحقق منه صراحة إن كان منتجك يخدم مستخدمي الفارسية أو الأردية إلى جانب العربية، إذ لا يغطي كل خط "عربي" تلك الحروف الممتدة.

Almarai، بحسب وصفه الخاص في مستودع Google Fonts، صمّمته Boutros™ خصيصًا "لتحقيق أفضل وضوح للقراءة وملاءمة للاستخدامين المتصل وغير المتصل بالإنترنت"، بهندسة تعتمد "تباينًا منخفضًا وفتحة واسعة" عبر أوزانه الأربعة "لتعزيز وضوح قراءة الخط في مختلف الوسائط، خصوصًا على الشاشة". هذه الفلسفة القائمة على وضوح القراءة على الشاشة، كما صرّحت بها دار الخط نفسها، هي سبب ظهور Almarai بكثافة في واجهات منتجات منطقة الشرق الأوسط وشمال أفريقيا أكثر من ظهوره في الأعمال التحريرية أو المطبوعة.

IBM Plex Sans Arabic هو الامتداد العربي لعائلة IBM المفتوحة المصدر Plex، صمّمه وائل مرقص وخاجيك أبيليان من استوديو Morcos Key، وقد فاز عملهما فيه بجائزة D&AD Pencil. أما وصف IBM نفسها لعائلة Plex، بحسب وصف مستودع Google Fonts، فيصفها بأنها "خط غروتيسك محايد لكنه ودود" صُمم حول فكرة "العلاقة الفريدة بين الإنسان والآلة" — فلسفة قائمة على الهوية أكثر منها على وضوح القراءة على الشاشة، وهو ما ينعكس في تباينه الأعلى قليلًا مقارنة بـ Almarai.

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

ارتفاع السطر: إرشاد حقيقي، بلا رقم مُختلَق

ابحث عن "ارتفاع السطر للعربية" وستجد كثيرًا من المقالات تجزم بمُعامل محدد — 1.5 أو 1.7 أو 1.8 — كأنه ثابت مستقر. لا يعود أي من هذه الأرقام إلى مواصفة تقنية أو دار خط؛ إنها قواعد تجريبية غير رسمية تتناقلها المقالات فيما بينها. ما هو موثَّق فعلًا نوعي لا رقمي: حروف العربية وتشكيلها تمتد أبعد من خط الأساس مقارنة باللاتينية، ويحتاج ارتفاع السطر أن يزداد ليستوعب ذلك — علاقة بين النتوء والذيل، لا نسبة ثابتة، لأنها تتوقف على مقاييس الخط المحدد نفسه، لا على العربية كنظام كتابة مجرد.

الأثر العملي هو ضبط ارتفاع السطر كقيمة بلا وحدة نسبةً إلى حجم الخط، تمامًا كما تفعل مع أي كتابة أخرى، بدل تثبيت قيمة بالبكسل:

[lang="ar"] {
  /* ارتفاع السطر بلا وحدة يتناسب مع حجم الخط ويترك للمتصفح
     استخدام المقاييس الرأسية الخاصة بالخط المحمَّل فعليًا،
     بدل افتراض نِسَب لاتينية موروثة من ورقة أنماط مشتركة.
     اضبط --arabic-line-height تجريبيًا لكل خط — عبر عرض
     نص عربي حقيقي بأحجام الإنتاج الفعلية والتحقق من أن
     التشكيل والذيول لا تتلامس بين الأسطر — بدل نسخ رقم
     من مقال، بما في ذلك هذا المقال نفسه. */
  line-height: var(--arabic-line-height);
}

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

font-feature-settings: أقل صلة بصحة العرض العربي مما تظن

من المعقول افتراض أن عرض العربية بشكل صحيح يعني اللجوء إلى font-feature-settings بالطريقة نفسها التي قد تلجأ إليها من أجل الروابط الحرفية اللاتينية أو الأرقام المحاذاة. لكن بالنسبة للميزات التي تجعل النص العربي المتصل يبدو صحيحًا فعلًا، هذا الافتراض معكوس.

الميزات الموضعية الأربع التي تُنتج الأشكال المتصلة — isol وinit وmedi وfina — إلى جانب الروابط الحرفية المطلوبة (rlig) والبدائل السياقية (calt)، موثَّقة في مرجع تشكيل العربية في OpenType كميزات يطبّقها محرّك تشكيل النص بترتيب ثابت وإلزامي استنادًا إلى حالة الاتصال المحسوبة لكل حرف — لا ميزات يُفعِّلها المؤلف بنفسه. عمليًا، يعني هذا أن محرّك التشكيل في المتصفح (HarfBuzz، في معظم الأنظمة والمتصفحات) يطبّقها بشكل صحيح بالفعل طالما يعرف أن النص عربي، وهذا بالضبط ما يعنيه دليل Typotheque حول ميزات OpenType في CSS حين يقول إن "جميع الميزات المطلوبة للعربية تُفعَّل تلقائيًا إذا أُعلنت اللغة":

<!-- هذا يقوم بعمل أكبر مما يبدو عليه. إعلان lang يخبر محرك
     التشكيل بقواعد أي كتابة يطبّق؛ أما dir فهو إشارة منفصلة
     ومكمّلة تتعلق باتجاه التخطيط. -->
<p dir="rtl" lang="ar">
  نص حكيم له سر قاطع وذو شأن عظيم مكتوب على ثوب أخضر ومغلف بجلد أزرق
</p>

إغفال lang="ar" على محتوى عربي — خلل شائع فعلًا حين تُدرَج نصوص عربية داخل شجرة مكوّنات لا تُعلن lang إلا على مستوى المستند الجذري — لا يضر فقط بإمكانية الوصول وفهرسة محركات البحث. فقد يؤثر أيضًا في قواعد التشكيل التي يطبّقها المتصفح في الحالات الملتبسة.

أما ما يظل font-feature-settings (أو، والأفضل، خصائص font-variant-* الأعلى مستوى) مناسبًا له فعليًا في واجهات عربية، فهو الفئة نفسها من الخيارات الطباعية الاختيارية التي يتعامل معها في النص اللاتيني: الروابط الحرفية الاختيارية، أو المجموعات الأسلوبية التي يوفّرها الخط لتنويع خطّي، أو الأرقام المحاذاة لمحاذاة الأرقام داخل جدول. توجيه MDN نفسه يفضّل خصائص font-variant-* حيثما يدعمها المتصفح، ويعامل font-feature-settings كحل بديل منخفض المستوى:

/* فضّل الخاصية القياسية حين تكون مدعومة */
.data-table td {
  font-variant-numeric: tabular-nums;
}

/* ارجع إلى font-feature-settings فقط عند الحاجة */
@supports not (font-variant-numeric: tabular-nums) {
  .data-table td {
    font-feature-settings: "tnum";
  }
}

الخطوط المتغيّرة: طلبات أقل، ونطاق أوزان يناسب الواجهة فعلًا

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

Noto Sans Arabic وCairo كلاهما موثَّق كخط متغيّر حقيقي بمحور wght (ويضيف Noto Sans Arabic محور wdth)، ما يعني أن تصريح @font-face واحدًا يحل محل ما كان يومًا عائلة أوزان كاملة — وهذا يستحق التحقق منه صراحة، لأن ليست كل "خطوط عربية" مدرجة على Google Fonts واكبت هذا التطور: فـ IBM Plex Sans Arabic، على سبيل المثال، ما زال يُوزَّع في سبعة أوزان ثابتة منفصلة بدل ملف متغيّر واحد. أما نسخة Cairo المتغيّرة فـتعرض محور wght يمتد من 200 إلى 900 — أي نطاق أوزانه الثابتة الموثَّق كاملًا مُدمج في ملف واحد:

@font-face {
  font-family: "Cairo Variable";
  src: url("/fonts/cairo-variable.woff2") format("woff2-variations");
  font-weight: 200 900; /* نطاق محور wght الموثَّق لخط Cairo */
  font-display: swap;
}

h1 {
  font-family: "Cairo Variable", sans-serif;
  font-weight: 700; /* يختار نقطة داخل النطاق، دون ملف منفصل */
}

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

تحميل مجموعة حروف كبيرة دون الإضرار بالأداء

عدد رموز العربية هو رافعة الأداء الحقيقية التي تتجاهلها معظم الفرق. يمتد Noto Sans Arabic وحده على نحو 1600 رمز عبر أكثر من ألف حرف، وهذا قبل احتساب الأرقام العربية الهندية الممتدة، أو علامات التلاوة القرآنية، أو امتدادات الفارسية/الأردية التي تضمّها بعض الخطوط "العربية". دليل web.dev لتقليل حجم خطوط الويب يطرح الحجة العامة بأن "تجزئة unicode-range مهمة بشكل خاص للكتابات التي يكون فيها عدد الرموز أكبر بكثير مما هو عليه في اللغات الغربية" — والعربية، إلى جانب كتابات شرق آسيا، هي بالضبط الحالة التي كُتب هذا التوجيه من أجلها.

ثلاث خطوات عملية تنبثق مباشرة من ذلك:

1. جزِّئ إلى ما تعرضه فعليًا. إن كانت واجهتك لا تعرض أبدًا تشكيلًا قرآنيًا أو حروفًا خاصة بالفارسية، فلا تشحن رموزها. أدوات مثل pyftsubset (جزء من fonttools) أو معامل text= الخاص بواجهة برمجة تطبيقات Google Fonts نفسها يمكنها توليد تجزئة تقتصر على نطاق العربية إضافة إلى أي حروف لاتينية يمزجها منتجك.
2. استخدم unicode-range لتقسيم الكتابات إلى كتل @font-face منفصلة. هذا يتيح للمتصفح تجاوز تنزيل تجزئة العربية بالكامل لصفحة تُعرض بالإنجليزية، والعكس صحيح:

@font-face {
  font-family: "UI Sans";
  src: url("/fonts/ui-sans-latin.woff2") format("woff2");
  unicode-range: U+0000-00FF;
}

@font-face {
  font-family: "UI Sans";
  src: url("/fonts/ui-sans-arabic.woff2") format("woff2");
  unicode-range: U+0600-06FF, U+0750-077F, U+FB50-FDFF, U+FE70-FEFF;
}

3. اعتمد WOFF2 حصرًا، واختر font-display بوعي. تشير web.dev إلى أن ضغط WOFF2 القائم على Brotli يتفوق على WOFF بنسبة تصل إلى 30%، ومع مجموعة حروف عربية كبيرة يتضاعف أثر هذا الفارق في الضغط. أما بالنسبة لـfont-display، فـدليل web.dev لأفضل ممارسات الخطوط يصوغ الخيار كمفاضلة: تُبقي swap النص ظاهرًا فورًا بخط احتياطي، على خطر حدوث انزياح في التخطيط عند تبديله بالخط الفعلي، بينما تتجنب optional ذلك الانزياح كليًا بقبول الخط الاحتياطي إن لم يكن الخط الفعلي جاهزًا في الوقت الكافي. بالنسبة للعربية تحديدًا، لا تفترض أن سلسلة الخطوط الاحتياطية لديك تتصرف كما تتصرف مع اللاتينية: إن كانت الخطوط المدرجة قبل خط الويب العربي في سلسلة font-family لا تتضمن رموزًا عربية، فسيستبدل المتصفح خطًا نظاميًا مختلفًا تمامًا للحروف العربية — بوزنه وتناسباته وجودة اتصاله الخاصة — أثناء تحميل خط الويب لديك، بدل عرض تقريب قريب المقاييس من التصميم نفسه كما قد يفعل خط احتياطي لاتيني غالبًا. اختبر فعليًا الخط الاحتياطي الذي تختاره المتصفحات وأنظمة التشغيل المستهدفة لديك، بدل افتراض أن swap يتدهور بأناقة مع العربية كما يفعل مع نص لاتيني أساسي.

تجميع كل ذلك

لا شيء من هذا يحل محل عمل التخطيط والاتجاه الذي تناولناه في مقالنا عن نظام التصميم لدعم LTR وRTL — بل يفترض أن هذا الأساس موجود فعلًا. ما يضيفه هذا المقال هو الطبقة التي تعلو التخطيط: اختيار خط تطابق فلسفة تصميمه الموثَّقة منتجك فعلًا (نص واجهة واضح القراءة على الشاشة مقابل خط عرض قائم على الهوية)، ومنحه المساحة الرأسية التي تتطلبها كتابته بدل افتراض لاتيني افتراضي، وإعلان lang="ar" ليقوم محرّك التشكيل في المتصفح بعمل الاتصال الذي بُني أصلًا لأدائه، وتحميل مجموعة حروف كبيرة بالطريقة نفسها التي ينبغي أن تُحمَّل بها أي مجموعة حروف كبيرة: مجزَّأة، ومضغوطة، ومقسَّمة حسب الكتابة. اضبط الخط بشكل صحيح، وستحصل بقية واجهتك العربية على أساس لا يعمل ضدها في صمت.