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
फ़ॉन्ट में अब ज़्यादा वैरिएबल सेटिंग हैं: ऑप्टिकल साइज़ और दो यूनीक वज़न अडजस्टमेंट:
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 वज़न वाले अपग्रेड किए गए वज़न को देख पाएंगे 👍
खेल का मैदान
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 की स्पेसिंग में बहुत आसानी से कम अंतर है](https://web.dev/static/articles/more-variable-font-options-in-chromium-83/image/a-comparison-two-paragra-c4d1b72fd8bdc.jpg?authuser=7&hl=hi)
बैकग्राउंड
क्या आपने कभी 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
वैल्यू को अभी तक शामिल नहीं किया गया है.
![सिस्टम-यूज़र इंटरफ़ेस (यूआई) और उसके सभी फ़ॉन्ट की मोटाई और सूची में मौजूद अलग-अलग वर्शन का डिसप्ले. उनमें से आधे के वज़न में कोई अंतर लागू नहीं है.](https://web.dev/static/articles/more-variable-font-options-in-chromium-83/image/a-display-system-ui-all-6299fdd54fff3.jpg?authuser=7&hl=hi)
सिर्फ़ 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 को अलग करता है. हालांकि, यह सिर्फ़ इमोजी फ़ॉन्ट होने पर ही उपलब्ध होता है.
![सिस्टम-यूज़र इंटरफ़ेस (यूआई) और उसके सभी फ़ॉन्ट की मोटाई और सूची में मौजूद अलग-अलग वर्शन का डिसप्ले. जो आधा हिस्सा पहले काम नहीं कर रहा था वह अब बढ़िया लग रहा है.](https://web.dev/static/articles/more-variable-font-options-in-chromium-83/image/a-display-system-ui-all-f53cc76595e73.jpg?authuser=7&hl=hi)
इस बीच, अब भी Skia की समस्या #10123 मौजूद है, ताकि Skia में इस समस्या को ठीक किया जा सके. साथ ही, HarfBuzz
की प्रोसेस के बजाय सिस्टम फ़ॉन्ट मेट्रिक का डेटा फिर से पाने के लिए, Skia का इस्तेमाल किया जाए.