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

विशेष रूप से सार्वजनिक रूप से उपलब्ध जानकारी का उपयोग करके फ़ॉन्ट रैस्टराइज़ेशन एल्गोरिदम को बेहतर बनाने का प्रयास।

अनुवादक से

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



उपयोग की जाने वाली कुछ शर्तों में आमतौर पर रूसी समकक्षों को स्वीकार नहीं किया जाता है। मैं एंटी-अलियासिंग को एंटी-अलियासिंग के रूप में अनुवाद करूंगा (जैसा कि विकिपीडिया का मानना ​​है, और मैं इससे सहमत हूं), हिंटिंग के रूप में संकेत देना (संकेत करना, मेरी राय में, बहुत सामंजस्यपूर्ण नहीं है और सभी सामान्य शब्दों में नहीं है, और रस्टीजेशन के रूप में प्रतिपादन करना) (फोंट के रूप में लागू किया जाता है) यह शब्द मुझे अंग्रेजी से ट्रेसिंग पेपर से अधिक उपयुक्त लगता है; "ड्राइंग", मेरी राय में, बहुत सामान्य अवधारणा है)।



उन लोगों के लिए जो पहले स्क्रीन टाइपोग्राफी के विषय में रुचि नहीं रखते थे, लेख को पढ़ने से पहले ऊपर दिए गए लिंक का पालन करना और इन सभी शब्दों का अर्थ जानने के लिए उपयोगी होगा।



लेख 2007 में प्रकाशित किया गया था, और इसमें उल्लेखित विंडोज का नवीनतम संस्करण विस्टा है। फिर भी, अधिकांश लेख इस दिन के लिए प्रासंगिक है: विंडोज 7 में, फ़ॉन्ट रैस्टोरेशन तंत्र विस्टा से बहुत दूर नहीं गए हैं, और वेब प्लेटफॉर्म पर इंटरफेस को स्थानांतरित करने की प्रवृत्ति ने विभिन्न ब्राउज़रों में अलग-अलग ऑपरेटिंग सिस्टम में रैस्टिरेशन में अंतर करने के लिए रेखांकन अंतर को जोड़ा है। इसलिए, मेरी राय में, लेख में प्रस्तुत विचार अब तक प्रासंगिकता नहीं खोते हैं।



मैंने स्क्रीनशॉट में ग्रंथों का अनुवाद नहीं किया: एक तरफ, मेरे पास सही चित्र तैयार करने की तकनीकी क्षमता नहीं थी, दूसरी तरफ, उन पर किसी भी तरह से लेख के अर्थ को प्रभावित नहीं करता है।



मैं पारंपरिक रूप से मीट्रिक को इकाइयों में बदलने की कोशिश करता हूं, केवल रूसी आईटी उद्योग में स्वीकार किए जाने वाले लोगों को छोड़कर, जैसे कि डीपीआई। इसके अलावा, मैं नामों का अनुवाद करता हूं, लेकिन कंपनियों और उनके उत्पादों के अंग्रेजी नामों को छोड़ देता हूं।



मैं अनुवाद के किसी भी परिवर्धन या सुधार के लिए आभारी रहूंगा। कृपया स्पष्ट त्रुटियों और टाइपोस के बारे में निजी संदेश लिखें - हमने टिप्पणियों पर रोक नहीं लगाई है। आपका धन्यवाद

प्रविष्टि

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



जेफ एटवुड, अपनी पोस्ट में फ़ॉन्ट्स के रेखांकन: पिक्सेल ग्रिड से चिपका [5] लिखते हैं:

"मुझे समझ में नहीं आता कि Apple भविष्य के लिए वर्तमान का त्याग क्यों कर रहा है।" हम उच्च रिज़ॉल्यूशन की सटीकता का अवलोकन करते हुए, कम रिज़ॉल्यूशन पर हिन्टिंग का उपयोग क्यों नहीं कर सकते हैं? फोंट को पिक्सेल ग्रिड से जोड़ना सबसे अधिक अप्रासंगिक होने की संभावना है जब हर कोई 200 डीपीआई के संकल्प के साथ अपने मॉनिटर की स्क्रीन पर एक शानदार तस्वीर का आनंद ले सकता है। लेकिन जब तक वह महान समय नहीं आया है, तब तक एक पिक्सेल ग्रिड के लिए स्नैपिंग निश्चित रूप से उन लोगों के लिए पाठ को अधिक पठनीय बनाता है जो वर्तमान में रहते हैं। ”

मैं इसका इस तरह से जवाब दूंगा: जब तक Microsoft अपनी आक्रामक संकेत नीति का पालन करता है, 100 DPI से अधिक के रिज़ॉल्यूशन वाले मॉनिटर बस दिखाई नहीं देंगे। Microsoft के प्रयासों के माध्यम से, हम केवल दुष्चक्र से बच नहीं सकते।



जेफ एप्पल उत्पादों में इस्तेमाल होने वाले रैस्टराइजेशन विधि को मंजूरी नहीं देता है। वह मेरे लिए बहुत सुंदर भी नहीं है। लेकिन शायद Apple का मिशन 200 DPI मॉनिटर के युग को करीब लाना है? ठीक है, मेरी पट्टी और भी ऊंची है, मुझे 300 डीपीआई चाहिए। मेरी राय में, 200 डीपीआई भी पूरी तरह से संकेत छोड़ने के लिए पर्याप्त नहीं है। फिर भी, इस लेख में मैं एप्पल की रणनीति को उजागर करने की कोशिश करूंगा। लेख आपको लंबा और उबाऊ लग सकता है, लेकिन मुझे मौजूदा स्थिति का सावधानीपूर्वक और गहन विश्लेषण करने की आवश्यकता है।



थोड़ी साज़िश जोड़ने के लिए, मैं आगे देखूंगा और आपको कुछ उदाहरण दिखाऊंगा।







धुंधला दिखता है? लेकिन पाठ के आकार पर ध्यान दें। और ध्यान रखें कि यह पूरी तरह से पठनीय, चिकना और एक ही समय में स्पष्ट रहता है। और एक ही समय में, संकेतों का आकार पूरी तरह से संरक्षित है (एरियल हेडसेट का उपयोग किया जाता है)।



ठीक है, इस उदाहरण के बारे में क्या?







बहुत भारी लग रहा है? कोई बात नहीं, हम इसे उज्जवल बना सकते हैं।







और कुछ और उदाहरण:











यह जॉर्जिया का फ़ॉन्ट है। कृपया ध्यान दें कि दोनों मामलों में पात्रों का आकार पूरी तरह से संरक्षित है, बस दूसरे उदाहरण में पाठ जानबूझकर अधिक "भारी" बनाया गया है।



लेकिन यह सिर्फ एक प्रदर्शन था, यहां इस लेख का मुख्य विचार है: हम पिक्सेल ग्रिड को क्षैतिज स्नैप से मना कर सकते हैं! अब से, आप 1/256 पिक्सेल पर पाठ की क्षैतिज स्थिति सटीकता का उपयोग कर सकते हैं! पाठ के सुंदर स्वरूप को बनाए रखते हुए, आप किसी भी आंशिक मूल्य द्वारा पाठ को क्षैतिज रूप से स्थानांतरित कर सकते हैं! यह "ट्रिफ़ल" वास्तव में बहुत मायने रखता है। इसके बारे में कैसे:

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

कुछ असंभव जैसा लगता है? ठीक है, यहाँ एक और उदाहरण है।







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



यदि आप कल्पना नहीं कर सकते, तो यहाँ एक उदाहरण है:







सबसे आश्चर्यजनक बात यह है कि यहाँ कुछ भी काल्पनिक रूप से जटिल नहीं है! पेटेंट के लिए कुछ भी नहीं है। मेरे द्वारा उपयोग की जाने वाली सभी जानकारी सार्वजनिक रूप से उपलब्ध है और / या तार्किक रूप से हम जो वर्तमान में उपयोग किए जाने वाले फ़ॉन्ट रैस्टोरेशन एल्गोरिदम के बारे में जानते हैं, से अनुमान लगाते हैं। आपको बस सामान्य ज्ञान और थोड़ा इंजीनियरिंग स्वभाव चाहिए। तो चलिए चलते हैं। आप इस लेख के अंत में सभी स्रोत कोड के साथ डेमो प्रोग्राम डाउनलोड कर सकते हैं, और इसके साथ खेल सकते हैं, लेकिन एक शुरुआत के लिए, कृपया इस लंबी कहानी को अंत तक पढ़ने के लिए थोड़ा धैर्य दिखाएं।

Microsoft, Apple, Adobe और FontFocus

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



थोड़ा परीक्षण। कल्पना कीजिए कि हमारे पास टाइम्स न्यू रोमन हेडसेट द्वारा टाइप की गई एक पंक्ति है और उच्च रिज़ॉल्यूशन में मुद्रित है (उदाहरण के लिए, बिल्कुल 1000 डीपीआई)। यह रेखा कागज पर दी गई दूरी का 87% (मान लीजिए 12.7 सेमी) लेती है। अब हमें कम रिज़ॉल्यूशन में समानुपातिक छवि प्राप्त करने की आवश्यकता है, कहते हैं, 100 डीपीआई ताकि हमारा 12.7 सेमी बिल्कुल 500 पिक्सल के अनुरूप हो। क्या विंडोज पर पाठ प्रदर्शित करने का एक तरीका है जो 500 पिक्सल के 87% हिस्से पर कब्जा करता है? नहीं! यह नीचे स्क्रीनशॉट से स्पष्ट है। उन्हें विंडोज एक्सपी, "स्क्रीन गुण -> विकल्प -> उन्नत -> सामान्य -> ​​स्केल (डॉट्स प्रति इंच) -> विशेष सेटिंग्स ..." से हटा दिया जाता है।









वे ( Microsoft। लगभग। अनुवाद। ) पैसे की खातिर इंजीनियरों के सम्मान का बलिदान किया, जिसके कारण तकनीकी प्रगति की कमी ( मॉनिटरों के संकल्प को बढ़ाने में लगभग। अनुवाद। ) कई वर्षों तक चली । वे एक अत्यधिक आक्रामक संकेत का उपयोग करते हैं, जो न केवल वर्णों के आकार को विकृत करता है, बल्कि पूरे लाइन में एक महत्वपूर्ण त्रुटि ( क्षैतिज समन्वय, लगभग अनुवाद ) को जमा करता है। नतीजतन, फोंट को स्वतंत्र रूप से स्केलेबल नहीं माना जा सकता है, वे केवल स्केलेबल दिखते हैं, लेकिन वास्तव में ऐसा नहीं है। इस तथ्य ने कंप्यूटर मॉनीटर उद्योग को प्रभावित किया है। क्या आप 600 डीपीआई के रिज़ॉल्यूशन वाले मॉनिटर पर विंडोज एक्सपी की कल्पना कर सकते हैं? कहो, 8000x6000 पिक्सेल? मैं न केवल बिटमैप आइकन के कारण, बल्कि पाठ के भयानक स्केलिंग के कारण भी नहीं कर सकता। यदि आप स्क्रीन गुणों में रिज़ॉल्यूशन को बदलते हैं, तो प्रोग्राम में कुछ डायलॉग बॉक्स अनिवार्य रूप से गलत तरीके से प्रदर्शित किए जाएंगे। तदनुसार, उच्च-रिज़ॉल्यूशन मॉनिटर के उत्पादन के लिए प्रेरणा क्या है?



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



कुछ समय पहले मैंने जॉनसन एंड जॉनसन (हैलो दिमित्रीस एग्रफ़ियोटिस और अन्य सहयोगियों) के लिए काम किया था और मुझे .Net WinForms प्लेटफ़ॉर्म के लिए जटिल डायलॉग बॉक्स डिज़ाइन करने पड़े। डिफ़ॉल्ट रूप से, किसी भी स्थिर या संपादन योग्य पाठ के लिए "तहोमा, 10pt" जैसी चीज़ का उपयोग किया गया था। लेकिन मुझे लगातार पाठ की प्रत्येक पंक्ति के अंत में कुछ अतिरिक्त खाली स्थान के बारे में चिंता करना पड़ता था, क्योंकि संकल्प बदलने के बाद पाठ नियमित रूप से आवंटित स्थान में फिट नहीं होता था, और रूपों का उपयोग करना पूरी तरह से असंभव था। इसलिए यदि आप आनुपातिक स्केलिंग के बारे में चिंतित हैं, तो आपको अपने रूपों को एक भयानक तरीके से प्रारूपित करना होगा, जिससे बड़ी मात्रा में खाली स्थान "रिजर्व" हो जाएगा। दूसरा तरीका यह है कि आप टेक्स्ट साइज को पिक्सल के साथ सख्ती से बांधें। यही है, "तहोमा 14 पीएक्स " ( नोट पीएक्स, पीटी नहीं। अप्रोच। ट्रांसलेशन। ) जैसे कुछ का उपयोग करें। इसका मतलब बहुत है। इसका अर्थ है कि आपके सॉफ़्टवेयर का उपयोग उच्च रिज़ॉल्यूशन पर नहीं किया जा सकता है। इससे कोई फर्क नहीं पड़ता कि विंडोज विस्टा टेक्स्ट स्केलिंग का कितना अच्छा समर्थन करता है: वैसे भी, परेशानी पहले ही हो चुकी है। एक बड़ी मात्रा में सॉफ़्टवेयर है जो निश्चित रिज़ॉल्यूशन पर निर्भर करता है और यह मॉनिटर निर्माताओं को उच्च-रिज़ॉल्यूशन स्क्रीन को विकसित करने से रोकता है। कोई प्रेरणा नहीं है! आपको मुझे और कई अन्य सॉफ्टवेयर डेवलपर्स और डिजाइनरों को दोष नहीं देना चाहिए। माइक्रोसॉफ्ट को उनके क्रूर संकेत के लिए दोषी ठहराते हैं, जो ग्राफिक तत्वों पर पाठ के अप्रत्याशित क्रॉल की ओर जाता है।



हां, विंडोज विस्टा में WPF के साथ, सब कुछ स्वतंत्र रूप से स्केलेबल हो जाता है। यह अच्छी खबर है। बुरी खबर यह है कि आप वैसे भी उच्च प्रस्तावों का उपयोग नहीं कर सकते हैं। लोंग त्सेंग और जिम मैथ्यू द्वारा मुद्दों का विस्तार से वर्णन किया गया है:

लंबे झेंग, विंडोज विस्टा डीपीआई स्केलिंग: मेरा विस्टा आपके विस्टा से बड़ा है।

www.istartedsomething.com/20061211/vista-dpi-scaling

जिम मैथिस, एक्सपी स्टाइल डीपीआई स्केलिंग।

www.mathies.com/weblog/?p=908

Microsoft और Adobe: सबपिक्सल पोजिशनिंग और कर्निंग

Microsoft Word में, जो WYSIWYG के सिद्धांत पर बनाया गया है, किसी भी रिज़ॉल्यूशन पर सही लेआउट बनाए रखना महत्वपूर्ण है। इसका मतलब यह है कि मार्कअप स्वतंत्र रूप से स्केलेबल होना चाहिए, और यह वास्तव में स्केलेबल है। लेकिन मुझे थोड़ी जांच करनी चाहिए। नीचे दिया गया पाठ ऐसा है जो Office 2003 से Microsoft Word में दिखता है। इस पाठ को पढ़ने का कोई मतलब नहीं है, बस इसे देखें।







और एडोब एक्रोबेट रीडर में जैसा दिखता है उससे तुलना करें:







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

यदि एनालॉग सिग्नल में एक सीमित स्पेक्ट्रम है, तो यह विशिष्ट रूप से और दोषरहित रूप से अपने असतत नमूनों से फिर से संगठित किया जा सकता है, जो आवृत्ति के साथ लिया जाता है, जो स्पेक्ट्रम की अधिकतम आवृत्ति से दो गुना अधिक होता है।

हमारे मामले में, संकेत के स्पेक्ट्रम से हमारा मतलब है कि नमूना आवृत्ति। व्यवहार में, इसका मतलब है कि आप एक ही समय में स्पष्ट रूप से और समान अंतराल के साथ ऊर्ध्वाधर रेखाओं के एक सेट को सही ढंग से प्रदर्शित नहीं कर सकते हैं, जब तक कि अंतराल पिक्सेल के गुणक हैं। या तो लाइनों के बीच की दूरी कूद जाएगी, या कुछ लाइनें धुंधली दिखाई देंगी। कोई अन्य विकल्प नहीं है, अवधि।



पियरे अरनौद ने इसे और भी बेहतर तरीके से प्रदर्शित किया:

मान लीजिए कि आपको "i" वर्ण के लिए एक ग्लिफ़ का उत्पादन करने की आवश्यकता है, जो बिल्कुल 2.4 पिक्सेल चौड़ा होगा। यदि आप हिंटिंग का उपयोग करते हैं, तो सबसे अधिक संभावना है कि आपको एक छवि मिलेगी जो आउटपुट पर 2 पिक्सेल चौड़ी है। मान लीजिए कि हमारे पास चार पिक्सेल हैं।

अब कल्पना करें कि आपको "iiiiiiii" (ग्लिफ़ "i" 10 बार) आउटपुट करने की आवश्यकता है। यह हमें एक ऐसा शब्द देगा जो स्क्रीन पर 20 पिक्सेल रखता है, लेकिन टाइपोग्राफिक स्थिति 24 पिक्सेल द्वारा स्थानांतरित होनी चाहिए। प्रभावी ढंग से इसके आकार को दोगुना करने के लिए, आपको बाद के स्थान पर 4 पिक्सेल जोड़ना होगा। यह स्क्रीन पर बल्कि अजीब लगेगा। अगर ग्लिफ़ "i" वास्तव में 2.6 पिक्सेल लेता है, तो यह और भी बुरा होगा, और hinter इसे 3 पिक्सेल तक फैलाने का निर्णय लेता है। इस स्थिति में, आप स्क्रीन पर 30 पिक्सल्स पर कब्जा कर लेंगे, हालाँकि टाइपोग्राफिक पोजीशन में 26 पिक्सल्स होने चाहिए। इस स्थिति में, आपको -4 पिक्सेल की त्रुटि मिलती है, और इस त्रुटि के लिए क्षतिपूर्ति पूरी तरह से बाद के स्थान को खाती है।



एक और प्रयास उनके टाइपोग्राफिक पदों को गोल करके ग्लिफ़ "i" की स्थिति में हो सकता है। इस दृष्टिकोण को लागू करने के परिणामस्वरूप, हमें x अक्ष के साथ निम्नलिखित निर्देशांक प्राप्त होंगे (मामले में 2.4 पिक्सेल की ग्लिफ़ चौड़ाई के साथ):

 x = 0 ----> 0 त्रुटि = 0 चौड़ाई = 2
 x = 2.4 -> 2 त्रुटि = -0.4 चौड़ाई = 3
 x = 4.8 -> 5 त्रुटि = +0.2 चौड़ाई = 2
 x = 7.2 -> 7 त्रुटि = -0.2 चौड़ाई = 3
 x = 9.6 -> 10 त्रुटि = +0.4 चौड़ाई = 2

परिणाम भयानक होगा:

 । *। * .. *। *। * * *
 ............
 । *। * .. *। *। * * *
 । *। * .. *। *। * * *
 । *। * .. *। *। * * *
 । *। * .. *। *। * * *

आपको यह विचार मिलता है ... ग्लिफ़ "i" के बीच का अंतराल परिवर्तनशील हो जाता है।

हाँ, वे हैं। Microsoft Word में ठीक यही होता है।







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











एडोब ग्लिफ़्स "i", "n", "s", "t" पर एक नज़र डालें। विभिन्न पदों में उनके प्रदर्शन के कम से कम दो अलग-अलग संस्करण हैं। यही कारण है कि एडोब में पाठ अधिक समान दिखता है, लेकिन एक ही समय में अधिक धुंधला हो जाता है।



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



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



विशुद्ध रूप से इंजीनियरिंग के दृष्टिकोण से, पाठ स्पष्टता और कार्यक्षमता के बीच एक उचित समझौता होना चाहिए। समस्या यह है कि Microsoft ने ग्लैमरस डिज़ाइन पर ध्यान केंद्रित किया है, जबकि कार्यात्मक भाग को पूरी तरह से अनदेखा किया है। विरोधाभास: 300 DPI में आपको बिल्कुल भी हिंट करने की आवश्यकता नहीं है, इसके अलावा, पाठ स्वतंत्र रूप से स्केलेबल हो जाता है (और 600 DPI पर और इससे अधिक आपको एंटी-एलियासिंग की भी आवश्यकता नहीं है), लेकिन आप 300 DPI के लिए अपने सॉफ़्टवेयर का उपयोग नहीं कर सकते, क्योंकि यह 100 DPI पर रेट किया गया! यहां वह कीमत है जो पूरी दुनिया एक ग्लैमरस लुक के लिए अदा करती है। यह कीमत बहुत अधिक है, बस अविश्वसनीय रूप से उच्च है।



इस के बावजूद, यहां तक ​​कि 5 (पांच!) साल पहले यह तकनीकी रूप से संभव था कि स्वतंत्र रूप से स्केलेबल फॉर्म और डायलॉग बॉक्स हो। हम सभी की जरूरत थी एक निश्चित डिग्री के धब्बा की अनुमति देने के लिए, बहुत मामूली, मैक ओएस एक्स के बजाय उच्च के रूप में नहीं। एडोब उत्पादों के रूप में। विंडोज उपयोगकर्ताओं को सफारी के लिए आउटपुट पसंद नहीं है जो बहुत धुंधली है। मैं उन लोगों के साथ आंशिक रूप से सहमत हूं, जो विंडोज में उपयोग किए जाने के अलावा किसी भी अन्य रेखांकन विधि को नेत्रहीन रूप से नकारने के साथ हैं। यह सिर्फ लापरवाह कट्टरता है। यह कहने के समान है कि "मैं संकल्प के बारे में कोई ध्यान नहीं देता, विंडोज को मेरे द्वारा उपयोग किए जाने वाले तरीके को देखो, भले ही 96 DPI की कीमत पर, भले ही इसके लिए तकनीकी प्रगति को रोकने की आवश्यकता हो।" क्या इस तरह के विचार को उचित माना जा सकता है?



मैं Apple के पक्ष में आंदोलन नहीं करता, क्योंकि मैं Apple के विघटन से खुश नहीं हूँ। मेरी राय में, यह वास्तव में बहुत धुंधला दिखता है। वे एक ऑटो-हिन्टिंग एल्गोरिदम की तरह कुछ का उपयोग करते हुए प्रतीत होते हैं जो क्षैतिज स्ट्रोक लगाता है, लेकिन वास्तव में कोई लाभ नहीं देता है। वास्तव में, उनकी हिंटिंग भी टेढ़ी-मेढ़ी लगती है, विशेषकर सेन्स-सेरिफ़ फोंट के लिए, जैसे कि उन्होंने जानबूझकर कुरकुरा पाठ को 0.2..0.5 पिक्सेल से स्थानांतरित कर दिया हो। यही कारण है कि विंडोज उपयोगकर्ताओं को सफारी पसंद नहीं है। लेकिन एक ही समय में, उनमें से कई एडोब एक्रोबेट रीडर का उपयोग करके खुश हैं और संतुष्ट हैं। ऐसा इसलिए है क्योंकि इसमें पाठ स्वीकार्य लगता है (बिल्कुल सही नहीं, लेकिन विंडोज प्रशंसकों के लिए स्वीकार्य)। हालांकि, यह स्वतंत्र रूप से स्केलेबल रहता है! बस किसी भी दस्तावेज़ को लोड करने और अंदर और बाहर आसानी से ज़ूम करने का प्रयास करें। पाठ का मार्कअप सही रहता है,और कर्नेल भी। इसलिए मैं एडोब की सबसे अच्छी रेंडरिंग विधि को सबसे अच्छा कहूंगा, क्योंकि उनका समझौता इष्टतम के बहुत करीब दिखता है।

ClearType: ?

जेफ एटवुड [5] पिक्सेल ग्रिड के लिए सख्त बंधन के पक्ष में असमान रूप से बोलते हैं । मेरी अपनी राय है। मैं पिक्सेल ग्रिड से सहमत होने के लिए सहमत हूं, लेकिन केवल वाई अक्ष के साथ। एक्स पर यह उप-पिक्सेल स्थिति का उपयोग करने के लिए बेहतर है। उसी समय, हम कठोरता (लेकिन बहुत कम) का त्याग करते हैं, लेकिन पूर्ण स्वतंत्रता प्राप्त करते हैं।



विडंबना यह है कि माइक्रोसॉफ्ट के पास पहले से ही ग्लिफ़ हिंटिंग में उप-पिक्सेल स्थिति है। मजेदार बात यह है: जेफ के पृष्ठों पर यह स्पष्ट रूप से दिखाई देता है कि वह किस फ़ॉन्ट का उपयोग करता है।







ध्यान से देखें: शब्द "आम", लाल रंग में हाइलाइट किया गया, साथ ही अक्षर "एम" भी।







देखें, तीन ऊर्ध्वाधर "मी" डैश अलग हैं! इसके बावजूद, मूल पाठ में वे काफी स्पष्ट और आकर्षक रूप से दिखते हैं। इसका क्या मतलब है? बहुत कुछ।इसका मतलब है कि ClearType के साथ 1/3 पिक्सेल की सटीकता के साथ स्थिति का उपयोग करना संभव है। तो फिर वे ग्लिफ़ को पिक्स से क्यों जोड़ते हैं? मुझे नहीं मिला एक ही समय में सटीक कर्निंग और स्पष्ट पाठ के लिए 1/3 पिक्सेल सटीकता पर्याप्त होगी! खैर, अगर मैंने आपको आश्वस्त नहीं किया है, तो मैं विस्तार से प्रदर्शित करूंगा। मैंने Microsoft Word से पाठ की एक पंक्ति का स्क्रीनशॉट लिया। यह इस तरह दिखता है:







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







और फिर मैं आरजीबी मॉडल में इस नक्शे को "ग्रे-मिश्रित" करता हूं, प्रत्येक रंग चैनल को एक अलग ग्रे पिक्सेल के रूप में मानता है। मैंने यह 12 बार 1 ग्रे पिक्सेल की ऑफसेट के साथ किया, आरजीबी में 1/3 पिक्सेल का ऑफसेट प्राप्त किया। देखिए क्या हुआ:







लेकिन यह सबपिक्सल पोजीशनिंग है! आप इसे आसानी से सत्यापित कर सकते हैं: 4 अतिरिक्त पिक्सेल 12 लाइनों पर जमा हो गए हैं, जबकि पात्रों की स्पष्टता प्रभावित नहीं हुई है। खैर, लाइनें थोड़ी अलग हैं, लेकिन आपको यह ध्यान देने के लिए बहुत बारीकी से देखना होगा (मैं ध्यान देता हूं कि मेरे पास एक दृष्टि है और मैं चश्मा नहीं पहनता हूं)। मेरा विश्वास करो, यह सटीक उप-पिक्सेल स्थिति की स्वतंत्रता के लिए बहुत कम कीमत है! तो यह काम करता है। यह काफी संभव है। आप सब-पिक्सेल पोजिशनिंग, प्रिय Microsoft, उत्तर का उपयोग क्यों नहीं करते हैं! कोई जवाब नहीं है।





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



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

जिस तरह से FontFocus पिक्सेल संरेखण करता है

जेफ, अन्य बातों के अलावा, FontFocus [4] के लिए प्रलेखन को संदर्भित करता है । पूरे सम्मान के साथ, मुझे उससे असहमत होना है।





वे ऊर्ध्वाधर स्ट्रोक को अनदेखा करते हुए पिक्सेल स्ट्रोक को संरेखित करते हैं। आप देखते हैं, "T", "W", "C" और "g" अक्षर बहुत धुंधले हैं। इसके अलावा, "डब्ल्यू" बाकी की तुलना में भारी दिखता है।



मेरी राय में, यह बहुत मैला दिखता है। समझा जाता है कि यह टाइम्स न्यू रोमन है। लगता है?नहीं, एक आदिम बिटमैप फ़ॉन्ट की तरह। तो क्या बात है? क्या फ़ॉन्ट को एक बार फास्टर के रूप में सहेजना और इसे कम रिज़ॉल्यूशन पर उपयोग करना आसान नहीं है? यदि हम संकेतों के आकार को विकृत करने का जोखिम उठा सकते हैं, तो इसे सुचारू करने का क्या मतलब है? इसके अलावा, ऐसा लगता है कि पाठ में "स्पॉट" हैं, जैसे कि यह एक नरम नैपकिन पर स्याही में लिखा गया था: अधिकांश स्ट्रोक सही हैं, लेकिन कुछ स्थानों पर उन्हें स्मियर किया जाता है। किसी भी मामले में, समस्या समान है: या तो आप सही लेआउट से इनकार करते हैं, या आपको एक कर्लिंग वक्र मिलता है।



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



नीचे आप देखेंगे कि पाठ का एक सुखद और सही प्रदर्शन कैसे प्राप्त किया जा सकता है, और, सबसे दिलचस्प रूप से, बहुत सरल जोड़तोड़ के परिणामस्वरूप। मैंने Win32 API से FreeType लाइब्रेरी [10] और GetGlyphOutline () फ़ंक्शन का उपयोग किया। दूसरे शब्दों में, विंडोज और लिनक्स दोनों पर इस तरह की एक रेखांकन योजना संभव है, और निश्चित रूप से, मैक ओएस पर, जिसमें फ्रीटाइप भी ठीक संकलन करता है। इसके अलावा, मुझे पता चला है कि फ्री टाइप ऑटोहर्ट बहुत सही ढंग से काम करता है यदि आप इसे मेरे द्वारा किए गए तरीके से उपयोग करते हैं (सामान्य परिस्थितियों में, इसके काम का परिणाम स्वीकार्य नहीं कहा जा सकता है)। लेकिन सबसे पहले, मैं लिनक्स दुनिया की स्थिति के बारे में बात करूंगा।



जारी रखने के लिए ...