Catalina में, macOS के लिए एक नया यूनिटेड वैरिएबल सिस्टम फ़ॉन्ट जोड़ा गया है.
सीएसएस फ़ॉन्ट मॉड्यूल लेवल 4 स्पेसिफ़िकेशन के 'system-ui' सेक्शन में, 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 फ़ॉन्ट में अब ज़्यादा वैरिएबल सेटिंग हैं: ऑप्टिकल साइज़िंग और वज़न में दो यूनीक अडजस्टमेंट:
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 सेटिंग होती हैं. वहीं, 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 वेट दिखेगा. साथ ही, उन्हें कुछ और मज़ेदार बदलाव भी दिखेंगे 👍
macOS 10.15 में, सिस्टम फ़ॉन्ट में नई सुविधाएं जोड़ी गई हैं. साथ ही, macOS 10.15 में Chromium के बग ट्रैकर में एक मुश्किल system-ui बग लॉग किया गया था. क्या इनका कोई संबंध है!?
परिशिष्ट: 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" का इस्तेमाल करता था. ऑप्टिकल साइज़िंग को दो अलग-अलग फ़ॉन्ट में स्टैटिक तौर पर बनाया गया था.
Catalina (macOS 10.15) में, San Francisco के लिए एक नया यूनाइटेड वैरिएबल फ़ॉन्ट जोड़ा गया है. अब "टेक्स्ट" और "डिसप्ले" को मैनेज करने की ज़रूरत नहीं है. इसमें वैरिएशन की नई सेटिंग 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 वैल्यू को अब तक शामिल नहीं किया गया है.
अंदरूनी तौर पर, Skia (ग्राफ़िक्स लाइब्रेरी, न कि उसी नाम का टाइपफ़ेस) CoreGraphics की CGFontRef क्लास और CoreText की CTFontRef क्लास, दोनों का इस्तेमाल करता है. उन ऑब्जेक्ट के बीच ज़रूरी इंटरनल कन्वर्ज़न की वजह से (जिसका इस्तेमाल, पिछली पीढ़ी के सिस्टम के साथ काम करने की सुविधा को बनाए रखने और दोनों क्लास पर ज़रूरी एपीआई को ऐक्सेस करने के लिए किया जाता है), Skia कुछ मामलों में वज़न की जानकारी खो देगा और बोल्ड फ़ॉन्ट काम करना बंद कर देंगे. इस समस्या को समस्या #1057654 में ट्रैक किया गया था.
Skia को अब भी macOS 10.11 के साथ काम करना होगा, क्योंकि Chromium अब भी उस पर काम करता है. 10.11 में, "San Francisco Text" और "San Francisco Display" फ़ॉन्ट, वैरिएबल फ़ॉन्ट भी नहीं थे. इसके बजाय, हर फ़ॉन्ट फ़ैमिली में, उपलब्ध हर वेट के लिए अलग-अलग फ़ॉन्ट होते थे. किसी समय, उनके ग्लिफ़ आईडी एक-दूसरे से सिंक नहीं हुए. इसलिए, अगर Skia ने "San Francisco Text" के साथ टेक्स्ट को शेप किया है (टेक्स्ट को ऐसे ग्लिफ़ में बदला है जिसे ड्रॉ किया जा सकता है), तो "San Francisco Display" के साथ ड्रॉ करने पर, टेक्स्ट अजीब लगेगा. इसके अलावा, "San Francisco Display" के साथ ड्रॉ करने पर, "San Francisco Text" के साथ ड्रॉ करने पर टेक्स्ट अजीब लगेगा. भले ही, Skia ने सिर्फ़ किसी दूसरे साइज़ का अनुरोध किया हो, लेकिन macOS किसी दूसरे साइज़ पर स्विच कर सकता है. हमेशा किसी एक फ़ॉन्ट का इस्तेमाल किया जा सकता है और उसे सिर्फ़ स्केल किया जा सकता है. इसके लिए, बड़े साइज़ का अनुरोध करने के बजाय, मैट्रिक का इस्तेमाल करके उसे बड़ा किया जा सकता है. हालांकि, CoreText में एक समस्या है, जिसमें यह sbix (रंग वाले इमोजी) ग्लिफ़ को बड़ा नहीं करेगा (सिर्फ़ छोटा करेगा). यह उससे थोड़ा ज़्यादा जटिल है. ऐसा लगता है कि मैट्रिक लागू करने के बाद, CoreText वर्टिकल एक्सटेंट को कैप कर देता है. ऐसा इसलिए होता है, क्योंकि यह इमोजी को 45 डिग्री के कोण पर नहीं खींच सकता. किसी भी मामले में, अगर आपको अपना इमोजी बड़ा दिखाना है, तो आपको फ़ॉन्ट की कॉपी बनाकर उसका बड़ा वर्शन पाना होगा.
इसलिए, CTFont ऑब्जेक्ट की कॉपी को अलग-अलग साइज़ में बनाने के लिए, Chromium ने CGFont को CTFont से हटा दिया. इसके बाद, CGFont से एक नया CTFont बनाया. 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 के इंजीनियरों ने Skia में फ़ॉन्ट से जुड़े कोडपाथ को बदलने के लिए, किसी दूसरे बिल्ड फ़्लैग का इस्तेमाल भी किया. इससे बोल्ड फ़ॉन्ट की समस्या ठीक हो गई, लेकिन स्पेसिंग की समस्या फिर से आ गई.
समस्या को ठीक करना
आखिर में, Chromium दोनों समस्याओं को ठीक करना चाहता था. Chromium अब सिस्टम फ़ॉन्ट की फ़ॉन्ट टेबल में मौजूद बाइनरी डेटा से सीधे हॉरिज़ॉन्टल मेट्रिक हासिल करने के लिए, HarfBuzz में पहले से मौजूद फ़ॉन्ट OpenType फ़ॉन्ट मेट्रिक फ़ंक्शन का इस्तेमाल करता है. इस सुविधा का इस्तेमाल करके, Chromium CoreText और Skia को तब बायपास कर रहा है, जब फ़ॉन्ट में trak टेबल है. हालांकि, इमोजी फ़ॉन्ट के लिए ऐसा नहीं किया जा रहा है.
इस बीच, Skia की समस्या #10123 को ट्रैक किया जा रहा है, ताकि Skia में इस समस्या को पूरी तरह से ठीक किया जा सके. साथ ही, HarfBuzz के ज़रिए मौजूदा तरीके के बजाय, Skia का इस्तेमाल करके सिस्टम फ़ॉन्ट मेट्रिक को वापस पाया जा सके.