مزيد من خيارات الخط المتغيّرة لخط واجهة مستخدم النظام macOS في Chromium 83

توفّر Catalina خطًا جديدًا للنظام المتغيّر الموحّد إلى نظام التشغيل macOS.

آدم أرجيل
دومينيك روتشس
"دومينيك روتشس"
Twitter GitHub

يحدّد قسم'system-ui' ضمن مواصفات وحدة CSS Fonts المستوى 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 إلى خط النظام متاحة الآن لمطوّري البرامج على الويب اعتبارًا من Chromium 83. خط system-ui الآن يتضمّن المزيد من الإعدادات المتغيّرة: تغيير الحجم البصري وتعديلَين فريدَين للوزن:

Mojave
h1 {
  font-family: system-ui;
  font-weight: 700;
  font-variation-settings:
    'wght' 750
  ;
}
Catalina
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 درجة الذي تمت ترقيته والمخصّص وفقًا لبعض التعديلات الأخرى الممتعة 👍.

ملعب

انقر على Remix to Edit (إنشاء ريمكس) ضمن علامة التبويب "Glitch" أدناه للحصول على نسخة قابلة للتعديل من تأثير Glitch، ثم عدِّل خيارات font-variation-settings الجديدة لمعرفة مدى تأثيرها في الخط. تذكَّر أنّ ميزة Glitch لن تعمل إلا إذا كنت تستخدم جهازًا يعمل بنظام التشغيل macOS Catalina.

أضاف الإصدار 10.15 من نظام التشغيل macOS ميزات جديدة إلى خط النظام، وفي الإصدار 10.15 من نظام التشغيل macOS 10.15، تم تسجيل خطأ system-ui معقد في أداة تتبّع الأخطاء في Chromium. أتساءل عما إذا كانا مرتبطين ببعضهما؟

الملحق: انحدار system-ui

تبدأ هذه القصة بخلل مختلف: #1005969. تم الإبلاغ عن ذلك في الإصدار 10.15 من نظام التشغيل macOS لأنّ تباعد الخط system-ui بدا ضيقًا ومحدودًا.

مقارنة بين فقرتين من صفحة مجموعة على Facebook. على اليسار يوجد Chrome وعلى اليمين Safari، وChrome خفيف لكن أكثر إحكامًا قليلاً في التباعد
Chrome على الجانب الأيسر (تتبع أكثر دقة)، Safari على اليمين (تباعد بصري أفضل)

الخلفية

هل لاحظت من قبل في نظام التشغيل macOS 10.14 كيف "انتقت" فقراتك أو رؤوسك إلى خط ذي مظهر مختلف عندما ارتفع الحجم أو انخفض؟

على Mojave (نظام التشغيل macOS 10.14)، تم تبديل الخط system-ui بين خطين بناءً على حجم الخط المستهدف. عندما كان النص أقل من 20px، استخدم نظام التشغيل macOS "San Francisco Text". عندما كان النص 20px أو أكثر، استخدم نظام التشغيل macOS "جهاز عرض سان فرانسيسكو". تم تصميم الحجم البصري بشكل ثابت في خطين منفصلين.

شحنت Catalina (الإصدار 10.15 من نظام التشغيل macOS) خطًا متغيّرًا موحّدًا جديدًا لمدينة سان فرانسيسكو. لن تحتاج بعد الآن إلى إدارة "النص" و "العرض". كما اكتسبت إعداد الصيغة الجديد opsz الموضح سابقًا.

h1 {
  font-variation-settings: 'opsz' 20;
}

للأسف، القيمة التلقائية opsz في خط Catalina الجديد هي 20، لم يكن مهندسو Chromium مستعدين لتطبيق opsz على خط النظام. وأدى هذا إلى عرض أحجام أصغر حجمًا ضيقًا جدًا.

لإصلاح ذلك، كان على Chromium تطبيق opsz بشكل صحيح على خط النظام. وأدّى ذلك إلى حلّ المشكلة رقم 1005969. لقد انتصرت. أم كان...؟

لم يتم الانتهاء بعد

إليك الأمر الصعب: قام Chromium بتطبيق opsz ولكن هناك شيء لا يبدو على ما يرام. تحتوي خطوط النظام على نظام التشغيل Mac على جدول خطوط إضافي يُسمى trak، وهو يعدّل التباعد الأفقي. أثناء العمل على حلّ المشكلة، لاحظ مهندسو Chromium أنّه تم تضمين مقاييس trak في نظام التشغيل macOS عند استرداد المقاييس الأفقية من عنصر CTFontRef. تحتاج مكتبة التشكيل في Chromium HarfBuzz إلى مقاييس لم يتم أخذ قيم trak فيها في الاعتبار بعد.

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

داخليًا، تستخدم Skia (مكتبة الرسومات، وليس الخط الطباعي الذي يحمل الاسم نفسه) الفئة CGFontRef من CoreGraphics والفئة CTFontRef من CoreText. وبسبب عمليات التحويل الداخلية المطلوبة بين هذه الكائنات (المستخدمة للحفاظ على التوافق مع الأنظمة القديمة والوصول إلى واجهات برمجة التطبيقات المطلوبة في كلا الفئتين)، سيفقد Skia معلومات الوزن في ظروف معيّنة وستتوقف الخطوط الغامقة عن العمل. وقد تم تتبُّع ذلك في المشكلة رقم 1057654.

لا يزال Skia بحاجة إلى دعم macOS 10.11 لأن Chromium لا يزال يدعمه. في 10.11 لم يكن الخط "San Francisco Text" و"San Francisco Display" بمثابة خطوط متغيرة. بدلاً من ذلك، كان كل منها مجموعة من الخطوط المنفصلة لكل وزن متاح. في مرحلة ما، أصبحت أرقام تعريف الأحرف الرسومية غير متزامنة مع بعضها البعض. لذلك إذا قامت سكيا بتشكيل النص (تحويل النص إلى أحرف رسومية يمكن رسمها) باستخدام "نص سان فرانسيسكو"، فسيكون هراء إذا تم رسمه باستخدام "شاشة سان فرانسيسكو"، والعكس صحيح. وحتى إذا طلب Skia للتو حجمًا مختلفًا لنظام التشغيل macOS، فقد يبدّل إلى الآخر. من المفترض أن يكون من الممكن دائمًا استخدام أحد الخطوط وتغيير حجمه (باستخدام مصفوفة لتوسيعه بدلاً من طلب الحصول على حجم أكبر)، ولكن هناك مشكلة في CoreText تتمثل في عدم تحجيم الأحرف الرسومية المزدوجة (الرموز التعبيرية الملونة) لأعلى (فقط أو تقليلها). الأمر أكثر تعقيدًا من ذلك قليلاً. في الواقع، يبدو أنّ CoreText يضع حدًا للامتداد الرأسي بعد تطبيق المصفوفة، ما يبدو مرتبطًا بعدم قدرته على رسم رموز تعبيرية بزاوية 45 درجة. وفي جميع الأحوال، إذا كنت تريد إظهار الرموز التعبيرية بحجم كبير، عليك إنشاء نسخة من الخط للحصول على نسخة كبيرة منه.

لذلك بهدف إنشاء نُسخ من كائنات CTFont بأحجام مختلفة داخليًا مع ضمان استخدام بيانات الخط الأساسية نفسها، أزال Chromium CGFont من CTFont، ثم أنشأ CTFont جديدة من CGFont (كائنات CGFont مستقلّة عن الحجم، ويحدث التبديل السحري على مستوى CoreText). سارت هذه العملية بشكل جيد حتى 10.154. وفي الساعة 10.15، انتهى الأمر بفقدان الكثير من المعلومات، ما أدى إلى حدوث مشكلة في الوزن. لاحظ Flutter مشكلة الوزن وتم إجراء إصلاح بديل لتغيير الحجم لإنشاء CTFont الجديد مباشرةً من CTFont الأصلي مع التحكّم في الحجم البصري مباشرةً باستخدام سمة قديمة ولكن غير موثَّقة في CoreText. يؤدي هذا إلى إبقاء الأمور تعمل على الإصدار 10.11 وإصلاح المشكلات الأخرى (مثل تعيين الحجم البصري بوضوح على القيمة الافتراضية).

ومع ذلك، سيحافظ هذا على قدر أكبر من "السحر" الخاص بـ CoreText في الخط. يبدو أنّ إحدى هذه الأسباب لا تزال تُعدِّل تقدُّم الأحرف الرسومية بطريقة أخرى غير الجدول trak (الذي كان التطبيق يحاول حاليًا تجنُّبه من خلال سمة أخرى غير موثَّقة).

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

نظرًا لأنّ إصلاح مشكلة التباعد يتطلب مجموعة من إصلاحات Blink وSkia المترابطة، لم يتمكّن مهندسو Chromium من "الرجوع فقط" لإصلاح المشكلة. حاول مهندسو Chromium أيضًا استخدام علامة إصدار مختلفة لتغيير مسار الترميز المرتبط بالخط في Skia، مما أصلح مشكلة الخطوط الغامقة، لكنه تراجع مشكلة التباعد.

الحل

وفي النهاية، أراد Chromium بطبيعة الحال إصلاح كلا الأمرين. يلجأ Chromium الآن إلى استخدام دوال مقاييس الخط OpenType المضمّنة لـ HarfBuzz لاسترداد المقاييس الأفقية مباشرةً من البيانات الثنائية في جداول خطوط النظام. باستخدام هذا، يتجاهل Chromium استخدام CoreText وSkia عندما يتضمّن الخط جدول trak (إلا إذا كان خط الرموز التعبيرية).

عرض لواجهة مستخدم النظام وكل سمك الخط وأشكاله المختلفة في قائمة. النصف الذي كان لا يعمل في السابق يبدو رائعًا الآن.

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