हमने कैनवास पर ग्रंथों को आकर्षित करना कैसे सीखा

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

फ्लैश के साथ चल रहा है

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

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

एक संपादक के रूप में, हमने एक खुली लाइब्रेरी का उपयोग किया, लेकिन एचटीएमएल से कैनवस तक के प्रतिपादन के लिए तैयार लाइब्रेरी ने हमें काम की गति और अपर्याप्त कार्यक्षमता के अनुरूप नहीं किया।

हमने कई समाधानों की जांच की:

• मानक कैनवास। HTML में टेक्स्ट आकर्षित करने में सक्षम, स्टाइल किया जा सकता है, सभी ब्राउज़रों में काम करता है। लेकिन यह पता नहीं है कि HTML संपादक बहु-पंक्ति पाठ जैसे लिंक को विभिन्न स्वरूपण के साथ कैसे आकर्षित किया जाए। इन कठिनाइयों को हल किया जा सकता है, लेकिन बहुत समय की आवश्यकता होती है;
• कैनवस के ऊपर DOM ड्रा करें। विकल्प हमें पसंद नहीं आया, क्योंकि हमारे उत्पाद में, प्रत्येक बनाई गई वस्तु का कैनवास पर अपना स्वयं का जेड-इंडेक्स है। और इसे DOM z- इंडेक्स के साथ मिलाने से काम नहीं चलेगा।
• Html को svg में बदलें। वह विदेशी ओब्जेक्ट तत्व की बदौलत html को इमेज में बदलने में सक्षम है। यह आपको svg के अंदर html को सेंकने और एक छवि के रूप में इसके साथ काम करने की अनुमति देता है। हमने इस विकल्प को चुना है।

एसवीजी विदेशी सुविधाएँ

SVG ForeignObject कैसे काम करता है: हमारे पास एडिटर से HTML है → HTML को विदेशी में डालें → कुछ मैजिक → इमेज प्राप्त करें → इमेज को कैनवस में जोड़ें



जादू के बारे में। इस तथ्य के बावजूद कि अधिकांश ब्राउज़र विदेशी ऑबजेक्ट टैग का समर्थन करते हैं, प्रत्येक के पास कैनवास के साथ परिणाम का उपयोग करने के लिए अपनी विशेषताएं हैं। फ़ायर्फ़ॉक्स एक ब्लॉब ऑब्जेक्ट के साथ काम करता है, एज में आपको छवि के लिए बेस 64 करने और डेटा-यूआरएल वापस करने की आवश्यकता होती है, और IE11 में टैग बिल्कुल काम नहीं करता है।

getImageUrl(svg: string, browser: string): string { let dataUrl = '' switch (browser) { case browsers.FIREFOX: let domUrl = window.URL || window.webkitURL || window let blob = new Blob([svg], {type: 'image/svg+xml;charset=utf-8'}) dataUrl = domUrl.createObjectURL(blob) break case browsers.EDGE: let encodedSvg = encodeURIComponent(svg) dataUrl = 'data:image/svg+xml;base64,' + btoa(window.unescape(encodedSvg)) break default: dataUrl = 'data:image/svg+xml,' + encodeURIComponent(svg) return dataUrl } 

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



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

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

• फ़ॉन्ट-कर्लिंग: ऑटो; फ़ॉन्ट के कर्नेल को नियंत्रित करता है। अधिक जानकारी
• वेबकिट-फ़ॉन्ट-चौरसाई: एंटीलियास; चौरसाई के लिए जिम्मेदार है। अधिक जानकारी ।

एसवीजी <फॉरेन ऑबजेक्ट> के लिए हमें अंत में क्या मिला:

• हम किसी भी HTML को आकर्षित कर सकते हैं: टेक्स्ट, टेबल, ग्राफिक्स
• टैग एक वेक्टर छवि देता है।
• टैग IE11 को छोड़कर सभी आधुनिक ब्राउज़रों में काम करता है

हमने विदेशी विदेशी को क्यों छोड़ दिया

सब कुछ अच्छी तरह से काम किया, लेकिन एक बार डिजाइनर हमारे पास आए और मॉकअप बनाने के लिए फ़ॉन्ट समर्थन जोड़ने के लिए कहा।



हमें आश्चर्य होता है कि क्या हम विदेशी के साथ ऐसा कर सकते हैं। यह पता चला कि उसके पास एक विशेषता है, जो इस समस्या को हल करते समय, एक घातक दोष बन जाता है। यह स्वयं के अंदर HTML प्रदर्शित कर सकता है, लेकिन बाहरी संसाधनों तक नहीं पहुंच सकता है, इसलिए इसके साथ काम करने वाले सभी संसाधनों को base64 में परिवर्तित किया जाना चाहिए और svg के अंदर जोड़ा जाना चाहिए।



इसका मतलब यह है कि यदि आपके पास OpenSans द्वारा लिखे गए चार पाठ हैं, तो आपको इस फ़ॉन्ट को चार बार उपयोगकर्ता को डाउनलोड करना होगा। यह विकल्प हमें पसंद नहीं आया।

हमने फैसला किया कि हम अपने कैनवस पाठ के साथ लिखेंगे ... अच्छा प्रदर्शन, वेक्टर छवियों के लिए समर्थन, हम IE 11 के बारे में नहीं भूलेंगे

क्यों एक वेक्टर छवि हमारे लिए महत्वपूर्ण है? हमारे उत्पाद में, बोर्ड पर किसी भी वस्तु को ज़ूम किया जा सकता है, और वेक्टर छवि के साथ हम इसे केवल एक बार बना सकते हैं और ज़ूम की परवाह किए बिना इसका पुन: उपयोग कर सकते हैं। Canvas.fillText एक बिटमैप बनाता है: इस मामले में, हमें प्रत्येक ज़ूम के साथ छवि को फिर से बनाना होगा, जैसा कि हमने सोचा था, प्रदर्शन को बहुत प्रभावित करता है।

एक प्रोटोटाइप बनाएं

सबसे पहले, हमने इसके प्रदर्शन का परीक्षण करने के लिए एक सरल प्रोटोटाइप बनाया।



प्रोटोटाइप के संचालन का सिद्धांत:

• हम फ़ंक्शन "टेक्स्ट" को देते हैं;
• इससे हमें एक वस्तु मिलती है जिसमें पाठ से प्रत्येक शब्द है, प्रतिपादन के लिए निर्देशांक और शैलियों के साथ;
• कैनवस को वस्तु दें;
• कैनवस पाठ खींचता है।

प्रोटोटाइप में कई कार्य थे: यह सत्यापित करने के लिए कि स्केलिंग के साथ कैनवस रिडरिंग बिना देरी के होगा और यह कि html को ऑब्जेक्ट में बदलने का समय svg इमेज बनाने से अधिक नहीं होगा।

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


हमने कोड को ऑप्टिमाइज़ करने के लिए सबसे विश्वसनीय तरीके का उपयोग करने का निर्णय लिया - "परीक्षण को हमारी ज़रूरत के साथ बदलें";; लेकिन गंभीरता से, हम विश्लेषकों के पास गए और पूछा कि हमारे उपयोगकर्ताओं द्वारा ग्रंथों को कितनी बार बनाया जाता है। यह पता चला कि औसत पाठ का आकार 14 वर्ण है। इस तरह के छोटे पाठों के लिए, हमारे प्रोटोटाइप ने बेहतर प्रदर्शन के परिणाम दिखाए, जैसा कि पाठ की मात्रा पर गति की निर्भरता रैखिक है, और svg में लपेटना लगभग हमेशा एक ही समय में किया जाता है, पाठ की लंबाई की परवाह किए बिना। यह हमारे अनुकूल है: हम लंबे ग्रंथों पर प्रदर्शन में खो सकते हैं, लेकिन ज्यादातर मामलों में हमारी गति svg से बेहतर होगी।


कैनवास टेक्स्ट अपडेट पर काम करने के कई पुनरावृत्तियों के बाद, हमें निम्नलिखित एल्गोरिथ्म मिला:

चरण 1. हम तार्किक ब्लॉकों में तोड़ते हैं

1. हम ब्लॉक में पाठ को तोड़ते हैं: पैराग्राफ, सूचियां;
2. हम शैलियों के अनुसार ब्लॉक को छोटे ब्लॉकों में तोड़ते हैं;
3. हम ब्लॉक को शब्दों में तोड़ते हैं।

चरण 2. हम निर्देशांक और शैलियों के साथ एक वस्तु में एकत्र करते हैं

1. पीएक्स में प्रत्येक शब्द की चौड़ाई और ऊंचाई की गणना करें;
2. हम विभाजित शब्दों को जोड़ते हैं, क्योंकि बिंदु 2 में कुछ शब्द कई में विभाजित थे;
3. शब्दों से हम लाइनें इकट्ठा करते हैं, अगर शब्द लाइन में फिट नहीं होता है, तो हम तब तक काटते हैं जब तक यह फिट नहीं हो जाता;
4. हम पैराग्राफ और सूची एकत्र करते हैं;
5. हम प्रत्येक शब्द के लिए x, y की गणना करते हैं;
6. हमें रेंडरिंग के लिए तैयार वस्तु मिलती है।

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

नतीजतन, हमने फोंट और IE 11 के लिए समर्थन बनाया, यूनिट परीक्षणों के साथ सब कुछ कवर किया, और ज्यादातर मामलों में रेंडरिंग की गति फॉरेनऑबजेक्ट की तुलना में अधिक हो गई। बीटा उपयोगकर्ताओं में जाँच की और जारी किया। लगता है सफलता!

सफलता 30 मिनट तक चली

अब तक, दाएं हाथ के लेखन प्रणाली वाले लोगों ने तकनीकी सहायता नहीं लिखी है। यह पता चला कि हम ऐसी भाषाओं के अस्तित्व के बारे में भूल गए:



सौभाग्य से, दाएं हाथ की लेखन प्रणाली के लिए समर्थन जोड़ना मुश्किल नहीं था, क्योंकि मानक Canvas.fillText पहले से ही इसका समर्थन करता है।

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



एकमात्र उपाय जो हम जानते थे कि ब्राउज़रों के लिए W3C विनिर्देश में जाना था और कैनवस पाठ के अंदर इसे दोहराने की कोशिश करना था। यह मुश्किल और दर्दनाक था, लेकिन हम बुनियादी समर्थन को जोड़ने में सक्षम थे। द्विदिश पर अधिक: एक और दो ।

संक्षिप्त निष्कर्ष हम खुद के लिए बनाया है

1. किसी चित्र में HTML प्रदर्शित करने के लिए, SVG ForeignObject का उपयोग करें;
2. निर्णय लेने के लिए हमेशा अपने उत्पाद का विश्लेषण करें;
3. प्रोटोटाइप बनाएं। वे दिखा सकते हैं कि जटिल निर्णय केवल पहली नज़र में ही लग सकते हैं;
4. कोड को तुरंत लिखें ताकि इसे परीक्षणों के साथ कवर किया जा सके;
5. एक अंतरराष्ट्रीय उत्पाद में, यह भूलना महत्वपूर्ण नहीं है कि कई अलग-अलग भाषाएं हैं, जिनमें द्विभाषी शामिल हैं।

यदि आपके पास ऐसी समस्याओं को हल करने का अनुभव है - तो इसे टिप्पणियों में साझा करें।