Chromium 83 में, macOS सिस्टम-यूआई वाले फ़ॉन्ट के लिए, अलग-अलग फ़ॉन्ट के ज़्यादा विकल्प

Catalina macOS के लिए, यूनाइटेड वैरिएबल सिस्टम का नया फ़ॉन्ट लाया है.

एडम आर्गायल
एडम आर्गाइल
डोमिनिक रॉटशेज़
डॉमिनिक रॉशचेज़

सीएसएस फ़ॉन्ट मॉड्यूल लेवल 4 की खास जानकारी का 'system-ui' सेक्शन, system-ui फ़ॉन्ट कीवर्ड के बारे में बताता है. इसकी मदद से डेवलपर, पहले से मौजूद, टर्बो-ऑप्टिमाइज़ किया गया, स्थानीय, मेगा-हाई-क्वालिटी, बिना डाउनलोड किए, डिफ़ॉल्ट ऑपरेटिंग सिस्टम फ़ॉन्ट को अपनी साइटों और ऐप्लिकेशन में इस्तेमाल कर सकते हैं.

body {
  font-family: system-ui;
}

टाइपोग्राफ़ी का यह विकल्प "इस उपयोगकर्ता की मौजूदा स्थान-भाषा के लिए, डिफ़ॉल्ट सिस्टम फ़ॉन्ट का इस्तेमाल करें" जैसा है.

macOS पर, system-ui का फ़ॉन्ट सैन फ़्रांसिस्को है. यह एक ऐसा फ़ॉन्ट है जिसकी डिज़ाइन टीम ने जांच की है, जांच की है, और... इसे हाल ही में अपग्रेड किया है! सबसे पहले हम catalina में मौजूद नई और दिलचस्प वैरिएबल फ़ॉन्ट सुविधाओं के बारे में बताएंगे. इसके बाद, हम कुछ गड़बड़ी के बारे में बताएंगे और यह भी बताएंगे कि Chromium इंजीनियर उन्हें कैसे ठीक करते हैं.

इस पोस्ट में यह माना गया है कि आपको वैरिएबल फ़ॉन्ट के बारे में पहले से जानकारी है. अगर ऐसा नहीं है, तो वेब पर मौजूद वैरिएबल फ़ॉन्ट के बारे में जानकारी और नीचे दिया गया वीडियो देखें.

वेबसाइट का अलग-अलग ब्राउज़र पर चलना

जानकारी लिखते समय, system-ui के पास Chromium (56 से अब तक), Edge (79 से), Safari (11 से), और Firefox (43 से) के लिए सपोर्ट उपलब्ध है. हालांकि, यह -apple-system कीवर्ड के साथ काम करता है. अपडेट के लिए, क्या वैरिएबल फ़ॉन्ट इस्तेमाल किए जा सकते हैं? देखें.

नई शक्तियां

कैटलीना की तरफ़ से सिस्टम फ़ॉन्ट में मिलने वाली नई सुविधाएं, अब 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 सेटिंग है. हालांकि, Catalina पर system-ui, 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;

विकल्पों को मिलाना

सीएसएस की कुछ लाइनों की मदद से, हम फ़ॉन्ट सेटिंग को अपनी पसंद के बोल्ड अक्षरों में बदल सकते हैं या दूसरे दिलचस्प कॉम्बिनेशन आज़मा सकते हैं:

font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;

ठीक इसी तरह, macOS पर Chromium इस्तेमाल करने वाले लोग, कुछ मज़ेदार ट्वीट की मदद से आपके हिसाब से, 750 वज़न वाले अपग्रेड किए गए वज़न को देख पाएंगे 👍

खेल का मैदान

Glitch की बदलाव करने लायक कॉपी पाने के लिए, नीचे दिए गए Glitch में बदलाव करने के लिए रीमिक्स करें पर क्लिक करें. इसके बाद, font-variation-settings के नए विकल्पों में बदलाव करके देखें कि यह आपके फ़ॉन्ट पर किस तरह असर डालता है. याद रखें कि यह Glitch सिर्फ़ तब काम करेगा, जब macOS Catalina डिवाइस इस्तेमाल किया जा रहा हो.

macOS 10.15 ने अपने सिस्टम फ़ॉन्ट में नई सुविधाएं जोड़ी हैं. साथ ही, macOS 10.15 में, Chromium की गड़बड़ी को ट्रैक करने वाले टूल में system-ui की एक मुश्किल गड़बड़ी को लॉग किया गया था. मैं सोच रहा हूं कि क्या दोनों एक-दूसरे से जुड़े हैं!?

अपेंडिक्स: system-ui रिग्रेशन

यह कहानी किसी दूसरे बग से शुरू होती है: #1005969. इसे macOS 10.15 के ख़िलाफ़ रिपोर्ट किया गया था, क्योंकि system-ui फ़ॉन्ट स्पेसिंग कम और खराब लग रही थी.

Facebook के किसी ग्रुप पेज से दो पैराग्राफ़ की तुलना. बाईं ओर Chrome और दाईं ओर Safari है. साथ ही, Chrome की स्पेसिंग में बहुत आसानी से कम अंतर है
बाईं ओर Chrome (बेहतर ट्रैकिंग), दाईं ओर Safari (बेहतर ऑप्टिकल स्पेस)

बैकग्राउंड

क्या आपने कभी macOS 10.14 पर ध्यान दिया है कि बड़ा या कम होने पर, किस तरह आपके पैराग्राफ़ या हेडर एक अलग दिखने वाले फ़ॉन्ट में "स्नैप" किए गए थे?

Mojave (macOS 10.14) पर, टारगेट फ़ॉन्ट साइज़ के आधार पर, system-ui फ़ॉन्ट दो फ़ॉन्ट के बीच स्विच हुआ. जब टेक्स्ट 20px से कम था, तो macOS ने "San Francisco Text" का इस्तेमाल किया. टेक्स्ट 20px या उससे ज़्यादा होने पर, macOS ने "San Francisco Display" का इस्तेमाल किया. ऑप्टिकल साइज़ को दो अलग-अलग फ़ॉन्ट में स्थिर रूप से बनाया गया था.

Catalina (macOS 10.15) ने सैन फ़्रांसिस्को के लिए एक नया यूनाइटेड वैरिएबल फ़ॉन्ट भेजा. अब "टेक्स्ट" और "डिसप्ले" को मैनेज करने की कोई ज़रूरत नहीं है. साथ ही, इसके वर्शन में नई सेटिंग opsz भी जुड़ गई, जिसके बारे में पहले बताया गया है.

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

माफ़ करें, नए Catalina फ़ॉन्ट में opsz की डिफ़ॉल्ट वैल्यू 20 है. इसलिए, Chromium के इंजीनियर सिस्टम फ़ॉन्ट में opsz लागू करने के लिए तैयार नहीं थे. इस वजह से, छोटे साइज़ बहुत छोटे हो गए.

इसे ठीक करने के लिए, Chromium को opsz को सिस्टम के फ़ॉन्ट पर सही तरीके से लागू करना था. इससे समस्या #1005969 ठीक हो गई. आप जीत गए! या फिर ऐसा हुआ था...?

अभी तक पूरा नहीं किया गया है

यहां यह मुश्किल हो गया: Chromium ने opsz लागू कर दिया है, लेकिन फिर भी कोई चीज़ ठीक नहीं लगी. Mac पर सिस्टम फ़ॉन्ट में trak नाम की एक अतिरिक्त फ़ॉन्ट टेबल होती है, जो हॉरिज़ॉन्टल स्पेसिंग में बदलाव करती है. गड़बड़ी को ठीक करने के दौरान, Chromium के इंजीनियरों को पता चला कि macOS पर, किसी CTFontRef ऑब्जेक्ट से हॉरिज़ॉन्टल मेट्रिक फ़ेच करते समय, trak मेट्रिक पहले से ही मेट्रिक के नतीजों में शामिल हो रही थीं. Chromium की आकार देने वाली लाइब्रेरी HarfBuzz को ऐसे मेट्रिक की ज़रूरत है जिनमें trak वैल्यू को अभी तक शामिल नहीं किया गया है.

सिस्टम-यूज़र इंटरफ़ेस (यूआई) और उसके सभी फ़ॉन्ट की मोटाई और सूची में मौजूद अलग-अलग वर्शन का डिसप्ले. उनमें से आधे के वज़न में कोई अंतर लागू नहीं है.
बाएं: 19 और उससे कम के फ़ॉन्ट साइज़ पर बोल्ड वेट लागू किए गए हैं. दाईं ओर: 20 और उससे बड़े साइज़ के फ़ॉन्ट में बोल्ड स्टाइल नहीं होती

सिर्फ़ Skia, CoreGraphics की CGFontRef क्लास और CoreText की CTFontRef क्लास का इस्तेमाल करता है. वहीं, ग्राफ़िक लाइब्रेरी में, उसी नाम का टाइपफ़ेस नहीं है. इन ऑब्जेक्ट के बीच ज़रूरी इंटरनल कन्वर्ज़न (पुराने सिस्टम के साथ काम करने की सुविधा को बनाए रखने और दोनों क्लास में ज़रूरी एपीआई ऐक्सेस करने के लिए इस्तेमाल किया जाता है) की वजह से, कुछ मामलों में Skia वज़न की जानकारी कम कर देगा और बोल्ड फ़ॉन्ट काम करना बंद कर देंगे. इसे समस्या #1057654 में ट्रैक किया गया था.

Skia अब भी macOS 10.11 के साथ काम करता है, क्योंकि Chromium अब भी इस वर्शन के साथ काम करता है. 10.11 को "San Francisco टेक्स्ट" और "San Francisco Display" फ़ॉन्ट, वैरिएबल फ़ॉन्ट भी नहीं थे. इसके बजाय, हर एक फ़ॉन्ट में, हर उपलब्ध फ़ॉन्ट के लिए अलग-अलग फ़ॉन्ट शामिल थे. कुछ समय में, उनके ग्लिफ़ आईडी एक-दूसरे से सिंक नहीं हो पाए थे. इसलिए, अगर स्किया ने "सैन फ़्रांसिस्को टेक्स्ट" की मदद से टेक्स्ट शेप (टेक्स्ट को ग्लिफ़ में बदला, जिसे ड्रॉ किया जा सकता है) किया, तो "सैन फ़्रांसिस्को डिसप्ले" के साथ लिखे जाने पर बेमतलब के शब्द होंगे और "सैन फ़्रांसिस्को डिसप्ले" के साथ टेक्स्ट को हूबहू दिखाया जाएगा. अगर Skia ने किसी दूसरे साइज़ के macOS के लिए अनुरोध किया है, तब भी वे दूसरे साइज़ के macOS पर स्विच हो सकते हैं. किसी एक फ़ॉन्ट का इस्तेमाल करके उसे स्केल किया जा सकता है (बड़े साइज़ के बजाय इसे बड़ा करने के लिए मैट्रिक्स का इस्तेमाल करके) किया जा सकता है. हालांकि, CoreText में एक समस्या है जिसकी वजह से, sbix (कलर इमोजी) के ग्लिफ़ ऊपर (सिर्फ़ नीचे) नहीं दिखेंगे. यह उतना ही मुश्किल है. ऐसा लगता है कि मैट्रिक्स में लगाने के बाद, CoreText की वर्टिकल सीमा पूरी हो गई है. ऐसा लगता है कि यह मेट्रिक, 45 डिग्री के कोणों पर इमोजी न बना पाने से जुड़ी है. किसी भी इवेंट में, अगर आपको अपने इमोजी को बड़ा दिखाना है, तो उसका बड़ा वर्शन पाने के लिए आपको फ़ॉन्ट की एक कॉपी बनानी होगी.

इसलिए, एक ही फ़ॉन्ट डेटा इस्तेमाल किया जा रहा है, यह पक्का करने के लिए अंदरूनी तौर पर CTFont ऑब्जेक्ट की कॉपी बनाने के लिए, Chromium ने CTFont से CGFont को बाहर कर दिया, फिर CGFont से एक नया CTFont बनाया. CGFont ऑब्जेक्ट का साइज़ अलग होता है. मैजिक स्विचिंग CoreText लेवल पर होती है. यह 10.154 तक सही तरीके से काम करता रहा. साल 10.15 में यह राउंड ट्रिप बहुत ज़्यादा जानकारी खो गई, जिससे वज़न में समस्या आई. फ़्लटर ने वज़न की समस्या का पता लगाया. साइज़ बदलने के लिए एक अन्य समाधान दिया गया, ताकि सीधे मूल CTFont से नया CTFont बनाया जा सके. साथ ही, CoreText में किसी पुरानी, लेकिन दस्तावेज़ में मौजूद एट्रिब्यूट की मदद से ऑप्टिकल साइज़ को कंट्रोल किया जा सके. इससे चीज़ें 10.11 पर काम करती रहती हैं और दूसरी समस्याओं को ठीक करती हैं (जैसे कि ऑप्टिकल साइज़ को साफ़ तौर पर डिफ़ॉल्ट वैल्यू पर सेट करना).

हालांकि, यह फ़ॉन्ट में CoreText के ज़्यादा 'जादू' को सुरक्षित रखता है. इनमें से एक ऐसा लगता है कि यह अब भी ग्लिफ़ ऐडवांस्ड को सिर्फ़ trak टेबल (वह ऐप्लिकेशन जिसके बारे में Chromium, बिना दस्तावेज़ वाले एक अन्य एट्रिब्यूट की मदद से प्रोसेस करने की कोशिश कर रहा था) के बजाय किसी दूसरे तरीके से थोड़ा बदलाव करता है.

CGFont इनमें से कोई भी 'जादू' नहीं करता है. इसलिए, शायद Chromium CGFont को CTFont पर हटा दे और सिर्फ़ आगे बढ़ने के लिए इसका इस्तेमाल कर सके? माफ़ करें, यह काम नहीं करेगा, क्योंकि CoreText अन्य तरीकों से भी फ़ॉन्ट का इस्तेमाल करता है. उदाहरण के लिए, यह छोटे इमोजी को आपके अनुरोध से थोड़ा बड़ा करता है (उनका साइज़ थोड़ा बड़ा करता है). CGFont को इस बारे में पता नहीं है. इसलिए, ऐसा हो सकता है कि आपका sbix वाला इमोजी एक-दूसरे के बहुत करीब हो. ऐसा इसलिए, क्योंकि एक साइज़ में इमोजी का साइज़ नापने पर, CoreText उन्हें बड़ा कर देगा. Chromium चाहता है कि CTFont बेहतर हो जाए, लेकिन वह उन्हें ट्रैक किए बिना और खास तौर पर बिना किसी दिक्कत के उन्हें चाहता है.

स्पेसिंग की समस्या को ठीक करने के लिए, आपस में कनेक्ट किए गए ब्लिंक और Skia सुधारों की ज़रूरत थी. इसलिए, इस समस्या को ठीक करने के लिए, Chromium के इंजीनियर "वापस लाएं" में नहीं जा सके. Chromium के इंजीनियरों ने, Skia में फ़ॉन्ट से जुड़े कोडपाथ को बदलने के लिए, एक अलग बिल्ड फ़्लैग का इस्तेमाल करने की भी कोशिश की, इससे बोल्ड फ़ॉन्ट की समस्या ठीक हो गई, लेकिन स्पेस की समस्या कम हो गई.

समस्या को हल करना

आखिर में, Chromium दोनों चीज़ों को ठीक करना चाहता था. Chromium अब सिस्टम फ़ॉन्ट की फ़ॉन्ट टेबल में मौजूद बाइनरी डेटा से सीधे बाइनरी डेटा से हॉरिज़ॉन्टल मेट्रिक पाने के लिए, HarfTez के बिल्ट-इन फ़ॉन्ट OpenType फ़ॉन्ट मेट्रिक फ़ंक्शन का इस्तेमाल करता है. इसका इस्तेमाल करके Chromium, फ़ॉन्ट में trak टेबल होने पर CoreText और Skia को अलग करता है. हालांकि, यह सिर्फ़ इमोजी फ़ॉन्ट होने पर ही उपलब्ध होता है.

सिस्टम-यूज़र इंटरफ़ेस (यूआई) और उसके सभी फ़ॉन्ट की मोटाई और सूची में मौजूद अलग-अलग वर्शन का डिसप्ले. जो आधा हिस्सा पहले काम नहीं कर रहा था वह अब बढ़िया लग रहा है.

इस बीच, अब भी Skia की समस्या #10123 मौजूद है, ताकि Skia में इस समस्या को ठीक किया जा सके. साथ ही, HarfBuzz की प्रोसेस के बजाय सिस्टम फ़ॉन्ट मेट्रिक का डेटा फिर से पाने के लिए, Skia का इस्तेमाल किया जाए.