SVG को PNG में बदलते समय असल में क्या होता है

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

हर कन्वर्टर इन तीनों का जवाब देता है। ज़्यादातर यह नहीं बताते कि कैसे। मौजूदा Chrome, Firefox और Safari में मापकर देखा गया, असल में यह होता है।

पहला सवाल: SVG कितनी बड़ी है?#

किसी ब्राउज़र से SVG का आकार पूछिए, वह पूरे भरोसे से एक ग़लत संख्या बताएगा।

हमने इसे Chromium 149, Firefox 151 और WebKit 26.5 पर तीन फ़ाइलों के साथ जाँचा:

तीनों इंजन सहमत हैं, और समस्या दूसरी तथा तीसरी पंक्ति है। 300 x 150 उन तत्वों के लिए CSS का पुराना डिफ़ॉल्ट है जिनका अपना कोई आकार नहीं होता - वही डिफ़ॉल्ट जो एक ग़ायब <img> को मिलता है। जब viewBox मौजूद हो, ब्राउज़र वही 300 पिक्सेल चौड़ाई रखता है और ऊँचाई अनुपात से निकाल लेता है।

तो जिस आइकन को उसकी डिज़ाइनर ने 200 x 50 पर बनाया था, वह 300 x 75 की PNG बनकर निकलता है, और कहीं यह नहीं लिखा होता कि आपकी कलाकृति के असली आकार की जगह एक डिफ़ॉल्ट रख दिया गया।

वह नियम जो सचमुच काम करता है#

DOM नहीं, फ़ाइल पढ़िए:

1. अगर width और height दोनों निरपेक्ष इकाइयों में हों - बिना इकाई, px, pt, mm, in - तो असली आकार वही है। 96 dpi पर बदलिए, यानी 1in 96 पिक्सेल।
2. वरना, अगर viewBox है तो उसकी चौड़ाई-ऊँचाई लीजिए। यह बनाने वाले का अपना निर्देशांक तंत्र है। और यही सबसे अहम स्थिति है, क्योंकि viewBox के साथ width="100%" height="100%" ही Illustrator और Figma का डिफ़ॉल्ट आउटपुट है।
3. वरना फ़ाइल में सचमुच कोई आकार नहीं है। कुछ न कुछ चुनना ही पड़ता है, और ईमानदारी यह है कि चुपचाप 300 x 150 गढ़ने के बजाय यह बता दिया जाए।

हमारा SVG से PNG कन्वर्टर आपकी छोड़ी हुई हर फ़ाइल के लिए बताता है कि इन तीनों में से क्या हुआ, और तीसरी स्थिति में ब्राउज़र के ग़ैर-वर्गाकार डिफ़ॉल्ट के बजाय 512 x 512 पर लौटता है।

दूसरा सवाल: मेरे फ़ॉन्ट का क्या हुआ?#

SVG में लिखा हुआ, लिखे हुए की तस्वीर नहीं होता। वह एक अक्षर-श्रृंखला है, साथ में उस फ़ॉन्ट का नाम जो कहीं और मौजूद होना चाहिए। font-family="Brandon Grotesque" कहने वाली SVG में Brandon Grotesque का कुछ भी नहीं होता।

आपको लग सकता है कि SVG के भीतर @font-face नियम इसे सुलझा देगा। नहीं सुलझाता। हमने दूरस्थ वेबफ़ॉन्ट वाली एक SVG को तीनों ब्राउज़र में नेटवर्क देखते हुए जाँचा: हर इंजन में फ़ॉन्ट के लिए शून्य अनुरोध। लिखावट फिर भी बनी - एक विकल्प फ़ॉन्ट में, अलग चौड़ाई के साथ।

"बदलने के बाद मेरा टेक्स्ट ग़लत क्यों दिखता है" के पीछे की पूरी क्रियाविधि यही है। सिर्फ़ दो तरह की लिखावट ज्यों की त्यों बचती है:

• वे फ़ॉन्ट जो बदलने वाली मशीन पर इंस्टॉल हों। यानी आपकी PNG आपके लैपटॉप पर और सहकर्मी के लैपटॉप पर अलग निकल सकती है।
• वह लिखावट जो पहले ही आउटलाइन में बदल दी गई हो। Illustrator में यह Type > Create Outlines है, Figma में Flatten। जब हर अक्षर एक पथ बन जाए, तो कोई फ़ॉन्ट ग़ायब हो ही नहीं सकता।

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

तीसरा सवाल: चलने की अनुमति किसे है?#

SVG उस अर्थ में छवि प्रारूप नहीं है जिस अर्थ में PNG है। वह एक XML दस्तावेज़ है, और XML दस्तावेज़ों में स्क्रिप्ट हो सकती है। एक SVG <script> टैग, onload हैंडलर, दूरस्थ छवियों के संदर्भ और बाहरी स्टाइलशीट खींचने वाले @import नियम ले जा सकती है।

इसीलिए कुछ कंटेंट मैनेजमेंट सिस्टम SVG अपलोड सिरे से मना कर देते हैं।

अच्छी ख़बर, जो हमने भी मापी: SVG को पेज में इंजेक्ट करने के बजाय <img> टैग से बनाना एक असली सैंडबॉक्स है। एक ऐसी फ़ाइल के साथ जिसमें भीतर <script>, दूरस्थ <image href>, एक xlink:href, एक @import और दूरस्थ @font-face था, तीनों ब्राउज़र ने कोई स्क्रिप्ट नहीं चलाई और एक भी नेटवर्क अनुरोध नहीं किया - पेज के भीतर से और बाहर से, दोनों तरह पुष्ट।

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

अब भी जो एक चीज़ बनती है वह है data: URI - एक छवि जो सीधे SVG के भीतर टेक्स्ट के रूप में जड़ी हो। यह जान-बूझकर है: वह आत्मनिर्भर है, लाने को कुछ है ही नहीं।

यह असल में कहाँ चुभता है#

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

इनमें से कुछ भी जो नहीं बदलता#

दो चीज़ें रूपांतरण से बिल्कुल सही-सलामत निकलती हैं, और यह जानना अच्छा है ताकि आप ऐसी समस्याएँ न ढूँढें जो हैं ही नहीं।

पारदर्शिता। PNG पूरा अल्फ़ा चैनल रखता है, इसलिए जहाँ आपकी SVG कुछ नहीं रंगती वह सचमुच पारदर्शी रहता है, और आधी-पारदर्शी भराई अपनी आंशिक अपारदर्शिता बनाए रखती है। तीनों इंजनों में पिक्सेल-दर-पिक्सेल जाँचा गया।

आप जो भी आकार माँगें, उसमें तीक्ष्णता। वेक्टर से शुरू करने का असली फ़ायदा यही है। 2x निर्यात दोगुनी की गई छवि नहीं है - चित्र ज्यामिति से बड़े आकार पर नए सिरे से बनाया जाता है, इसलिए वक्र गणितीय रूप से तीखे रहते हैं। इसीलिए 2x पर निर्यात करना बाद में PNG बड़ी करने से बेहतर है, और इसीलिए वेक्टर से बना 16 पिक्सेल का आइकन 512 पिक्सेल से घटाए गए आइकन से बेहतर है।

यह आख़िरी बात मापी जा सकती है। ग्रिड से मेल खाते किनारों वाले एक चिह्न पर, सीधे 16 x 16 में बनाने से 141 ठोस पिक्सेल मिले और एक भी आधा-पारदर्शी नहीं; वही कलाकृति 512 पिक्सेल के चित्र से घटाने पर 98 ठोस और 64 धुँधले पिक्सेल दिए। चालीस प्रतिशत स्याही लुगदी बन गई - इसीलिए हमारा फ़ेविकॉन जेनरेटर एक बड़े को घटाने के बजाय हर आकार अलग से बनाता है।

संक्षेप में#

• आकार: width/height पढ़िए, न मिले तो viewBox पर लौटिए, और ब्राउज़र जो बताए उस पर कभी भरोसा मत कीजिए।
• फ़ॉन्ट: वे साथ नहीं चलते। लिखावट मायने रखती हो तो निर्यात से पहले आउटलाइन कर दीजिए।
• स्क्रिप्ट: रूपांतरण के दौरान वे चल नहीं सकतीं, पर SVG स्रोत को पेज में चिपकाते ही चल सकती हैं।
• पारदर्शिता और तीक्ष्णता: दोनों बचती हैं। बाद में आकार बदलने के बजाय जिस आकार की ज़रूरत हो उसी में निर्यात कीजिए।