يوفّر Catalina خطًا جديدًا موحّدًا ذا عرض متغيّر لنظام التشغيل macOS.
يحدّد قسم "system-ui" من مواصفات CSS Fonts Module Level 4 كلمة رئيسية للخط system-ui تتيح للمطوّرين استخدام خط نظام التشغيل التلقائي المدمج والمحسّن للغاية والمتوافق مع اللغة المحلية وعالي الجودة جدًا والذي لا يتطلّب تنزيله مباشرةً في مواقعهم الإلكترونية وتطبيقاتهم.
body {
font-family: system-ui;
}
يشبه اختيار الخط هذا القول "استخدام خط النظام التلقائي للغة الحالية لهذا المستخدم".
على أجهزة macOS، الخط system-ui هو San Francisco، وهو خطّ راجعه فريق تصميم واختبره… وتمت ترقيته مؤخرًا. سنناقش أولاً ميزات خطوط المتغيرات الجديدة الرائعة في Catalina، ثم سنتناول بعض الأخطاء وكيفية حلّها من قِبل مهندسي Chromium.
يفترض هذا المنشور أنّك على دراية مسبقة بالخطوط المتغيرة. إذا لم يكن الأمر كذلك، يمكنك الاطّلاع على مقدمة عن الخطوط المتغيرة على الويب والفيديو أدناه.
توافُق المتصفح
في وقت كتابة هذا المقال، يتوفّر دعم system-ui في Chromium (منذ الإصدار 56) وEdge (منذ الإصدار 79) وSafari (منذ الإصدار 11) وFirefox (منذ الإصدار 43)، ولكن باستخدام الكلمة الرئيسية -apple-system. يُرجى الاطّلاع على هل يمكنني استخدام خطوط متغيرة؟ لمعرفة آخر الأخبار.
قدرات جديدة
أصبحت الإمكانات الجديدة التي أضافها نظام التشغيل Catalina إلى خط النظام متاحة الآن لمطوّري الويب اعتبارًا من الإصدار 83 من Chromium. يتضمّن خط system-ui الآن المزيد من إعدادات المتغيّرات: التحجيم البصري وتعديلان فريدان للوزن:
h1 { font-family: system-ui; font-weight: 700; font-variation-settings: 'wght' 750 ; }
h1 { font-family: system-ui; font-weight: 700; font-variation-settings: 'wght' 750, 'opsz' 20, 'GRAD' 400, 'YAXS' 400 ; }
في نظام التشغيل Mojave، يكون system-ui خطًا متغيرًا يتضمّن إعدادات wght فقط. في حين أنّ system-ui على Catalina هو خط متغيّر يتضمّن إعدادات wght وopsz وGRAD وYAXS.
يبدو أنّها فرص رائعة لتصميم تحسين تدريجي! يمكنك التعرّف على التفاصيل الدقيقة لخط النظام إذا أردت ذلك.
wght
يقبل قيمة لوزن الخط تتراوح بين 0 و900 ويتم تطبيقها بالتساوي على جميع الأحرف.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
التحديد البصري للحجم يشبه تباعد الأحرف أو المسافة بين الحروف، ولكن يتم تحديد المسافة بالعين البشرية بدلاً من الرياضيات. القيمة 19 أو أقل مخصّصة للمساحة بين النص ونسخة النص الأساسي، بينما القيمة 20 أو أعلى مخصّصة للمساحة بين عناوين العرض.
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD
تشبه هذه السمة سمة الوزن، ولكن بدون التأثير في المسافة الأفقية. تقبل هذه السمة قيمًا تتراوح بين 400 و1000.
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS
تمدّد الحرف الرسومي عموديًا. تقبل هذه السمة قيمًا تتراوح بين 400 و1000.
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
الجمع بين الخيارات
باستخدام بضعة أسطر من CSS، يمكننا تعديل إعدادات الخط إلى خط غامق من اختيارنا أو تجربة مجموعات أخرى مثيرة للاهتمام:
font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;
بهذه البساطة، سيتمكّن مستخدمو Chromium على أجهزة macOS من رؤية الخط المخصّص الذي تمّت ترقيته والذي يبلغ وزنه 750 مع بعض التعديلات الممتعة الأخرى 👍
أضاف نظام التشغيل macOS 10.15 ميزات جديدة إلى خط النظام، وتم تسجيل خطأ system-ui في أداة تتبُّع الأخطاء في Chromium في نظام التشغيل macOS 10.15. أتساءل عمّا إذا كانا مرتبطَين ببعضهما.
الملحق: تراجع system-ui
تبدأ هذه القصة بخطأ مختلف: #1005969. تم الإبلاغ عن هذه المشكلة في نظام التشغيل macOS 10.15 لأنّ مساحة الخط system-ui بدت ضيقة ومزدحمة.
الخلفية
هل لاحظت يومًا في نظام التشغيل macOS 10.14 كيف "تتغير" الفقرات أو العناوين إلى خط مختلف عند زيادة الحجم أو إنقاصه؟
في نظام التشغيل Mojave (macOS 10.14)، كان خط system-ui يتنقل بين خطَّين استنادًا إلى حجم الخط المستهدف. عندما كان النص ضمن 20px، كان نظام التشغيل macOS يستخدم خط "San Francisco Text". عندما كان النص 20px أو أكثر، كان نظام التشغيل macOS يستخدم خط "San Francisco Display". تم إنشاء ميزة "تغيير الحجم البصري" بشكل ثابت في خطَّين منفصلَين.
أصدرت شركة Apple خطًا جديدًا موحّدًا ذا عرض متغير لخط San Francisco في نظام التشغيل Catalina (macOS 10.15). لن تحتاج بعد الآن إلى إدارة "الإعلانات النصية" و "الإعلانات الصورية". أضفنا أيضًا إعداد السعر المتغير الجديد opsz الموضّح سابقًا.
h1 {
font-variation-settings: 'opsz' 20;
}
لسوء الحظ، القيمة التلقائية opsz في خط Catalina الجديد هي 20، ولم يكن مهندسو Chromium مستعدين لتطبيق opsz على خط النظام. وقد أدّى ذلك إلى عرض الأحجام الأصغر بشكل ضيق جدًا.
لحلّ هذه المشكلة، كان على Chromium تطبيق opsz بشكل صحيح على خط النظام. أدّى ذلك إلى حلّ المشكلة رقم 1005969. لقد فزت! أم كان ذلك…؟
لم يكتمل بعد
وهنا تكمن المشكلة: طبّق Chromium opsz ولكن كان هناك خطأ ما. تحتوي خطوط النظام على أجهزة Mac على جدول خطوط إضافي يُسمى trak، ويعدّل هذا الجدول المسافة الأفقية. أثناء العمل على إصلاح المشكلة، لاحظ مهندسو Chromium أنّه عند استرداد المقاييس الأفقية من عنصر CTFontRef على نظام التشغيل macOS، يتمّ تضمين مقاييس trak في نتائج المقاييس. تحتاج مكتبة التشكيل HarfBuzz في Chromium إلى مقاييس لم يتم أخذ قيم trak فيها بعد.
داخليًا، تستخدم Skia (مكتبة الرسومات، وليس نوع الخط الذي يحمل الاسم نفسه) الفئة CGFontRef من CoreGraphics والفئة CTFontRef من CoreText. بسبب عمليات التحويل الداخلية المطلوبة بين هذه العناصر (المستخدَمة للحفاظ على التوافق مع الإصدارات القديمة والوصول إلى واجهات برمجة التطبيقات اللازمة في كلا الفئتين)، ستفقد Skia معلومات الوزن في ظروف معيّنة وستتوقف الخطوط الغليظة عن العمل. تم تتبُّع هذه المشكلة في المشكلة رقم 1057654.
يجب أن يظلّ Skia متوافقًا مع نظام التشغيل macOS 10.11 لأنّ Chromium لا يزال متوافقًا معه. في الإصدار 10.11، لم تكن خطوط "San Francisco Text" و"San Francisco Display" حتى خطوطًا متغيرة. بل كانت كل مجموعة عبارة عن عائلة من الخطوط المنفصلة لكل وزن متاح. وفي مرحلة ما، أصبحت أرقام تعريف الرموز الرسومية غير متزامنة مع بعضها البعض. لذا، إذا نفّذت Skia عملية تشكيل النص (تحويل النص إلى رموز رسومية يمكن رسمها) باستخدام "San Francisco Text"، سيظهر النص بشكل غير مفهوم إذا تم رسمه باستخدام "San Francisco Display"، والعكس صحيح. وحتى إذا طلبت Skia حجمًا مختلفًا، قد ينتقل نظام التشغيل macOS إلى الحجم الآخر. من المفترض أن يكون من الممكن استخدام أحد الخطوط دائمًا وتغيير حجمه فقط (باستخدام مصفوفة لتكبيره بدلاً من طلب حجم أكبر)، ولكن هناك مشكلة في CoreText حيث لن يتم تكبير رموز sbix (الرموز التعبيرية الملوّنة) (سيتم تصغيرها فقط). الأمر أكثر تعقيدًا من ذلك. يبدو أنّ CoreText يحدّ من المدى العمودي بعد تطبيق المصفوفة، ويبدو أنّ ذلك مرتبط بعدم إمكانية رسم رموز إيموجي بزوايا 45 درجة. في أي حال، إذا أردت عرض الرموز التعبيرية بحجم كبير، عليك إنشاء نسخة من الخط للحصول على نسخة كبيرة.
لذا، من أجل إنشاء نُسخ من عناصر CTFont بأحجام مختلفة داخليًا مع ضمان استخدام بيانات الخط الأساسية نفسها، سحب Chromium CGFont من CTFont، ثم أنشأ CTFont جديدًا من CGFont (عناصر CGFont مستقلة عن الحجم، ويحدث التبديل السحري على مستوى CoreText). كان هذا يعمل بشكل جيد حتى الإصدار 10.154. في الإصدار 10.15، أدت هذه الرحلة ذهابًا وإيابًا إلى فقدان الكثير من المعلومات، ما أدى إلى حدوث مشكلة الوزن. لاحظ فريق Flutter مشكلة الوزن، وتم إجراء إصلاح بديل لتغيير الحجم من أجل إنشاء CTFont الجديد مباشرةً من CTFont الأصلي مع التحكّم في الحجم المرئي مباشرةً باستخدام سمة قديمة ولكن غير موثّقة في CoreText. يضمن ذلك استمرار عمل التطبيق على الإصدار 10.11 ويحلّ مشاكل أخرى (مثل ضبط الحجم المرئي بشكل صريح على القيمة التلقائية).
ومع ذلك، يحافظ هذا الخيار على المزيد من CoreText "السحر" في الخط. يبدو أنّ إحدى هذه المشاكل هي أنّها لا تزال تعدّل تقدّم الرموز الرسومية بطريقة أخرى غير جدول trak فقط (الذي كان Chromium يحاول بالفعل إيقافه من خلال سمة أخرى غير موثّقة).
لا يقدّم CGFont أيًا من هذه "السحر"، لذا ربما يمكن لـ Chromium إزالة CGFont من CTFont واستخدامه فقط للحصول على مزايا؟ للأسف، لن ينجح ذلك لأنّ CoreText معروف بتأثيره في الخطوط بطرق أخرى أيضًا. على سبيل المثال، يجعل رموز الإيموجي الصغيرة أكبر قليلاً من الحجم الذي طلبته (أي يزيد حجمها قليلاً). لا يعرف CGFont ذلك، لذا سينتهي بك الأمر برموز إيموجي مستندة إلى sbix قريبة جدًا من بعضها البعض لأنّك ستقيس بحجم واحد، ولكنّ CoreText سيرسمها أكبر بمقدار معيّن. يريد Chromium الاستفادة من تحسينات CTFont، ولكن بدون تتبُّع، ومن المفضّل بدون أي تغييرات أخرى.
بما أنّ حلّ مشكلة المسافات يتطلّب مجموعة من عمليات الإصلاح المترابطة في Blink وSkia، لم يتمكّن مهندسو Chromium من "مجرد الرجوع إلى الإصدار السابق" لحلّ المشكلة. جرّب مهندسو Chromium أيضًا استخدام علامة إنشاء مختلفة لتغيير مسار الرمز المرتبط بالخط في Skia، ما أدّى إلى حلّ مشكلة الخطوط الغليظة، ولكنّه أدّى إلى تراجع مشكلة المسافات.
الحلّ
في النهاية، أراد فريق Chromium إصلاح المشكلتين. يلجأ Chromium الآن إلى استخدام وظائف مقاييس خطوط OpenType المضمّنة في HarfBuzz لاسترداد المقاييس الأفقية مباشرةً من البيانات الثنائية في جداول خطوط خط نظام التشغيل. باستخدام هذا الخيار، يتجاوز Chromium CoreText وSkia عندما يحتوي الخط على جدول trak (باستثناء خط الإيموجي).
في الوقت الحالي، لا يزال الخطأ رقم 10123 في Skia قيد المتابعة لإصلاحه بالكامل في Skia، والعودة إلى استخدام Skia لاسترداد مقاييس خط النظام منه، بدلاً من الإصلاح الحالي الذي يتم من خلال HarfBuzz.