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

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

Adam Argyle

Dominik Röttsches

يحدّد قسم "system-ui" ضِمن مواصفات المستوى 4 لوحدة خطوط CSS الكلمة الرئيسية للخط system-ui التي تسمح للمطوّرين باستخدام خط نظام التشغيل التلقائي المدمَج والمحسَّن التوربو والمترجم والعالية الجودة وغير الضرورية للتنزيل في مواقعهم الإلكترونية وتطبيقاتهم.

body {
  font-family: system-ui;
}

يشبه خيار أسلوب الخط هذا قول "استخدم خط النظام الافتراضي للغة الحالية لهذا المستخدم".

على نظام التشغيل macOS، الخط system-ui هو "سان فرانسيسكو"، وهو خط تم فحصه واختباره و... ترقيته مؤخرًا. سنتناول أولاً ميزات الخطوط المتغيّرة الجديدة والمثيرة في 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 مع بعض التعديلات الأخرى الممتعة. 👍

ملعب

انقر على إنشاء ريمكس لتعديل في Glitch أدناه للحصول على نسخة قابلة للتعديل من Glitch، ثم عدِّل خيارات font-variation-settings الجديدة لمعرفة تأثيرها في خطك. يُرجى العِلم أنّ هذه المشكلة لن تعمل إلا إذا كنت تستخدم جهاز macOS Catalina.

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

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

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

الخلفية

هل لاحظت يومًا في نظام التشغيل macOS 10.14 أنّه عند تغيير حجم الفقرات أو العناوين، يتم استخدام خط مختلف المظهر؟

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

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

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

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

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

لم ينتهِ بعد

في هذه المرحلة، بدأت الأمور تصبح صعبة: طبَّق Chromium opsz ولكن لا يبدو أنّ هناك مشكلة. تحتوي خطوط النظام على أجهزة Mac على جدول خطوط إضافي يُسمى trak، والذي يعدّل المسافة الأفقية. أثناء العمل على حلّ المشكلة، لاحظ مهندسو Chromium أنّه على نظام التشغيل macOS، عند استرداد المقاييس الأفقية من عنصر CTFontRef، يتمّ تضمين مقاييس trak في نتائج المقاييس. تحتاج مكتبة التشكيل في Chromium HarfBuzz إلى مقاييس لم يتمّ فيها احتساب قيم 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 (باستثناء الخط المخصّص للرموز التعبيرية).

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