एक्सपोज़र फ़ॉन्ट रेखांकन एल्गोरिदम (2/2)

(लेख एक्सपोज़र फ़ॉन्ट रेखांकन एल्गोरिदम के अनुवाद का दूसरा भाग)

लिनक्स

सबसे बुरे का पालन

विंडोज फोंट खराब करता है, लिनक्स और भी खराब है। सभी लिनक्स सिस्टम मैंने डेविड टर्नर, रॉबर्ट विल्हेम और वर्नर लैम्बग द्वारा फ्रीटाइप [10] का उपयोग करते हुए देखा है। यह एक उत्कृष्ट पुस्तकालय है, लेकिन इसके उपयोग की विधि, दुर्भाग्य से, सफल नहीं कही जा सकती। एक विशिष्ट लिनक्स स्क्रीनशॉट इस तरह दिखता है:







यहाँ पूर्ण स्क्रीनशॉट है:

लिंक



समस्या तुरंत ध्यान देने योग्य है - चौरसाई के परिणामस्वरूप गोल कोनों में काले धब्बे। सामान्य तौर पर, हम कह सकते हैं कि तिरछे स्ट्रोक ऊर्ध्वाधर लोगों की तुलना में भारी दिखते हैं, जो परिणाम में "गंदगी" का आभास देता है। आप यह तर्क दे सकते हैं कि FreeType और Linux ClearType के समान सबपिक्सल रेखांकन का उपयोग कर सकते हैं, लेकिन मेरे लिए इसका कोई ध्यान देने योग्य लाभ नहीं है।







"डब्ल्यू", "वी" और "वाई" को देखें - समस्या अनिवार्य रूप से समान है, वर्ण गंदे दिखते हैं। आप कोस्टरेशन की प्रक्रिया में गामा सुधार का उपयोग करके कोनों में स्थिति को थोड़ा सुधार सकते हैं, लेकिन यह अभी भी एक आदर्श प्रदर्शन प्राप्त करने की अनुमति नहीं देगा।

गामा सुधार

गामा सुधार इस तरह काम करता है:







जैसा कि आप देख सकते हैं, चौरसाई के साथ गोल कोनों 2.0 गामा 2.0 के साथ बेहतर दिखते हैं। गामा सुधार एक अलग गैर-तुच्छ विषय है, और यदि आप रुचि रखते हैं, तो आप चार्ल्स पॉयटन [6] द्वारा गामा एफएक्यू में व्यापक जानकारी पा सकते हैं।



हमारे मामले में, हम इलेक्ट्रॉनिक सर्किट में घटता "स्रोत संकेत - परिणाम" के बारे में बात नहीं कर रहे हैं, बल्कि, मानव दृष्टि की बारीकियों। दृश्य प्रतिक्रिया भौतिक चमक के वर्गमूल के लगभग आनुपातिक है। दूसरे शब्दों में, अगर हमारे पास एक काले रंग की पृष्ठभूमि पर दो सफेद पिक्सेल हैं, और उनमें से एक दूसरे की तुलना में दो गुना अधिक फोटॉन का उत्सर्जन करता है, इसका मतलब यह नहीं है कि यह दोगुना उज्ज्वल दिखाई देगा। वास्तव में, कहीं 1.4 गुना। आप इसे आसानी से सत्यापित कर सकते हैं:







दाईं ओर दो पिक्सेल हैं, और हम विश्वास के साथ कह सकते हैं कि वे बाईं ओर पिक्सेल की तुलना में प्रति सेकंड कई फोटोन का उत्सर्जन करते हैं। हालांकि, वे दो बार उज्ज्वल नहीं दिखते हैं। चार पिक्सल लगभग दो बार चमक देंगे, लेकिन दो नहीं।



अनावश्यक स्पष्टीकरणों को स्वीकार करते हुए, हम कह सकते हैं कि दो मुख्य आरजीबी रंग स्थान हैं: विषयगत रूप से एक समान, जिसे sRGB कहा जाता है, और शारीरिक रूप से समान है। उत्तरार्द्ध में, मान sRGB के विपरीत, भौतिक चमकता के लिए आनुपातिक है, जिसमें मूल्य व्यक्तिपरक चमकदारता के लिए आनुपातिक है। आमतौर पर, एक शारीरिक रूप से समान रंग का स्थान बस रैखिक आरजीबी कहा जाता है। एंटी-अलियासिंग का उपयोग करते समय, रंग मिश्रण को रैखिक स्थान में किया जाना चाहिए, लेकिन प्रदर्शित करने से पहले रंगों को sRGB में लाना आवश्यक है। व्यवहार में, इस कदम को अक्सर नजरअंदाज कर दिया जाता है, और एंटी-अलियासिंग सीधे sRGB में किया जाता है। कई मामलों में, यह स्वीकार्य परिणाम देता है, लेकिन पाठ को व्यवस्थित करने के लिए नहीं, जिसे सीधे Microsoft Word में प्रदर्शित किया जा सकता है। चाल यह है कि वे पाठ का चयन करने के लिए कुछ प्रकार की चाल का उपयोग करते हैं, कुछ एक तुच्छ उलटा जैसा होता है, बजाय खरोंच से छुटकारा पाने के। सामान्य, काले और सफेद चौरसाई के साथ, चयनित पाठ गंदा दिखता है। ClearType के साथ, यह एक रंगीन सीमा प्राप्त करता है:







इसलिए हम यह निष्कर्ष निकाल सकते हैं कि सही गामा सुधार विंडोज पर किया जाता है (लेकिन चयनित पाठ के लिए नहीं), जबकि लिनक्स आमतौर पर इसे अनदेखा करता है। FreeType आसानी से ब्लैक एंड व्हाइट स्मूथिंग मास्क में वांछित गामा परिवर्तन लागू कर सकता है जो रैस्टराइज़र उत्पन्न करता है। लेकिन यह विंडोज की तरह ही काम करेगा: रंग उलटा गामा उलटा पैदा करेगा। व्यवहार में, यह बेकार है, क्योंकि मिश्रण से पहले प्रत्येक रंग घटक के लिए गामा को अलग से लागू किया जाना चाहिए (जो व्यवहार में रैखिक आरजीबी में काम करने के बराबर है)। इसलिए, एक काले और सफेद मुखौटा के लिए गामा सुधार केवल तभी मदद करेगा जब आप एक सफेद पृष्ठभूमि पर काला पाठ प्रदर्शित करते हैं। इस स्थिति में, आप सुधार के लिए क्षेत्र 2 में मान का उपयोग कर सकते हैं। लेकिन यदि आप एक काले रंग की पृष्ठभूमि पर सफेद पाठ प्रदर्शित करते हैं, तो आपको गामा मान को उल्टा करने की आवश्यकता है, अर्थात लगभग 0.5 का उपयोग करें। समस्या यह है कि आप पाठ और पृष्ठभूमि का सही रंग नहीं जानते हैं, पाठ को ढाल या छवि के शीर्ष पर भी प्रदर्शित किया जा सकता है। तो "काला और सफेद" गामा सुधार काम नहीं करेगा, और "पूर्ण रंग" गामा सुधार महंगा और लागू करना मुश्किल हो सकता है। समस्या यह है कि रैखिक आरजीबी को प्रति चैनल 8 बिट्स से अधिक की आवश्यकता होती है, अन्यथा आपको अनिवार्य रूप से रंग नुकसान हो जाएगा। पाठ के लिए, यह मान्य हो सकता है, लेकिन आप पूरे डेस्कटॉप के लिए यह दावा नहीं कर सकते हैं! और प्रति चैनल 16 बिट्स का उपयोग करके रैखिक आरजीबी में काम करना अभी भी एक दुर्गम लक्जरी है।

गामा काम नहीं करता है

वास्तव में, स्थिति और भी खराब है। आप एक ही इरफानव्यू (छवि-> रंगों को बढ़ाएं ...) में लिनक्स से स्क्रीनशॉट के बराबर मान के साथ गामा सुधार लागू कर सकते हैं ... और पाठ को देख सकते हैं। कृपया इस तथ्य पर ध्यान न देने की कोशिश करें कि आइकन टेक्स्ट पर ध्यान केंद्रित करते हैं।







क्या आपको पसंद है? मैं अभी भी नहीं जब मैं एजीजी में टेक्स्ट रिस्ट्राइजेशन पर काम कर रहा था, तो मुझे लगा कि सही गामा करेक्शन से सभी समस्याएं हल हो सकती हैं। कुछ भी नहीं! कोई फर्क नहीं पड़ता कि यह कितनी अच्छी तरह से काम करता है, कुछ तत्व मोटे दिखते हैं और कुछ ऊर्ध्वाधर और क्षैतिज स्ट्रोक से पतले होते हैं। यह सेन्स-सेरिफ़ फोंट पर बहुत ध्यान देने योग्य है, और विशेष रूप से तब जब स्टॉक्स पिक्सेल में हार्ड-एलाइन हो जाते हैं। समस्या यह है कि ट्रू टाइप इशारा विशेष रूप से एंटी-अलियासिंग के बिना सामान्य काले और सफेद रैस्टराइज़र के लिए डिज़ाइन किया गया था! किसी भी एंटी-अलियासिंग का उपयोग करना औपचारिक रूप से गलत है, और अधिकांश लिनक्स सिस्टम बस यही करते हैं। नीचे दी गई छवि FreeType और GetGlyphOutline () दोनों का उपयोग करके एंटी-अलियासिंग के साथ रेखांकन का परिणाम है।







पाठ घटिया दिखता है और यह बहुत कुछ वैसा ही है जैसा हम लिनक्स पर ज्यादातर मामलों में देखते हैं। कोई भी गामा सुधार यहां मदद नहीं करेगा। उदाहरण के लिए, मुझे 1.5 के गामा मूल्य के साथ सबसे अच्छा परिणाम मिला। अभी भी बुरा लग रहा है:







रास्ते के साथ, आपने देखा होगा कि, एक निश्चित आकार से शुरू होने पर, पाठ भारी लगने लगता है। यह बिल्कुल विंडोज पर होता है। यदि आप ClearType को बंद करते हैं, तो यह स्पष्ट होगा (पाठ का आकार बिल्कुल सहेजा नहीं गया है)।







सामान्य तौर पर, आपने विचार को समझा। इसे और अधिक स्पष्ट करने के लिए, हम Win32 API से GetGlyphOutline () फ़ंक्शन द्वारा लौटाए गए वेक्टर चित्र को बढ़ा सकते हैं और देखें कि क्या होता है।







13 पिक्सलों के मामूली आकार के लिए यह पेटेंटेड आक्रामक हिंटिंग काम करता है। यही कारण है कि "के" में स्ट्रोक इतने पतले, लगभग अदृश्य दिखते हैं। टाइम्स न्यू रोमन में इटैलिक और भी बदतर हैं: "z" में तिरछी पट्टी पूरी तरह से गायब हो जाती है। सुचारू रूप से विरूपण नियमित रैस्टराइज़र को प्रभावित नहीं करता है, लेकिन जो फ्रीटाइप का उपयोग करता है वह इन चीजों के प्रति संवेदनशील है। यह सीधे पिक्सेल की कवरेज की डिग्री की गणना करता है, जिससे यह ईमानदारी से तिरछा स्ट्रोक "z" के लिए शून्य कवरेज प्राप्त करता है। यही है, यह पता चला है कि हिंटिंग के लिए ट्रू टाइप बाइटकोड की व्याख्या करने का कोई मतलब नहीं है (यह उल्लेख करने के लिए नहीं कि आपको लाइसेंस खरीदना है)। चौरसाई करना अच्छा है, लेकिन आपको इसे अपने लिए इस्तेमाल नहीं करना चाहिए। किसी भी मामले में, मैं पाठ को बिना सुचारू करना पसंद करूंगा यदि इसे अपर्याप्त हिंटिंग के साथ संयोजन में उपयोग किया जाता है।

ऑटोटाइप फ्रीटाइप

फ्रीटाइप संस्करण 2 में, डेविड टर्नर ने एक ऑटो-हिंटिंग तंत्र पेश किया। यह काफी अच्छी तरह से काम करता है, लेकिन, फिर भी, इसका सीधा आवेदन एक परिणाम देता है जो आदर्श से बहुत दूर है। 1.5 के गामा के साथ वर्दाना हेडसेट को रेखांकन के परिणाम को देखें:







गैर-संकेत उदाहरण के साथ तुलना करें:







गैर-संकेतित संस्करण निश्चित रूप से अधिक सटीक दिखता है, लेकिन अधिक धुंधला भी होता है। तीन मुख्य अंतर हैं:

1. ऑटो-हिंटिंग अभी भी छोटे गोल तत्वों (ऊर्ध्वाधर और तिरछी स्ट्रोक के बीच मोटाई में समान दृश्य अंतर) में त्रुटियां देता है।
2. कभी-कभी ऑटो-हिन्टिंग गलत कर्निंग की ओर जाता है, जैसे कि "डॉग" शब्द में "ओग" (इस उदाहरण में, फ़ॉन्ट से एक कर्लिंग तालिका का उपयोग किया गया था)।
3. ऑटो-हंटिंग पाठ की एक पंक्ति में त्रुटियों को जमा करने की एक ही समस्या की ओर जाता है, जिसके परिणामस्वरूप पाठ का दाहिना किनारा "notches।"

Autohinter अधिक जटिल फोंट के साथ बेहतर काम करता है, जैसे कि टाइम्स न्यू रोमन, लेकिन वही स्थिति समस्याएं अभी भी होती हैं।

क्या करें?

आगे देखते हुए, मैं आपको एक और उदाहरण दिखाऊंगा।







स्वीकार्य समाधान खोजना अभी भी संभव है! लेकिन पहले आपको यह मानने की ज़रूरत है कि किसी भी तरह के संकेत का उपयोग करने का कोई तरीका नहीं है और साथ ही किसी भी पैमाने पर पाठ का सही स्थान बनाए रखें। केवल पाठ बिना हिंटिंग के, अपने प्राकृतिक ब्लर के साथ। फिर भी, हम विघटन में सुधार कर सकते हैं, हालांकि हमें कुछ महत्वपूर्ण नहीं बलिदान करना होगा। अर्थात्, हम पाठ की ऊर्ध्वाधर स्थिति और ऊंचाई में थोड़ी सी अशुद्धि बर्दाश्त कर सकते हैं। अन्य बातों के अलावा, ट्रू टाइप हाइनिंग उसी तरह से काम करती है: 12, 13 पिक्सल की ऊँचाई वाले टेक्स्ट की लाइनें स्क्रीन पर समान ऊँचाई वाली होंगी, हालाँकि वे अलग दिखेंगी।







संक्षेप में, सटीक क्षैतिज स्थिति बनाए रखते हुए आंख को प्रसन्न करने वाले पाठ के लिए, हमें निम्नलिखित की आवश्यकता है:

1. एलसीडी मॉनिटर पर क्षैतिज सबपिक्सल आरजीबी चौरसाई का उपयोग करें।
2. केवल ऊर्ध्वाधर हिंटिंग का उपयोग करें और पूरी तरह से क्षैतिज छोड़ दें।
3. गैर-संकेतित ग्लिफ़ के लिए उच्च रिज़ॉल्यूशन पर गणना की गई सटीक ग्लिफ़ ऑफ़सेट वैल्यू का उपयोग करें।
4. कर्निंग टेबल से सटीक उच्च रिज़ॉल्यूशन मान का उपयोग करें।

एक छोटा गामा सुधार परिणाम में सुधार कर सकता है, लेकिन यह आवश्यक नहीं है। पाठ सीधे sRGB में भी अच्छा लगता है, जिसका अर्थ है कि उल्टे रंग योजनाओं में कोई समस्या नहीं होगी।



आप फ्रीटाइप और इसके ऑटो-सिंटर के साथ आसानी से स्वीकार्य परिणाम प्राप्त कर सकते हैं। इसका मतलब है कि आपको ट्रू टाइप की पेटेंट की गई हिंटिंग के बारे में चिंता नहीं करनी चाहिए। Win32 API के GetGlyphOutline () फ़ंक्शन का उपयोग करके समान किया जा सकता है। यह कठिन है, लेकिन फिर भी संभव है।

आरजीबी में सबपिक्सल रेखांकन

आप स्टीव गिब्सन, "सबपिक्सल रेस्टराइजेशन टेक्नोलॉजी" [2] के पन्नों पर RGB में सबपिक्सल रेस्टराइजेशन का उपयोग करने के लिए व्यापक मार्गदर्शन पा सकते हैं। मैंने 64-स्तर के स्मूथिंग बिटमैप्स के साथ इस तकनीक का उपयोग करने की कोशिश की, जो GetGlyphOutline () उत्पन्न कर सकता है: मैक्सिम शिमनारेव, "विंडोज लॉन्गहॉर्न में कैसे ClearType काम करता है" [3] (UPD: लिंक खराब है, लेकिन आप इसे यहाँ , यहाँ या यहाँ पढ़ सकते हैं )। आप इस लिंक पर सभी स्रोतों के साथ विंडोज के लिए डेमो प्रोग्राम डाउनलोड कर सकते हैं:

antigrain.com/stuff/lcd_font.zip



इसके अलावा, मैंने एक साधारण, "शाम को अपने घुटने पर," एजीजी के लिए रैस्टराइज़र लिखा। इसका अनुसरण करने वाले डेमो में पाया जा सकता है। फिलहाल, कोड असुरक्षित और धीमा है। यह डेमो के लिए सामान्य है, लेकिन एक वास्तविक परियोजना में अस्वीकार्य है, मुख्य रूप से क्योंकि यह स्टैक में 2048 पिक्सेल से अधिक नहीं के लिए एक अस्थायी बफर का उपयोग करता है।



सबसे सरल मामले में, हमें प्रत्येक रंग चैनल के लिए पारदर्शिता मूल्यों की आवश्यकता है। इस फ़ाइल में, agg_pixfmt_rgb24_lcd.h स्टीव गिब्सन द्वारा बताए गए अतिरिक्त कलंक का भी मैंने उपयोग किया। यह मक्खी पर चलता है, हालांकि यह कुछ प्रकार के कैशिंग तंत्र का उपयोग करके अग्रिम में किया जा सकता है। इस मामले में, यह बहुत तेजी से काम करेगा, कम से कम शास्त्रीय अल्फा सम्मिश्रण की तुलना में धीमा नहीं होगा।



चैनल मिश्रण को डिबग करने के लिए, मैंने ब्रायन फ्रीजेन के ज़ूमइन [9] कार्यक्रम का उपयोग किया। मैंने सभी तराजू पर रंगों के "डिकोडिंग" त्रिकोणीय जोड़े जो तीन के गुणक हैं। आप यहां निष्पादन योग्य फ़ाइल डाउनलोड कर सकते हैं: antigrain.com/stuff/ZoomInLcd.zip (2005 में मैं संशोधित स्रोतों। किसी भी मामले में, इन संशोधनों को अपने दम पर करना आसान है)। आप नियमित रूप से काले और सफेद और उपपिग्लस आरजीबी रेखांकन के बढ़े हुए परिणामों की तुलना कर सकते हैं:





ब्लैक एंड व्हाइट रैस्टराइज़ेशन





उपपिक्सेल आरजीबी रेखांकन

अन्य बारीकियों

ऊर्ध्वाधर हिंटिंग को संरक्षित करने के लिए, लेकिन क्षैतिज से छुटकारा पाने के लिए, हम बस हंटर को मूर्ख बनाते हैं: हम पात्रों को क्षैतिज रूप से खींचते हैं ताकि हिरन को उच्च परिशुद्धता के साथ काम करने के लिए मजबूर किया जाए। समस्या यह है कि FreeType के लिए AGG फ़ॉन्ट इंजन संकेत देते हुए गलत ऑफ़सेट मानों का उपयोग करता है। तकनीकी रूप से, हिरन को दृढ़ता से फैले ग्लिफ़ के लिए सटीक ऑफसेट मूल्यों की गणना करनी चाहिए, लेकिन किसी कारण से वह नहीं करता है। मुझे इसे मूल, "संयुक्त राष्ट्र-संकेतित" ऑफ़सेट्स का उपयोग करने के लिए संशोधित करना पड़ा। डेमो प्रोग्राम में एक संशोधित संस्करण भी शामिल है। ग्लिफ़ वक्र प्राप्त होने के बाद, हम इसे वापस संपीड़ित करने के लिए एफ़िन परिवर्तन का उपयोग करते हैं। सबसे सरल मामले में, यह हम सभी की जरूरत है। कर्नेल तालिका में काफी सटीक मान शामिल हैं।



इसलिए मैं डेविड टर्नर की ओर मुड़ना चाहता हूं: हो सकता है कि वह अपने ऑटोहेरेंट में एक विकल्प जोड़ने के लिए समझे जो केवल एक्स अक्ष के साथ संकेत देने की अनुमति देता है, एक्स अक्ष के साथ इशारा करते हुए? या आप मौजूदा 1 की तुलना में बहुत अलग 1-डी हिरन बना सकते हैं। जैसा कि आप देखेंगे, सबपिक्सल आरजीबी रेखांकन के साथ पाठ एडोब एक्रोबेट रीडर के समान दिखता है, और, किसी भी मामले में, किसी भी आधुनिक लिनक्स सिस्टम की तुलना में बहुत बेहतर है ( 2007 में लिखा गया लेख - लगभग। अनुवाद। )। मेरा मानना ​​है कि यह लिनक्स आधारित प्रणालियों की लोकप्रियता को बढ़ावा देने और बढ़ाने में मदद करेगा।



विंडोज एपीआई का उपयोग करना अधिक जटिल है। GetGlyphOutline () फ़ंक्शन पूर्णांक पिक्सेल में ऑफसेट मान लौटाता है, जो हमारे लिए बहुत अशिष्ट है। टूटती नहीं बचती। GetCharABCWidthsFloat () जैसे कार्य भी हैं, लेकिन वे बेकार हैं क्योंकि वे संकेतित ग्लिफ़ के लिए मूल्यों की गणना करते हैं और इस तथ्य के बावजूद कि उनमें फ्लोटिंग-पॉइंट नंबर होते हैं, सभी एक ही, वास्तव में, वे पूर्णांक हैं। इसलिए मुझे सटीक संतान प्राप्त करने का सरल तरीका नहीं मिला। नतीजतन, मुझे एक साथ दो फोंट का उपयोग करना पड़ा, एक 1024 पिक्सल की ऊंचाई के साथ, और दूसरे जिस आकार की हमें आवश्यकता थी, वह संकेत और एक खींचे हुए मैट्रिक्स के साथ। मैं मानता हूं कि मुझे कुछ याद हो सकता है, लेकिन मुझे इस पर कोई विचार नहीं है कि इसे और अधिक सही तरीके से कैसे लागू किया जा सकता है। शायद वे माइक्रोसॉफ्ट वर्ड में कुछ अनिर्दिष्ट सुविधाओं का उपयोग करते हैं, जो प्रतिस्पर्धा के मामले में पूरी तरह से बेईमानी है। बेशक, मैं इस बारे में पूरी तरह से निश्चित नहीं हो सकता, लेकिन स्थिति मुझे यह सोचने पर मजबूर करती है कि Microsoft जानबूझकर WYSIWYG दस्तावेज़ टूल विकसित करने के लिए एक अच्छा पर्याप्त एपीआई प्रदान नहीं करता है। यह एक विशिष्ट एकाधिकारवादी नीति है, जिसके परिणामस्वरूप तकनीकी प्रगति का निषेध होता है।



वास्तव में, यह और भी बुरा है। पेटेंट की गई हिरन "स्ट्रेच्ड" मैट्रिक्स के साथ काम नहीं करती है! कम से कम, मुझे एक भी स्केलिंग कारक नहीं मिला जो सही ढंग से ग्लिफ़ को संभाल सके। केवल 1: 1 पैमाने पर सही तरीके से काम किया गया, लेकिन परिणामस्वरूप मुझे वही समस्याएं मिलीं जिन्होंने मुझे चिकनी के साथ एक काले और सफेद रैस्टराइज़र का उपयोग करने के लिए मजबूर किया:







डरावना लगता है, है ना? किसी भी स्केलिंग ने गंभीर रूप से दूषित ग्लिफ़ का नेतृत्व किया। यहाँ, उदाहरण के लिए, इटैलिक टाइम्स न्यू रोमन (16x क्षैतिज खिंचाव):







या यहां तक ​​कि। एरियल (100x क्षैतिज स्ट्रेचिंग) - अजीब स्मूदी, सही? लेकिन इसे पढ़ना असंभव है:







मुझे लगता है कि यह कहने का कोई मतलब नहीं है कि फ्री टाइप ऑटोहर्ट किसी भी खिंचाव के लिए सही ढंग से काम करता है।



ऐसा लगता है कि Microsoft API बिना किसी इंजीनियरिंग संस्कृति और इस सब के पीछे वैश्विक विचार के बिना "घुटने पर" अस्वास्थ्यकर यादृच्छिक समाधान का एक गुच्छा है। आम तौर पर, आप केवल एक हार्ड-कोडेड तरीके से Microsoft सॉफ़्टवेयर का उपयोग कर सकते हैं। दाईं ओर एक कदम, बाईं ओर एक कदम - और सब कुछ चला गया है। यह उनके व्यवसाय के लिए अच्छा हो सकता है, लेकिन कम से कम उचित नहीं। इस तरह की नीति समान प्रतिस्पर्धा की स्थितियों का उल्लंघन करती है और परिणामस्वरूप बाजार में समग्र प्रगति को धीमा कर देती है। मीडिया प्लेयर या इंटरनेट एक्सप्लोरर को सिस्टम से हटाने के लिए हास्यास्पद आवश्यकताओं के बजाय, इस स्थिति पर एंटीमोनोपॉली कमेटी को ध्यान देना चाहिए।



अंत में, मुझे पता चला कि मूल्य "16" एक कम बुराई है, यह ज्यादातर मामलों के लिए उपयुक्त है, लेकिन अभी भी इटैलिक टाइम्स न्यू रोमन के लिए काम नहीं करता है।

डेमो कार्यक्रम

यहाँ यह एक विंडोज प्रोग्राम है जो ट्रू टाइप का उपयोग करता है:

www.antigrain.com/research/font_rasterization/truetype_test_02_ft.zip



और यहां वह संस्करण है जो विंडोज एपीआई का उपयोग करता है:

www.antigrain.com/research/font_rasterization/truetype_test_02_win.zip



FreeType के संस्करण को प्रोग्राम डायरेक्टरी में निम्न फ़ाइलों की आवश्यकता होती है: arial.ttf, ariali.ttf, georgia.ttf, georgiai.ttf, tahoma.ttf, times.ttf, timesi .ttf, verdana.ttf, verdanai.ttf। आप उन्हें% WINDIR% \ Fonts फ़ोल्डर में पा सकते हैं।



यदि आप इसे संकलित करना चाहते हैं, तो AGG संस्करण 2.4 या 2.5 डाउनलोड करें और फ़ाइलों को कहीं न कहीं agg-2.4 \ research \ win32 \ trutype_lcd \ *। * से खोल दें। FreeType संस्करण के लिए, आपको स्वयं FreeType बनाने की आवश्यकता होगी, और संभवतः प्रोजेक्ट सेटिंग्स को बदलना होगा।



कार्यक्रम को लिनक्स / एक्स 11 या किसी अन्य सिस्टम के लिए भी संकलित किया जा सकता है यदि आप एजीजी उदाहरणों में उपयोग किए गए लोगों के समान एक उपयुक्त मेकफाइल लिखते हैं।



FreeType और WinAPI के तहत संस्करणों में पाठ अलग-अलग संकेत एल्गोरिदम के कारण अलग दिखता है।







आपको यहां बड़ी संख्या में सेटिंग्स दिखाई देती हैं। सबसे पहले, हम फोंट को बदल सकते हैं, साथ ही चालू या बंद कर्निंग, हिन्टिंग और सबपिक्सल आरजीबी रेखांकन भी बदल सकते हैं। इसके अलावा, आप काले रंग की पृष्ठभूमि पर सफेद पाठ पाने के लिए छवि को उल्टा कर सकते हैं।



फ़ॉन्ट स्केल स्लाइडर आपको आसानी से फ़ॉन्ट आकार बदलने की अनुमति देता है। जैसा कि आप देख सकते हैं, जब संकेत चालू होता है, तो लाइनें पिक्सेल से बंधी होती हैं, लेकिन पाठ की चौड़ाई आसानी से बदलती रहती है। आप अंतराल को बदलकर इस प्रभाव को बेहतर ढंग से देख सकते हैं। संकेत के बिना, पाठ का लेआउट किसी भी पैमाने पर पूरी तरह से संरक्षित है, लेकिन पाठ धुंधला दिखता है। ऊर्ध्वाधर स्नैप लाइनें - पाठ की तीक्ष्णता और सटीकता के बीच सबसे उचित समझौता।मैं खुद हैरान हूं कि पात्रों के आकार को बनाए रखने के दौरान ऊर्ध्वाधर हिंटिंग गुणवत्ता में कैसे सुधार करती है।



अंतराल, चौड़ाई और इटैलिक इमीटेशन स्लाइडर्स, मुझे लगता है, टिप्पणियों की जरूरत नहीं है। कंप्यूटर ग्राफिक्स से परिचित लोगों के लिए, यह स्पष्ट है कि ये साधारण affine रूपांतरण हैं । मैं केवल एक तथ्य पर ध्यान देना चाहूंगा: "ब्लैक-एंड-व्हाइट" और "सब-पिक्सेल आरजीबी रैस्टोरेशन" मोड में, "इटैलिक सिमुलेशन" स्लाइडर थोड़ा अलग तरीके से काम करता है। ऐसा इसलिए है क्योंकि मैं आर्कटिक के माध्यम से इसके मूल्यों को सही ढंग से संसाधित करने के लिए बहुत आलसी था। किसी भी मामले में, यह महत्वपूर्ण नहीं है।



जिस फ़ंक्शन पर मुझे विशेष रूप से गर्व है, वह "बोल्ड की नकल" है। यह इस तरह काम करता है:







एक और सरल चाल है। AGG के हिस्से के रूप मेंएक उपयोगिता conv_contour है जो आपको किसी दिए गए बहुभुज के लिए समतुल्य गणना करने की अनुमति देता है। लेकिन इसका सीधा उपयोग बहुत धुंधला परिणाम देता है, और साथ ही संकेतों के आकार में काफी बदलाव करता है (हालांकि यह चमक और छाया प्रभाव के लिए उपयोगी हो सकता है):







धुंधला से बचना आसान है। हम ग्लिफ़ को लंबवत रूप से फैलाते हैं, कहते हैं, 100 या 1000 बार, समभुज बहुभुज की गणना करें और इसे वापस संपीड़ित करें। इसलिए, परिणामस्वरूप, Y अक्ष के साथ निर्देशांक लगभग नहीं बदलता है और पाठ स्पष्ट रहता है। डेमो प्रोग्राम में एक faux_weight क्लास है। फिर, यह आश्चर्यजनक है कि कितने अवसर मुफ्त क्षैतिज स्केलिंग देते हैं। और कोई कम आश्चर्यजनक नहीं, पिक्सेल के लिए लंबवत तड़कने से दृश्य परिणाम में सुधार होता है।



एक और उदाहरण (मुझे यह स्वतंत्रता पसंद है):







यह सभी एक ही जॉर्जिया हेडसेट है, लेकिन केवल सॉफ्टवेयर परिवर्तित। एक ही समय में पूरी तरह से पठनीय, कुरकुरा और चिकना (हां, मैं सहमत हूं, वह मैनुअल कर्निंग से आहत नहीं होगा)।



या ताओमा हेडसेट के लिए समान:







गामा समायोजन स्लाइडर गामा सुधार को नियंत्रित करता है (यह प्रत्येक चैनल के लिए अलग से किया जाता है)। सैद्धांतिक रूप से, आपको "प्रत्यक्ष सरगम" को मूल रंगों पर लागू करना चाहिए, और फिर, दृश्य को प्रस्तुत करने के बाद, "उल्टे सरगम" को लागू करें। लेकिन, चूंकि इन उदाहरणों में पाठ हमेशा सफेद या काला होता है, इसलिए पहले ऑपरेशन का कोई मतलब नहीं है।



स्टीव गिब्सन द्वारा वर्णित प्राथमिक वज़न स्लाइडर ऊर्जा वितरण को नियंत्रित करता है: www.grc.com/freeandclear.htm। यह केवल प्राथमिक वजन का प्रबंधन करने के लिए पर्याप्त है, और शेष की गणना उसी के अनुसार की जाती है। प्राथमिक वजन बढ़ाकर, आप पाठ को स्पष्ट कर सकते हैं, लेकिन वर्णों के चारों ओर एक रंगीन रूपरेखा दिखाई देती है। यह 0.5 तक मूल्यों का उपयोग करने के लिए समझ में आता है, बड़े मूल्यों के साथ रंग "चमक" भी ध्यान देने योग्य हो जाता है। मेरे लिए, Windows ClearType बहुत ध्यान देने योग्य रंग "चमक" भी देता है।

इस तरह के रेखांकन जल्दी से काम कर सकते हैं

डेमो प्रोग्राम बहुत धीमा है। आंशिक रूप से क्योंकि वेक्टर ऑपरेशन मक्खी पर किया जाता है, लेकिन मुख्य रूप से WinAPI GetGlyphOutline () फ़ंक्शन के कारण होता है, जो अपने आप में बहुत धीमा है। दूसरी ओर, इस तरह के रेखापुंज पाठ के किसी भी हार्डवेयर त्वरित रेखापुंजकरण से कम तेज़ नहीं हो सकते हैं। लेकिन पहले, आपको इस बात पर सहमत होना चाहिए कि संकेत, सही लेआउट और स्पष्ट उप-गुणवत्ता की गुणवत्ता बनाए रखते हुए मनमाने ढंग से परिवर्तनशील पाठ के रेखांकन में तेजी लाना, सिद्धांत रूप में, एक आसान काम नहीं है। मनमाने ढंग से परिवर्तनों से मेरा तात्पर्य है, वास्तव में मनमाना दृष्टिकोण, जिसमें परिप्रेक्ष्य और कोई गैर-रेखीय परिवर्तन शामिल हैं।



अधिकांश समय हमें पूर्वी एशियाई भाषाओं का उपयोग करते समय क्षैतिज पाठ से निपटना पड़ता है। इसके अलावा, अधिकांश ग्लिफ़ एक ही नाममात्र आकार का उपयोग करते हैं। यह इस प्रकार है कि एक कैशिंग तंत्र यहाँ काम आएगा। तीन आरजीबी चैनलों के लिए एक उप-काले और सफेद मास्क को तीन बार अधिक मेमोरी की आवश्यकता होती है, लेकिन एक ही समय में पिक्सेल की 1/3 तक की टेक्स्ट पोजिशनिंग सटीकता होती है। ज्यादातर मामलों में, यह काफी अच्छी तरह से काम करता है। जब तक सैद्धांतिक "शानदार" रैस्टराइजेशन के लिए, आप 1/6 पिक्सेल की सटीकता प्राप्त करते हुए, प्रति ग्लिफ में दो ब्लैक-एंड-व्हाइट मास्क का उपयोग कर सकते हैं। यहां तक ​​कि सॉफ्टवेयर अल्फा मिक्सिंग काफी तेज काम करती है - आधुनिक इंटेल प्रोसेसर या पीपीसी पर लगभग 2-4 एमएस प्रति ग्लिफ़। GPU का उपयोग करना, यह तब और भी तेज़ी से हो सकता है जब आप उपयुक्त बनावट को लोड करते हैं।एकमात्र समस्या यह है कि GPU को चैनलों पर अल्फा सम्मिश्रण की अनुमति देनी चाहिए, जो कि जहां तक ​​मुझे पता है, संभव है। कम से कम डेविड ब्राउन ने इसका उल्लेख कियाउनकी प्रस्तुति में []]। लेकिन मुझे इस विषय पर अधिक जानकारी नहीं मिल पाई (पिक्सेल शेडर से 6-चैनल आउटपुट कैसे प्राप्त करें) और अगर आप मुझे इस विषय पर कोई लिंक देंगे तो मैं आभारी रहूंगा।

संदर्भ

1. जोएल स्पोल्स्की, फॉन्ट स्मूथिंग, एंटी-अलियासिंग, और उप-पिक्सेल रेंडरिंग।
   
   www.joelonsoftware.com/items/2007/06/12.html
2. स्टीव गिब्सन, उप-पिक्सेल फ़ॉन्ट प्रतिपादन प्रौद्योगिकी।
   
   www.grc.com/cleartype.htm
3. मैक्सिम शेमनारेव, इनसाइड क्लियरटाइप में विंडोज लॉन्गहॉर्न।
   
   www.byte.com/documents/s=9553/byt1113241694002/0411_shemanarev.html
   
   (ऑनलाइन पंजीकरण की आवश्यकता है)
4. FontFocus श्वेत पत्र, Artofcode.com/fontfocus
5. जेफ एटवुड, फ़ॉन्ट प्रतिपादन: पिक्सेल ग्रिड का सम्मान।
   
   www.codinghorror.com/blog/archives/000885.html
6. Charles Poynton, Frequently-Asked Questions about Gamma.
   
   www.poynton.com/GammaFAQ.html
7. Dave Shea, A Subpixel Safari.
   
   mezzoblue.com/archives/2007/06/12/a_subpixel_s
8. David Brown, Avalon Text. A PowerPoint presentation.
   
   download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04007_WINHEC2004.ppt
9. Brian Friesen, ZoomIn Program.
   
   www.csc.calpoly.edu/~bfriesen/software/zoomin.shtml
10. David Turner and the others, FreeType font Library.
    
    freetype.org
11. Jim Mathies, XP Style DPI Scaling.
    
    www.mathies.com/weblog/?p=908
12. Long Zheng, Windows Vista DPI scaling: my Vista is bigger than your Vista
    
    www.istartedsomething.com/20061211/vista-dpi-scaling

पुनश्च: वेब संग्रह में लेख का पहला भाग (चित्रों के साथ)। वेब संग्रह में लेख का दूसरा भाग (चित्रों के साथ)।



पीपीएस: स्क्रीन टाइपोग्राफी के विषय में रुचि रखने वालों के लिए कुछ दिलचस्प लिंक:

टाइपफेस: यह

विंडोज 8 में एक बजट मॉनीटर पर सरल फ़ॉन्ट नहीं है

विंडोज ओएस में उच्च डीपीआई मान

प्रोग्रामर की रक्षा के लिए।