एक ही 葛 अक्षर PC या मुद्रित फ़ॉर्म के अनुसार अलग क्यों दिखता है?

यह मोजीबाके से अधिक फ़ॉन्ट ग्लिफ़ का अंतर है। JIS X 0213:2004 (JIS2004) ने 168 कांजी के उदाहरण ग्लिफ़ मुद्रण-मानक रूपों में संशोधित किए, और Windows ने भी Vista से MS Gothic / MS Mincho आदि में JIS2004 ग्लिफ़ डिफ़ॉल्ट किए। 葛, 辻, 飴 जैसे प्रतिनिधि उदाहरण हैं: Unicode कोड पॉइंट (डेटा) वही रहता है, और केवल फ़ॉन्ट का ग्लिफ़ (दिखावट) बदला है। डेटा तुलना मेल खाती है; XP-युग फ़ॉर्म छवि और नए PC की स्क्रीन के आकार का बेमेल निर्दिष्ट व्यवहार है। यदि ग्लिफ़ भी संरेखित चाहें, स्क्रीन और फ़ॉर्म पर एक ही फ़ॉन्ट उपयोग करें, या वैचारिक विविधता चयनकर्ता से ग्लिफ़ निर्दिष्ट करें।

यदि वैचारिक विविधता चयनकर्ता (IVS) उपयोग करें, क्या हर व्यक्तिगत-नाम ग्लिफ़ समस्या हल होती है?

नहीं। IVS वह तंत्र है जो आधार वर्ण के तुरंत बाद U+E0100 से चयनकर्ता रखकर ग्लिफ़ डेटा के रूप में निर्दिष्ट करता है, और निर्दिष्ट ग्लिफ़ तभी दिखता है जब IPAmj Mincho जैसा समर्थक फ़ॉन्ट और समर्थक ऐप दोनों हों। असमर्थित वातावरण में निर्दिष्ट व्यवहार यह है कि चयनकर्ता अनदेखा हो और आधार वर्ण का डिफ़ॉल्ट ग्लिफ़ दिखे; कुछ वातावरण में चयनकर्ता □ भी दिख सकता है। आगे, एक IVS-युक्त वर्ण UTF-16 में चार कोड इकाइयों तक हो सकता है, जो वर्ण-गणना, स्लाइसिंग और DB कॉलम लंबाई के डिज़ाइन को प्रभावित करता है। यदि लाएँ, प्रदर्शन, मुद्रण और डाउनस्ट्रीम प्रणालियों से समर्थन का दायरा पुष्टि कर उपयोग करें।

गाइजी (EUDC) के रूप में पंजीकृत वर्ण दूसरे PC या PDF में दिख सकता है?

सिद्धांततः नहीं। गाइजी वह तंत्र है जिसमें उपयोगकर्ता उस PC की eudc.tte फ़ाइल में Unicode निजी-उपयोग क्षेत्र (U+E000 से) के कोड पॉइंट पर ग्लिफ़ पंजीकृत करता है; वही कोड पॉइंट दूसरे PC पर अपरिभाषित या भिन्न ग्लिफ़ है। मेल, PDF या दूसरी प्रणाली को सौंपने का भाग्य इसलिए □ होना या भिन्न वर्ण दिखना है। यदि गाइजी-युक्त विरासत डेटा पहले से है, माइग्रेशन पर यथार्थ पथ निजी-उपयोग क्षेत्र के उपयोगों की सूची बनाना, नियमित Unicode वर्णों या वैचारिक विविधता चयनकर्ताओं से पत्राचार तालिका बनाना, और प्रतिस्थापित करना है। नई प्रणाली में नया गाइजी बनाना टालें।

व्यावसायिक प्रणाली व्यक्तिगत नामों में वर्ण कितना स्वीकार करे?

पहली बात "स्वीकृत वर्ण सेट तय कर विनिर्देश के रूप में कहना" है। परिवार रजिस्टरों में लगभग 56,000 कोसेकी एकीकृत वर्ण हैं, और सरकार-मानक अनुरूप प्रणालियाँ प्रशासनिक मामलों के मानक वर्णों की ओर बढ़ रही हैं — चरित्र सूचना प्लेटफ़ॉर्म का विस्तार — पर सामान्य व्यावसायिक प्रणाली उसी स्तर को बिना सीमा स्वीकार करने को बाध्य नहीं। यथार्थ डिज़ाइन है "JIS X 0213 के दायरे तक" या "वैचारिक विविधता चयनकर्ता या निजी-उपयोग क्षेत्र स्वीकार न करें" जैसी सीमा तय करना, इनपुट पर मान्य करना, और दायरे-बाहर मामलों को चेतावनी या वैकल्पिक निरूपण से चलाना। केवल वे प्रणालियाँ जो सरकार या नगरपालिकाओं से अंतर-संचालन करती हैं प्रशासनिक मामलों के मानक वर्णों और JIS X 0221-आधारित अंतर-संचालन आवश्यकताओं का अनुसरण करें।

फ़ॉर्म या PDF स्क्रीन जैसे ही वर्ण कैसे दिखाए?

आधार रेखा स्क्रीन और फ़ॉर्म पर एक ही फ़ॉन्ट निर्दिष्ट करना, और PDF में फ़ॉन्ट एम्बेड करना है। यदि फ़ॉन्ट भिन्न हों, वही डेटा ग्लिफ़ बदल सकता है; यदि देखने वाले PC के पास फ़ॉन्ट न हो, स्थानापन्न फ़ॉन्ट से चित्रण होता है और दिखावट टूटती है। एम्बेडिंग की अनुमति फ़ॉन्ट के लाइसेंस (OpenType fsType) से तय होती है, इसलिए पुष्टि करें — रिपोर्ट लाइब्रेरी पर न छोड़ें। सबसेट एम्बेडिंग, जो केवल प्रयुक्त वर्ण एम्बेड करती है, फ़ाइल आकार भी घटाती है। यदि दीर्घकालिक प्रतिधारण आवश्यकता हो, PDF/A पर विचार करें, जो फ़ॉन्ट एम्बेडिंग माँगता है।

जापानी फ़ॉन्ट और वर्ण के जाल — व्यावसायिक ऐप में JIS2004, IVS और गाइजी सँभालना

20 Aug 2026 00:40 · Go Komura · जापानी फ़ॉन्ट, JIS2004, विविधता वर्ण, गाइजी, वर्ण एन्कोडिंग, Unicode, व्यावसायिक अनुप्रयोग, रिपोर्ट, Windows

“ग्राहक सूची का 葛 अक्षर स्क्रीन और मुद्रित फ़ॉर्म पर अलग दिखता है। ग्राहक ने शिकायत की कि डेटा भ्रष्ट होना चाहिए।” — व्यावसायिक-प्रणाली रखरखाव में इस तरह का परामर्श दुर्लभ नहीं। दूसरा आम है “व्यक्ति के नाम का अक्षर सरकारी कार्यालय को सौंपे दस्तावेज़ पर प्रदर्शित नहीं होता। पुराने PC पर दिखता था; बदलने के बाद □ हो गया।”

दोनों मैदान में “मोजीबाके” कहलाते हैं, पर एन्कोडिंग बेमेल से आने वाले मोजीबाके से भिन्न समस्या हैं। पहले में डेटा का एक बिट भी नहीं बदला और केवल दिखावट बदली; दूसरे में वह “गाइजी” खो गया जो केवल उस PC पर मौजूद था।

flowchart TB
    accTitle: दो आम परामर्श वास्तव में क्या हैं
    accDescr: परामर्श कि 葛 स्क्रीन और फ़ॉर्म पर अलग दिखता है वह मामला है जहाँ डेटा वही रहा और केवल दिखावट बदली; परामर्श कि PC बदलने के बाद □ हो गया वह मामला है जहाँ केवल उस PC पर मौजूद गाइजी खो गया; दोनों एन्कोडिंग-बेमेल मोजीबाके से भिन्न समस्या हैं
    c1["परामर्श 1: आकार स्क्रीन और फ़ॉर्म पर भिन्न"] --> r1["डेटा अपरिवर्तित; केवल दिखावट बदली"]
    c2["परामर्श 2: बदलने के बाद □ हो गया"] --> r2["केवल उस PC पर मौजूद गाइजी खो गया"]
    r1 --> diff["एन्कोडिंग मोजीबाके से भिन्न समस्या"]
    r2 --> diff

चित्र 1: “मोजीबाके” कहलाने वाले दोनों परामर्श एन्कोडिंग बेमेल से भिन्न समस्या हैं।

इस लेख का वादा सरल है। यदि वर्ण-कोड (डेटा) परत को फ़ॉन्ट (दिखावट) परत से अलग करें, अधिकांश जापानी वर्ण-समस्या सुलझ जाती है। JIS2004 ग्लिफ़ परिवर्तन, वैचारिक विविधता चयनकर्ता (IVS), और गाइजी (EUDC) से, सरकार के वर्ण प्लेटफ़ॉर्म से होते, फ़ॉन्ट चुनने और एम्बेड करने तक, व्यावसायिक प्रणालियों के डेवलपरों और IT स्टाफ के निर्णय के लिए व्यवस्थित है।

Shift_JIS ↔ UTF-8 रूपांतरण में होने वाला “मोजीबाके” स्वयं मौजूदा लेखों में कवर है, इसलिए यह लेख “कोड राउंड-ट्रिप सही हैं, पर दिखावट या प्रदर्शनीयता ग़लत है” की समस्या पर केंद्रित है।

1. निष्कर्ष पहले

“मोजीबाके” और “ग्लिफ़ भिन्न है” भिन्न समस्याएँ हैं। मोजीबाके बाइट अनुक्रम की ग़लत व्याख्या की डेटा-परत दुर्घटना है; ग्लिफ़ अंतर फ़ॉन्ट के ग्लिफ़ के अंतर की दिखावट-परत दुर्घटना है; उपचार पूरी तरह भिन्न हैं।
एक ही Unicode कोड पॉइंट पर भी प्रदर्शित ग्लिफ़ फ़ॉन्ट पर निर्भर करता है। JIS X 0213:2004 ने 葛, 辻 और 飴 जैसे 168 वर्णों के उदाहरण ग्लिफ़ मुद्रण-मानक रूपों में संशोधित किए, और Windows ने भी Vista से MS Gothic / MS Mincho में JIS2004 ग्लिफ़ डिफ़ॉल्ट किए।¹²
ग्लिफ़ को डेटा के रूप में स्थिर करने का मानक साधन वैचारिक विविधता चयनकर्ता (IVS) है। आप आधार वर्ण प्लस U+E0100 से चयनकर्ता के अनुक्रम से ग्लिफ़ निर्दिष्ट करते हैं; Adobe-Japan1, Hanyo-Denshi, और Moji_Joho (चरित्र सूचना प्लेटफ़ॉर्म) जैसे संग्रह Unicode के IVD में पंजीकृत हैं।³⁴
असमर्थित वातावरण में IVS का निर्दिष्ट व्यवहार यह है कि चयनकर्ता अनदेखा हो और आधार वर्ण का डिफ़ॉल्ट ग्लिफ़ प्रदर्शित हो। पर एक IVS-युक्त वर्ण UTF-16 में चार कोड इकाइयों तक हो सकता है, इसलिए वर्ण-गणना और स्लाइसिंग के कार्यान्वयन सावधानी चाहते हैं।⁵
गाइजी (EUDC) का भाग्य “केवल उस PC पर दिख सकता है” है। निजी-उपयोग क्षेत्र कोड पॉइंट का सहमत अर्थ नहीं, और eudc.tte में पंजीकृत ग्लिफ़ दूसरे PC, मेल या PDF तक नहीं जाता।⁶⁷
व्यक्तिगत नाम सँभालने वाली प्रणाली स्वीकृत वर्ण सेट तय करे और कहे। सरकार पक्ष पर, कोसेकी एकीकृत वर्णों और चरित्र सूचना प्लेटफ़ॉर्म पर बनकर, मानक-अनुरूप प्रणालियाँ “प्रशासनिक मामलों के मानक वर्ण” उपयोग की ओर बढ़ रही हैं।⁸⁹¹⁰
फ़ॉर्म और PDF के लिए “फ़ॉन्ट को स्क्रीन से संरेखित करें, और एम्बेड करें” आधार रेखा है। एम्बेडिंग की अनुमति फ़ॉन्ट के लाइसेंस (fsType) से तय होती है, और दीर्घकालिक-प्रतिधारण PDF/A फ़ॉन्ट एम्बेडिंग माँगता है।¹¹¹²
व्यक्तिगत-नाम डेटा पर सामान्यीकरण (NFKC) लापरवाही से न लगाएँ। पूर्णचौड़ाई और अर्धचौड़ाई एक करना, और संगतता वर्ण बदलना, वे भेद खो देता है जो रखने चाहिए।¹³

एक वाक्य में: “कौन सा बाइट अनुक्रम संग्रहीत करें” डेटा-डिज़ाइन समस्या है; “कैसा दिखता है” फ़ॉन्ट-डिज़ाइन समस्या है। दोनों मिलाकर चर्चा करें तो हल करने योग्य समस्याएँ भी हल न हों।

2. डेटा और दिखावट को अलग सोचना — कोड पॉइंट और ग्लिफ़

Unicode में वर्ण एक संख्या से निरूपित होता है जिसे कोड पॉइंट कहते हैं। 葛 U+845B है, और यह संख्या हर PC पर एक है। वह संख्या स्क्रीन या काग़ज़ पर कैसे खींची जाए, दूसरी ओर, फ़ॉन्ट के ग्लिफ़ से तय होती है। एक ही U+845B का फ़ॉन्ट A और फ़ॉन्ट B के बीच आकार के विवरण में भिन्न होना सामान्य व्यवहार है।

इन दो परतों को आधार मानकर मैदानी लक्षण इस प्रकार बाँटे जा सकते हैं।

परत	होने वाली दुर्घटना	विशिष्ट लक्षण	मुख्य उपचार
डेटा परत (वर्ण एन्कोडिंग)	एन्कोडिंग की ग़लत व्याख्या, रूपांतरण में हानि	縺ｯ जैसा मोजीबाके, `?` या `〓` से प्रतिस्थापन, U+FFFD (�)	रूपांतरण पथ पहचानें और ठीक करें
दिखावट परत (फ़ॉन्ट)	फ़ॉन्ट अनुसार ग्लिफ़ अंतर, ग्लिफ़ अनुपस्थिति	वही डेटा पर भिन्न आकार; □ (टोफ़ू) हो जाना	फ़ॉन्ट एक करें या बदलें; एम्बेड करें

विभाजन के संकेत के रूप में “�” और “□” का अंतर याद रखना उपयोगी है। U+FFFD (REPLACEMENT CHARACTER) का “�” डेटा परत पर रूपांतरण विफलता का निशान है, और मूल वर्ण पहले ही खो चुका है। “□” दूसरी ओर कई मामलों में केवल यह है कि डेटा अभी है पर फ़ॉन्ट के पास ग्लिफ़ नहीं, और फ़ॉन्ट बदलने से प्रदर्शित हो सकता है।

flowchart TB
    accTitle: लक्षण को � बनाम □ से बाँटना
    accDescr: जब वर्ण सही प्रदर्शित न हो, � डेटा परत पर रूपांतरण विफलता का निशान है जिसमें मूल वर्ण खो चुका है; □ केवल यह है कि डेटा अभी है पर फ़ॉन्ट के पास ग्लिफ़ नहीं, और फ़ॉन्ट बदलने से प्रदर्शित हो सकता है
    symptom["वर्ण सही प्रदर्शित नहीं होता"] --> which{"क्या दिखता है?"}
    which -->|� दिखता है| datalayer["डेटा-परत दुर्घटना"]
    datalayer -.-> lost["रूपांतरण विफलता का निशान （मूल वर्ण खो गया）"]
    which -->|□ दिखता है| viewlayer["दिखावट-परत दुर्घटना"]
    viewlayer -.-> noglyph["केवल यह कि फ़ॉन्ट के पास ग्लिफ़ नहीं"]
    noglyph --> fixable["फ़ॉन्ट बदलने से प्रदर्शित हो सकता है"]

चित्र 2: � डेटा-परत दुर्घटना का संकेत है, □ दिखावट-परत दुर्घटना का, और जाँच का प्रवेश बिंदु बदलता है।

एन्कोडिंग की बुनियाद स्वयं (CP932 और UTF-8, BOM, न्यूलाइन कोड) “Windows पाठ एन्कोडिंग का परिचय - Linux से एकीकरण पर होने वाला मोजीबाके” और “Windows पाठ एन्कोडिंग और पंक्ति अंत - मोजीबाके और CRLF/LF की बुनियाद” में कवर है। यहाँ से दिखावट परत है, और उसकी सीमा पर होने वाली समस्याएँ।

3. JIS90 से JIS2004 — कोड वही रहा, ग्लिफ़ बदला

खुलते “葛 स्क्रीन और फ़ॉर्म पर अलग दिखता है” की पहचान कई मामलों में यहाँ है।

राष्ट्रीय भाषा परिषद की 2000 रिपोर्ट “Hyogai Kanji Jitaihyo” (जोयो सूची से बाहर कांजी के रूपों की तालिका) के अनुसार, 2004 संशोधन JIS X 0213:2004 (सामान्यतः JIS2004) ने 168 कांजी के उदाहरण ग्लिफ़ मुद्रण-मानक रूपों में संशोधित किए, तथाकथित कांग्शी शब्दकोश रूपों के निकट। 葛, 辻, 飴, 芦, 溢, 餅 जैसे प्रतिनिधि उदाहरण हैं।¹

Windows ने इसके साथ संरेखित कर Windows Vista से MS Gothic / MS Mincho (और नए Meiryo) में JIS2004 ग्लिफ़ डिफ़ॉल्ट किए। वर्तमान MS Gothic भी JIS2004-आधारित डिफ़ॉल्ट ग्लिफ़ रखता है, उस संरचना के साथ कि JIS90-युग ग्लिफ़ OpenType jp90 फ़ीचर से सुलभ हैं।²¹

flowchart TB
    accTitle: वर्तमान MS Gothic की ग्लिफ़ संरचना
    accDescr: Vista से MS Gothic के डिफ़ॉल्ट JIS2004 ग्लिफ़ हैं, और OpenType jp90 फ़ीचर से JIS90-युग ग्लिफ़ तक पहुँचना संरचना है
    msg["MS Gothic （Vista से）"] --> def["डिफ़ॉल्ट ग्लिफ़: JIS2004-आधारित"]
    msg --> feat["jp90 फ़ीचर से"]
    feat --> old["JIS90-युग ग्लिफ़"]

चित्र 3: वर्तमान MS Gothic के डिफ़ॉल्ट JIS2004 ग्लिफ़ हैं, और jp90 फ़ीचर से JIS90 ग्लिफ़ पर स्विच कर सकते हैं।

यहाँ मायने यह है कि केवल फ़ॉन्ट बदला; डेटा बिल्कुल नहीं बदला।

葛 का कोड पॉइंट XP और Windows 11 दोनों पर U+845B है
XP (JIS90 ग्लिफ़) पर वह रूप दिखता है जो आवरण रेडिकल के अंदर को ヒ सरल करता है; Vista से (JIS2004 ग्लिफ़) वह रूप दिखता है जो अंदर 人 भी लिखता है
इसलिए पुरानी प्रणाली पर मुद्रित फ़ॉर्म की स्कैन छवि और नए PC की स्क्रीन प्रदर्शन वर्ण के आकार में असहमत हैं। डेटा तुलना पूरी तरह मेल खाती है

辻 के शिन्न्यो रेडिकल में एक बिंदु है या दो, 飴 के “खाओ” रेडिकल का रूप, और जैसे वही हैं। यदि यह इतिहास न जानें, जाँच “माइग्रेशन में डेटा भ्रष्ट हुआ” की ग़लत दिशा जाती है। जब कहा जाए कि माइग्रेशन के पहले-बाद वर्ण की दिखावट भिन्न है, पहले कोड पॉइंट तुलना करें, और यदि मेल खाएँ, फ़ॉन्ट ग्लिफ़ अंतर संदेह करें — वही सही क्रम है।

flowchart TB
    accTitle: एक ही कोड पॉइंट, फ़ॉन्ट अनुसार भिन्न ग्लिफ़
    accDescr: 葛 का कोड पॉइंट U+845B XP और Windows 11 दोनों पर वही रहता है; केवल प्रदर्शित आकार JIS90-ग्लिफ़ फ़ॉन्ट और JIS2004-ग्लिफ़ फ़ॉन्ट के बीच बदलता है, और डेटा तुलना पूरी तरह मेल खाती है
    cp["कोड पॉइंट U+845B （葛）"] --> f90["JIS90-ग्लिफ़ फ़ॉन्ट （XP）"]
    cp --> f04["JIS2004-ग्लिफ़ फ़ॉन्ट （Vista से）"]
    f90 --> g90["वह रूप जो अंदर को ヒ सरल करता है"]
    f04 --> g04["मुद्रण-मानक रूप जो अंदर 人 लिखता है"]
    g90 -.-> same["डेटा तुलना पूरी तरह मेल खाती है"]
    g04 -.-> same

चित्र 4: केवल फ़ॉन्ट बदला; कोड पॉइंट U+845B हर वातावरण में वही रहता है।

ध्यान दें कि क्योंकि वर्ण स्वयं नहीं बदला, दोनों ग्लिफ़ “एक ही वर्ण” हैं। व्यक्तिगत नामों में, पर, व्यक्ति या सरकारी कार्यालय कभी विशेष रूप पर ज़ोर देते हैं, और उस माँग का “डेटा के रूप में” उत्तर अगला विषय है, IVS।

4. वैचारिक विविधता चयनकर्ता (IVS) — ग्लिफ़ को डेटा के रूप में निर्दिष्ट करना

IVS (Ideographic Variation Sequence) वह तंत्र है जो कांजी के तुरंत बाद “वैचारिक विविधता चयनकर्ता” नामक अदृश्य कोड पॉइंट रखकर ग्लिफ़ विविधता को डेटा के रूप में निर्दिष्ट करता है। प्रयुक्त चयनकर्ता U+E0100–U+E01EF (VS17–VS256) हैं।³

कौन सा “आधार वर्ण + चयनकर्ता” अनुक्रम किस ग्लिफ़ को संदर्भित करता है, IVD (Ideographic Variation Database) नामक रजिस्ट्री तय करती है, जिसे Unicode Consortium प्रबंधित करता है। मुख्य संग्रह निम्न हैं।⁴

संग्रह	पंजीकृत	उत्पत्ति और उपयोग
Adobe-Japan1	2007	Adobe का जापानी वर्ण संग्रह। वाणिज्यिक फ़ॉन्ट में विविधता ग्लिफ़ स्विच करने की नींव
Hanyo-Denshi	2010	हान्यो-देनशी सूचना विनिमय वातावरण विकास कार्यक्रम। परिवार-रजिस्टर और मूल निवासी रजिस्टर वर्ण जैसे सरकारी वर्णों से मेल
Moji_Joho	2014	चरित्र सूचना प्लेटफ़ॉर्म (MJ) से मेल। IPAmj Mincho के साथ उपयोग। अगस्त 2026 में अतिरिक्त पंजीकरण भी

Microsoft का दस्तावेज़ उदाहरण देता है कि अकेला U+845B (葛) निशी-कासाई स्टेशन के लेखन में उपयोग होता है, और U+845B+U+E0100 (VS17) नारा के कत्सुरागी नगर के लेखन में। एक ही 葛, पर कौन सा ग्लिफ़ है डेटा के रूप में अलग किया जा सकता है।³

flowchart TB
    accTitle: IVS से एक ही 葛 को डेटा के रूप में अलग करने का उदाहरण
    accDescr: अकेले U+845B के रूप में 葛 निशी-कासाई स्टेशन के लेखन में उपयोग होता है; U+845B के बाद VS17 का अनुक्रम कत्सुरागी नगर के लेखन में उपयोग होता है; कौन सा अनुक्रम किस ग्लिफ़ को संदर्भित करता है IVD रजिस्ट्री तय करती है
    seq1["अकेला U+845B"] --> gl1["निशी-कासाई स्टेशन के लेखन में प्रयुक्त ग्लिफ़"]
    seq2["U+845B + VS17"] --> gl2["कत्सुरागी नगर के लेखन में प्रयुक्त ग्लिफ़"]
    ivd["IVD （रजिस्ट्री）"] -.-> gl1
    ivd -.-> gl2

चित्र 5: एक ही 葛 पर भी, चयनकर्ता की उपस्थिति या अनुपस्थिति से आप डेटा के रूप में कौन सा ग्लिफ़ है अलग कर सकते हैं।

4.1. असमर्थित वातावरण में व्यवहार

फ़ॉन्ट पक्ष पर, IVS और ग्लिफ़ का पत्राचार OpenType cmap तालिका (फ़ॉर्मैट 14) में लागू होता है।⁵ जब समर्थक फ़ॉन्ट (IPAmj Mincho आदि) और समर्थक ऐप दोनों हों, निर्दिष्ट ग्लिफ़ आता है; जब न हों, निम्न होता है।

निर्दिष्ट सही व्यवहार: चयनकर्ता अनदेखा हो और आधार वर्ण का डिफ़ॉल्ट ग्लिफ़ प्रदर्शित हो (चयनकर्ता स्वयं अदृश्य)
पुराने ऐप और कुछ चित्रण स्टैक: चयनकर्ता स्वतंत्र अज्ञात वर्ण माना जाता है, और अतिरिक्त □ प्रदर्शित होता है

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

flowchart TB
    accTitle: IVS-युक्त डेटा कैसे प्रदर्शित होता है
    accDescr: जब समर्थक फ़ॉन्ट और समर्थक ऐप दोनों हों निर्दिष्ट ग्लिफ़ दिखता है; जब न हों, चयनकर्ता अनदेखा हो और आधार वर्ण का डिफ़ॉल्ट ग्लिफ़ दिखे; पुराने ऐप और कुछ चित्रण स्टैक में चयनकर्ता अज्ञात वर्ण माना जाता है और अतिरिक्त □ दिखता है
    ivs["आधार + IVS चयनकर्ता"] --> env{"समर्थक फ़ॉन्ट + ऐप?"}
    env -->|हाँ| ok["निर्दिष्ट ग्लिफ़"]
    env -->|नहीं| other{"कैसे खींचा जाता है?"}
    other -->|अनदेखा| ignore["डिफ़ॉल्ट ग्लिफ़"]
    other -->|पुराना / कुछ स्टैक| tofu["अतिरिक्त □"]
    ignore -.-> spec["निर्दिष्ट सही"]

चित्र 6: IVS बिगड़ने पर भी आधार वर्ण के रूप में पठनीय रहता है, पर निर्दिष्ट ग्लिफ़ आएगा या नहीं प्राप्तकर्ता के वातावरण पर निर्भर है।

4.2. कार्यान्वयन सावधानी — “एक वर्ण” चार कोड इकाइयों तक हो सकता है

U+E0100 से IVS चयनकर्ता पूरक समतल पर कोड पॉइंट हैं, इसलिए UTF-16 में हमेशा सरोगेट जोड़ी (दो कोड इकाइयाँ) हैं। यदि आधार वर्ण पूरक-समतल कांजी हो (उदाहरण 𠮟 (U+20B9F), JIS2004 में जोड़ा), आधार अकेला पहले से दो कोड इकाइयाँ है, और वह अनुक्रम जिसे उपयोगकर्ता “एक वर्ण” मानता है UTF-16 में चार कोड इकाइयों तक, और UTF-8 में आठ बाइट तक है।

C# का "葛󠄀" (葛+VS17) string.Length == 3 रखता है। Substring और निश्चित-लंबाई स्लाइसिंग आधार वर्ण को चयनकर्ता से अलग करने का जोखिम रखते हैं
वर्ण-गणना और स्लाइसिंग की मान्यता ग्रेफेम इकाइयों में हो (StringInfo जैसे API), कोड इकाइयों में नहीं
DB कॉलम लंबाई के लिए (SQL Server का nvarchar(n) UTF-16 कोड इकाइयों में है), यदि IVS स्वीकार करें, प्रत्यक्ष वर्ण-गणना का दो से चार गुना प्रावधान करें
खोज और तुलना में, चयनकर्ता की उपस्थिति या अनुपस्थिति भिन्न स्ट्रिंग बनाती है। “葛” की खोज “葛+VS17” पर लगे या नहीं, आवश्यकता के रूप में तय कर लागू करें

flowchart TB
    accTitle: एक IVS-युक्त वर्ण और UTF-16 कोड इकाइयाँ
    accDescr: आधार वर्ण और वैचारिक विविधता चयनकर्ता का अनुक्रम जिसे उपयोगकर्ता एक वर्ण मानता है चयनकर्ता के लिए हमेशा सरोगेट जोड़ी है, और यदि आधार वर्ण पूरक-समतल कांजी हो अन्य दो कोड इकाइयाँ, UTF-16 में अधिकतम चार कोड इकाइयाँ
    one["एक दृश्य वर्ण"] --> base["आधार वर्ण"]
    one --> vs["विविधता चयनकर्ता"]
    base -.-> bnote["पूरक हो तो +2"]
    vs -.-> vnote["हमेशा 2 कोड इकाइयाँ"]
    base --> total["4 UTF-16 इकाइयों तक"]
    vs --> total
    total -.-> risk["निश्चित स्लाइसिंग में टूटना"]

चित्र 7: एक IVS-युक्त वर्ण UTF-16 में चार कोड इकाइयों तक हो सकता है; कोड इकाई से स्लाइस करना खतरनाक है।

5. गाइजी (EUDC) — वर्ण जो केवल उस PC पर दिखते हैं

गाइजी वह तंत्र है जिसमें उपयोगकर्ता Unicode निजी-उपयोग क्षेत्र (PUA: U+E000–U+F8FF आदि) के कोड पॉइंट पर अपना ग्लिफ़ असाइन करता है। निजी-उपयोग क्षेत्र कोड पॉइंट का विश्वव्यापी सहमत अर्थ नहीं; एक ही U+E000 प्रति PC और प्रति संगठन भिन्न वर्ण असाइन हो सकता है।⁶

Windows पर आप ग्लिफ़ निजी वर्ण संपादक (eudcedit.exe) से बनाते हैं, और वह eudc.tte नामक फ़ॉन्ट फ़ाइल में सहेजा जाता है। यह फ़ाइल छिपे फ़ॉन्ट के रूप में स्थापित होती है और HKEY_CURRENT_USER\EUDC रजिस्ट्री में प्रत्येक फ़ॉन्ट से जुड़ती है।⁷ Shift_JIS (CP932) युग में गाइजी सीमा 0xF040–0xF9FC थी, और Unicode रूपांतरण पर निजी-उपयोग क्षेत्र में मैप होती है।

इस तंत्र का परिणाम स्पष्ट है।

eudc.tte उस PC (उस उपयोगकर्ता) का है और डेटा के साथ दूसरे पक्ष तक नहीं जाता
मेल, PDF, वेब या दूसरी प्रणाली को सौंपते ही □ हो जाता है या दूसरे पक्ष के भिन्न गाइजी जैसा दिखता है
OS माइग्रेशन या PC प्रतिस्थापन में eudc.tte माइग्रेट करना भूलें तो “पुराने PC पर दिखने वाला वर्ण नहीं दिखता” होता है

यह खुलते दूसरे परामर्श की पहचान है।

flowchart TB
    accTitle: गाइजी केवल उस PC पर क्यों दिखते हैं
    accDescr: निजी वर्ण संपादक में बना ग्लिफ़ eudc.tte में सहेजा जाता है और उस PC की रजिस्ट्री में फ़ॉन्ट से जुड़ता है, इसलिए यदि केवल निजी-उपयोग क्षेत्र कोड मेल, PDF या दूसरी प्रणाली को जाए तो □ हो जाता है या भिन्न वर्ण दिखता है
    edit["PUA ग्लिफ़ बनाएँ"] --> tte["eudc.tte में सहेजें"]
    edit -.-> editN["निजी वर्ण संपादक"]
    tte --> reg["रजिस्ट्री फ़ॉन्ट मैपिंग"]
    reg --> local["उस PC पर दिखता है"]
    tte -.-> stay["eudc.tte पीछे रह जाता है"]
    send["केवल PUA कोड जाता है"] --> dest["मेल / PDF / अन्य प्रणाली"]
    dest --> broken["□ या ग़लत वर्ण"]
    local ~~~ send

चित्र 8: ग्लिफ़ eudc.tte में रहता है; डेटा में केवल निजी-उपयोग क्षेत्र संख्या बचती है, इसलिए गाइजी PC छोड़ते ही टूटे दिखते हैं।

5.1. पहले से गाइजी पा चुकी प्रणाली का यथार्थ उत्तर

समस्या तब है जब विरासत प्रणाली से आए डेटा में पहले से गाइजी मिला हो। माइग्रेशन कार्यों पर हम जो प्रक्रिया सुझाते हैं वह निम्न है।

जाँचें: डेटाबेस और फ़ाइलों को निजी-उपयोग क्षेत्र (U+E000–U+F8FF) के नियमित व्यंजक से स्कैन करें, और उपयोग में गाइजी कोड व उनकी गिनती सूचीबद्ध करें। प्रत्येक साइट के PC से eudc.tte इकट्ठा कर ग्लिफ़ पुष्टि करें
पहचानें: प्रत्येक गाइजी के लिए जाँचें “नियमित Unicode वर्ण के रूप में निरूपित हो सकता है”, “IVS से निरूपित हो सकता है”, “चरित्र सूचना प्लेटफ़ॉर्म (MJ) में संगत वर्ण है”, और स्थानापन्न-वर्ण पत्राचार तालिका बनाएँ। व्यवहार में अधिकांश मामले केवल यह हैं कि पुराना रूप JIS गाइजी के रूप में बना था
प्रतिस्थापित करें: पत्राचार तालिका से डेटा प्रतिस्थापित करें। केवल जब सचमुच संगत वर्ण न हो, छवि के रूप में रखें या उस रिकॉर्ड से नोट जोड़ें
काटें: नई प्रणाली में मान्यता में निजी-उपयोग क्षेत्र इनपुट अस्वीकार करें, और नया गाइजी न बनाएँ

flowchart TB
    accTitle: गाइजी-युक्त डेटा माइग्रेट करने की प्रक्रिया
    accDescr: निजी-उपयोग क्षेत्र स्कैन कर और eudc.tte इकट्ठा कर उपयोग में गाइजी सूचीबद्ध करें, स्थानापन्न-वर्ण पत्राचार तालिका बनाएँ और प्रतिस्थापित करें, और नई प्रणाली में मान्यता में निजी-उपयोग क्षेत्र इनपुट अस्वीकार करें और नया गाइजी न बनाएँ
    st1["जाँचें: PUA स्कैन"] --> st2["पहचानें: स्थानापन्न तालिका"]
    st2 --> st3["तालिका से प्रतिस्थापित करें"]
    st3 --> st4["काटें: कोई नया गाइजी नहीं"]
    st1 -.-> tte["eudc.tte इकट्ठा करें"]
    st2 -.-> nomap["कोई मैप नहीं: छवि या नोट"]

चित्र 9: गाइजी को जाँचें, पहचानें, प्रतिस्थापित करें और काटें के चार चरणों में माइग्रेट करें, और नया गाइजी न बनाएँ।

सरकार पक्ष पर दिशा वही है: नगरपालिकाओं के स्वयं बनाए गाइजी (राष्ट्रव्यापी लगभग दो मिलियन वर्ण कहे जाते हैं) को आगे वर्णित प्रशासनिक मामलों के मानक वर्णों के विरुद्ध अद्वितीय पहचानने, और उपयोग रोकने की नीति कही गई है।¹⁰ “गाइजी न बढ़ाएँ; उन्हें मानकीकृत वर्ण सेट के विरुद्ध पहचानें” सार्वजनिक और निजी दोनों क्षेत्रों में स्थापित माइग्रेशन पैटर्न बन रहा है।

6. सरकारी वर्ण प्लेटफ़ॉर्म — कोसेकी एकीकृत वर्णों से प्रशासनिक मामलों के मानक वर्णों तक

व्यक्तिगत नाम सँभालने वाली प्रणाली के डिज़ाइन में, सरकार-पक्ष वर्ण प्लेटफ़ॉर्म जानना “कितना स्वीकार करें” तय करने की सामग्री बनता है।

नाम	संरक्षक	रूपरेखा
कोसेकी एकीकृत वर्ण	न्याय मंत्रालय	परिवार रजिस्टरों के कम्प्यूटरीकरण के लिए व्यवस्थित लगभग 56,000 वर्ण। न्याय मंत्रालय साइट पर खोज योग्य⁸
जुकी-नेट एकीकृत वर्ण	J-LIS (जापान स्थानीय प्राधिकरण सूचना प्रणाली एजेंसी)	मूल निवासी रजिस्टर नेटवर्क पर प्रयुक्त लगभग 21,000 वर्ण
चरित्र सूचना प्लेटफ़ॉर्म (MJ)	चरित्र सूचना प्रौद्योगिकी संवर्धन परिषद	प्रशासनिक कार्य में प्रयुक्त लगभग 60,000 वर्ण, व्यवस्थित। MJ वर्ण-ग्लिफ़ नामों से प्रबंधित; IPAmj Mincho फ़ॉन्ट और MJ वर्ण-सूचना सूची प्रकाशित। IPA परियोजना के रूप में व्यवस्थित और अब परिषद को हस्तांतरित⁹
प्रशासनिक मामलों के मानक वर्ण (MJ+)	डिजिटल एजेंसी	वर्ण सेट जो चरित्र सूचना प्लेटफ़ॉर्म को उन परिवार-रजिस्टर वर्णों आदि से विस्तारित करता है जो MJ के विरुद्ध पहचाने नहीं जा सकते। मानक-अनुरूप प्रणालियों में व्यक्तिगत नाम आदि यह वर्ण सेट उपयोग करते हैं; वर्ण एन्कोडिंग JIS X 0221:2020 है¹⁰

नगरपालिका मुख्य-व्यवसाय प्रणालियों (मानक-अनुरूप प्रणालियों) में दो-स्तरीय संरचना मानक विनिर्देश में है: व्यक्तिगत नाम आदि के सूचना अंतर-संचालन के लिए प्रशासनिक मामलों के मानक वर्ण उपयोग करें, और बिना एकीकृत अंतर-संचालन नियमों वाली बाहरी प्रणालियों — स्मार्टफ़ोन आदि — से JIS X 0213:2012 के दायरे में अंतर-संचालन करें।¹⁰ “अंदर चौड़ा वर्ण सेट रखें, और बाहर उस सीमा में आदान-प्रदान करें जो सामान्य वातावरण प्रदर्शित कर सके” की संरचना स्वयं निजी-क्षेत्र प्रणालियों के लिए भी संदर्भ है।

flowchart TB
    accTitle: मानक-अनुरूप प्रणाली का दो-स्तरीय अंतर-संचालन
    accDescr: नगरपालिका मानक-अनुरूप प्रणाली व्यक्तिगत नाम आदि के सूचना अंतर-संचालन के लिए प्रशासनिक मामलों के मानक वर्ण उपयोग करती है, और बिना एकीकृत अंतर-संचालन नियमों वाली स्मार्टफ़ोन जैसी बाहरी प्रणालियों से JIS X 0213:2012 के दायरे में अंतर-संचालन करती है
    sys["नगरपालिका मानक प्रणाली"] --> renkei["नाम अंतर-संचालन"]
    sys --> gaibu["बाहरी प्रणालियाँ"]
    renkei --> mjp["प्रशासनिक मानक वर्ण"]
    mjp -.-> mjpN["व्यक्तिगत नाम आदि"]
    gaibu --> jis["JIS X 0213:2012 दायरा"]
    gaibu -.-> sumaho["कोई नियम नहीं （स्मार्टफ़ोन）"]
    mjp -.-> naibu["अंदर चौड़ा सेट रखा"]

चित्र 10: दो-स्तरीय संरचना: सरकारी अंतर-संचालन प्रशासनिक मामलों के मानक वर्ण उपयोग करता है; बिना नियमों वाला बाहरी अंतर-संचालन JIS X 0213:2012 उपयोग करता है।

सामान्य व्यावसायिक प्रणाली के लिए व्यावहारिक मार्गदर्शन के रूप में हम निम्न सुझाते हैं।

स्वीकृत वर्ण सेट तय करें और उसे विनिर्देश तथा इनपुट मान्यता दोनों में कहें। उदाहरण “JIS X 0213:2012 का दायरा”, “निजी-उपयोग क्षेत्र और संयोजन वर्ण अनुमत नहीं”, “IVS स्वीकार नहीं (या स्वीकार है, पर प्रदर्शन केवल IPAmj Mincho वातावरण में गारंटीकृत)”
बिना सीमा स्वीकार न करें। “Unicode है, इसलिए कुछ भी चलेगा” डिज़ाइन प्रदर्शन, मुद्रण या अंतर-संचालन में कहीं टूटेगा
दायरे-बाहर वर्णों का संचालन पहले तय करें। वैकल्पिक निरूपण (नया रूप, कटकाना) प्रतिस्थापित करने का नियम और व्यक्ति को समझाए जाने वाले शब्द स्वयं प्रणाली विनिर्देश हैं
जब सरकार या वित्त जैसी डाउनस्ट्रीम प्रणाली का वर्ण-सेट नियम हो, उसे प्राधिकारी मानें और संरेखित करें

flowchart TB
    accTitle: स्वीकृत वर्ण सेट डिज़ाइन और संचालन
    accDescr: स्वीकृत वर्ण सेट तय करें और उसे विनिर्देश तथा इनपुट मान्यता दोनों में कहें; दायरे में वर्ण स्वीकार करें; दायरे-बाहर वर्णों के लिए वैकल्पिक निरूपण प्रतिस्थापित करने के नियम और व्यक्ति को समझाए जाने वाले शब्दों सहित संचालन तय करें
    decide["स्वीकृत वर्ण सेट तय करें"] --> spec["विनिर्देश में कहें"]
    decide --> valid["इनपुट मान्यता में कहें"]
    valid --> range{"दायरे में?"}
    range -->|हाँ| ok["स्वीकार करें"]
    range -->|नहीं| alt["वैकल्पिक निरूपण प्रतिस्थापित करें"]
    alt -.-> word["व्यक्ति को समझाए जाने वाले शब्द भी विनिर्देश हैं"]

चित्र 11: स्वीकृत वर्ण सेट विनिर्देश और इनपुट मान्यता दोनों में कहें, और दायरे-बाहर संचालन भी तय करें।

7. फ़ॉन्ट चुनना और एम्बेड करना — स्क्रीन और फ़ॉर्म संरेखित करना

7.1. सामान्य फ़ॉन्टों का चरित्र

फ़ॉन्ट	कवरेज	चरित्र और कहाँ उपयोग करें
MS Gothic / MS Mincho	Windows मानक	निम्न-रिज़ॉल्यूशन स्क्रीन के लिए डिज़ाइन किया पुराना हाथ। डिफ़ॉल्ट ग्लिफ़ JIS2004-आधारित²। विरासत फ़ॉर्म के साथ संगतता बनाए रखने के लिए अभी सेवा में
Meiryo	Vista से	ClearType मानने वाला आधुनिक स्क्रीन टाइपफेस। Vista-पीढ़ी JIS2004 माइग्रेशन के साथ आया¹
Yu Gothic / Yu Mincho	Windows 8.1 से	परिवार जो Windows और macOS दोनों पर आता है, जिससे दस्तावेज़ों की दिखावट संरेखित करना आसान होता है
BIZ UD Gothic / BIZ UD Mincho	Windows 10 1809 से	Morisawa सार्वभौमिक-डिज़ाइन टाइपफेस। फ़ॉर्म और स्क्रीन पठनीयता पर ज़ोर वाले कार्यों पर पहला उम्मीदवार¹⁴
Noto Sans JP	अलग स्थापित	ओपन सोर्स के रूप में प्रदान, और सर्वर या Linux वातावरण पर बंडल करना तथा वेब पर वितरित करना आसान

चुनाव में टाइपफेस पसंद से अधिक मायने यह है कि क्या वह फ़ॉन्ट प्रदर्शन, मुद्रण और PDF निर्माण में शामिल हर वातावरण में मौजूद है। Windows 10/11 पर जापानी पूरक फ़ॉन्ट (BIZ UD आदि) कॉन्फ़िगरेशन अनुसार कभी अनुपस्थित होते हैं, और सर्वर पक्ष पर PDF बनाने वाले कॉन्फ़िगरेशन में सर्वर पर फ़ॉन्ट की उपस्थिति या अनुपस्थिति का सीधा प्रभाव पड़ता है।

flowchart TB
    accTitle: फ़ॉन्ट चुनते समय पुष्टि करने वाले वातावरण
    accDescr: फ़ॉन्ट चुनने में टाइपफेस पसंद से अधिक मायने यह है कि क्या वह फ़ॉन्ट प्रदर्शन, मुद्रण और PDF निर्माण में शामिल हर वातावरण में मौजूद है; पूरक फ़ॉन्ट का कॉन्फ़िगरेशन और सर्वर पर फ़ॉन्ट की उपस्थिति या अनुपस्थिति का सीधा प्रभाव पड़ता है
    cand["उम्मीदवार फ़ॉन्ट"] --> exist["हर वातावरण पर?"]
    exist --> scr["प्रदर्शन वातावरण"]
    exist --> more{"मुद्रण या PDF सर्वर?"}
    more --> prn["मुद्रण वातावरण"]
    more --> srv["PDF-निर्माण सर्वर"]
    scr -.-> hojo["पूरक फ़ॉन्ट?"]
    hojo -.-> hojoN["अनुपस्थित हो सकता है"]
    srv -.-> eikyo["सर्वर पर फ़ॉन्ट मायने रखता है"]

चित्र 12: फ़ॉन्ट टाइपफेस पसंद से कम, प्रदर्शन, मुद्रण और PDF निर्माण के हर वातावरण में उपस्थिति से अधिक चुनें।

7.2. फ़ॉर्म डिज़ाइन की बुनियाद — संरेखित करें, और एम्बेड करें

स्क्रीन और फ़ॉर्म पर एक ही फ़ॉन्ट निर्दिष्ट करें। यदि फ़ॉन्ट भिन्न हों, वही डेटा भिन्न ग्लिफ़ दिख सकता है, और आपको खुलती शिकायत मिलती है। “स्क्रीन पर Meiryo, फ़ॉर्म पर MS Mincho” जैसे कॉन्फ़िगरेशन की कम से कम जाँच हो कि 168 JIS2004 वर्णों पर ग्लिफ़ अंतर है या नहीं
PDF में फ़ॉन्ट एम्बेड करें। यदि एम्बेड न करें, देखने वाला पक्ष हाथ में फ़ॉन्ट से स्थानापन्न-चित्रण करता है, और न केवल ग्लिफ़ बल्कि लेआउट बदल सकता है
एम्बेडिंग की अनुमति लाइसेंस तय करता है। OpenType फ़ॉन्ट fsType फ़ील्ड में एम्बेडिंग अनुमतियाँ घोषित करता है (Installable / Restricted / Preview & Print / Editable, no-subsetting आदि), और आप उस फ़ॉन्ट को एम्बेड न करें जिसकी एम्बेडिंग लाइसेंस नहीं।¹¹ वाणिज्यिक फ़ॉन्ट के लिए अनुबंध पुष्टि आवश्यक है
सबसेट एम्बेडिंग आधार रेखा बनाएँ। यदि केवल प्रयुक्त वर्णों के ग्लिफ़ एम्बेड करें, पूरे जापानी फ़ॉन्ट (कई MB से दसियों MB) का बोझ नहीं लेना पड़ता
यदि दीर्घकालिक-प्रतिधारण आवश्यकता हो, PDF/A। PDF/A (ISO 19005) वह मानक है जो प्रदर्शन के लिए आवश्यक संसाधन फ़ाइल के अंदर पूरा करता है, और फ़ॉन्ट एम्बेडिंग आवश्यक है।¹² “दस वर्ष बाद खोला और ग्लिफ़ बदल गए” रोकने का सबसे विश्वसनीय तरीका भी है

flowchart TB
    accTitle: फ़ॉन्ट एम्बेडिंग का निर्णय प्रवाह
    accDescr: PDF में फ़ॉन्ट एम्बेड करने से पहले fsType एम्बेडिंग लाइसेंस पुष्टि करें; यदि लाइसेंस हो, सबसेट एम्बेडिंग आधार रेखा बनाएँ; यदि दीर्घकालिक-प्रतिधारण आवश्यकता हो, PDF/A पर विचार करें, जो एम्बेडिंग माँगता है
    emb["PDF में फ़ॉन्ट एम्बेड करें"] --> lic{"fsType से एम्बेडिंग लाइसेंस?"}
    lic -->|लाइसेंस है| sub["सबसेट एम्बेडिंग आधार रेखा है"]
    lic -->|लाइसेंस नहीं| ng["एम्बेड न करें"]
    sub -.-> gly["केवल प्रयुक्त वर्णों के ग्लिफ़"]
    sub -->|दीर्घकालिक-प्रतिधारण आवश्यकता| pdfa["PDF/A पर विचार करें"]
    pdfa -.-> must["फ़ॉन्ट एम्बेडिंग आवश्यक है"]

चित्र 13: एम्बेडिंग fsType लाइसेंस पुष्टि मानती है; सबसेट एम्बेडिंग और PDF/A आधार रेखा हैं।

मुद्रण और PDF आउटपुट के कार्यान्वयन साधन कैसे चुनें, “Windows व्यावसायिक ऐप में मुद्रण और PDF आउटपुट” में गहराई से कवर है।

8. फ़ॉन्ट लिंकिंग और फ़ॉलबैक — “भिन्न फ़ॉन्ट मिल जाता है” घटना

जिस वर्ण का निर्दिष्ट फ़ॉन्ट के पास ग्लिफ़ नहीं, वह कुछ नहीं दिखता नहीं; दूसरे फ़ॉन्ट में स्थानापन्न-चित्रण आधुनिक चित्रण स्टैक का डिफ़ॉल्ट व्यवहार है। GDI में रजिस्ट्री (FontLink\SystemLink) में परिभाषित “फ़ॉन्ट लिंकिंग” यह करता है; DirectWrite, WPF और ब्राउज़र में “फ़ॉन्ट फ़ॉलबैक” करता है।¹⁵

flowchart TB
    accTitle: फ़ॉन्ट लिंकिंग और फ़ॉलबैक का प्रवाह
    accDescr: यदि निर्दिष्ट फ़ॉन्ट के पास ग्लिफ़ हो वह ज्यों-का-त्यों दिखता है; यदि न हो, लिंक या फ़ॉलबैक फ़ॉन्ट में स्थानापन्न-चित्रण होता है; यदि कहीं ग्लिफ़ न हो □ हो जाता है, पर डेटा अक्सर अभी जीवित है
    disp["वर्ण प्रदर्शित करें"] --> has{"निर्दिष्ट फ़ॉन्ट के पास ग्लिफ़?"}
    has -->|हाँ| draw["निर्दिष्ट फ़ॉन्ट में प्रदर्शित करें"]
    has -->|नहीं| fb{"लिंक या फ़ॉलबैक लक्ष्य में है?"}
    fb -->|हाँ| alt["दूसरे फ़ॉन्ट में स्थानापन्न-चित्रण"]
    alt -.-> mixed["मिश्रित टाइपफेस अनुभूति का कारण"]
    fb -->|नहीं| tofu["□ （टोफ़ू） प्रदर्शित होता है"]
    tofu -.-> alive["डेटा अक्सर अभी जीवित है"]

चित्र 14: □ फ़ॉलबैक विफलता का निशान है; स्थानापन्न-चित्रण सफल हो या नहीं “मिश्रित” और “टोफ़ू” का द्वार है।

इस तंत्र को जानना निम्न आम मामलों की व्याख्या देता है।

लैटिन और जापानी के बीच टाइपफेस अनुभूति भिन्न: क्योंकि लैटिन फ़ॉन्ट पहले निर्दिष्ट था, केवल जापानी भाग लिंक या फ़ॉलबैक जापानी फ़ॉन्ट में खींचा जा रहा है
जापानी वाक्य के केवल कांजी चीनी-शैली ग्लिफ़ हो जाते हैं: फ़ॉलबैक लक्ष्य चीनी फ़ॉन्ट पर हल हुआ। उन वेब पृष्ठों या ऐप में आसान जहाँ भाषा जानकारी (lang विशेषता या लोकेल) सही नहीं जा रही
टोफ़ू (□) आता है: न निर्दिष्ट फ़ॉन्ट न फ़ॉलबैक लक्ष्य के पास ग्लिफ़। अर्थात् □ “फ़ॉलबैक विफलता का निशान” है, और डेटा अक्सर अभी जीवित है

फ़ॉलबैक राहत तंत्र है; शुरुआत से सही फ़ॉन्ट चुनने का विकल्प नहीं।¹⁵ व्यावसायिक ऐप में स्वस्थ स्थिति है “मुख्य प्रदर्शन और मुद्रण पथों पर डिज़ाइन किए फ़ॉन्ट अकेले पूरे करें; फ़ॉलबैक अप्रत्याशित वर्णों का बीमा है”। बहुभाषी UI में फ़ॉन्ट चयन की सोच के लिए “WinForms/WPF ऐप स्थानीयकरण” भी देखें।

9. व्यावसायिक ऐप के लिए कार्यान्वयन चेकलिस्ट

अंत में, इनपुट से अंतर-संचालन तक प्रत्येक परत पर पुष्टि बिंदु तालिका में सारांशित हैं।

परत	विशिष्ट दुर्घटना	डिज़ाइन और कार्यान्वयन बिंदु
इनपुट	वातावरण-निर्भर वर्ण, IVS-युक्त वर्ण, और निजी-उपयोग क्षेत्र वर्ण IME से आते हैं	स्वीकृत वर्ण सेट तय करें और मान्य करें। दायरे-बाहर के लिए त्रुटि के बजाय मार्गदर्शन (वैकल्पिक निरूपण प्रस्तावित करना) काउंटर काम चलाता रखता है
सामान्यीकरण	अनपेक्षित रूपांतरण जैसे NFKC ㈱ को (株) बनाना, पूर्णचौड़ाई और अर्धचौड़ाई एक करना, ① को 1। NFC भी CJK संगतता आइडियोग्राफ़ (उदा. U+FA19 神) को एकीकृत आइडियोग्राफ़ U+795E से बदलता है	व्यक्तिगत नामों और पतों पर NFKC न लगाएँ। सामान्यीकरण को उपयोग तक सीमित करें (खोज कुंजी बनाना आदि) और मूल जैसा दर्ज सहेजें¹³
संग्रहण	सरोगेट जोड़ी और IVS से कॉलम-लंबाई कमी; कोड इकाई से काटना	UTF-8/UTF-16 में सहेजें और कॉलम लंबाई कोड इकाइयों में ढील दें। ग्रेफेम इकाइयों में स्लाइस करें
प्रदर्शन	फ़ॉन्ट के पास ग्लिफ़ न होने से □; फ़ॉलबैक से ग्लिफ़ बदलना	लक्ष्य वर्ण सेट प्रदर्शित कर सकने वाला फ़ॉन्ट स्पष्ट निर्दिष्ट करें, और लक्ष्य OS पर मानक कवरेज पुष्टि करें
मुद्रण और PDF	स्क्रीन और फ़ॉर्म के बीच ग्लिफ़ अंतर; देखने वाले पक्ष पर स्थानापन्न-चित्रण	स्क्रीन और फ़ॉर्म पर फ़ॉन्ट संरेखित करें, और लाइसेंस पुष्टि के बाद PDF में सबसेट-एम्बेड करें¹¹
दूसरी प्रणाली से अंतर-संचालन	JIS X 0213 के अतिरिक्त कांजी, IVS, और गाइजी Shift_JIS (CP932) रूपांतरण में `?` या `〓` हो जाते हैं	अंतर-संचालन विनिर्देश में वर्ण एन्कोडिंग और वर्ण सेट कहें। यदि CP932 अंतर-संचालन रहे, अपरिवर्तनीय वर्णों का पता और प्रतिस्थापन नियम लागू करें

सामान्यीकरण विशेष रूप से वह जाल है जो इस लेख का विषय स्वयं है: “अच्छे इरादे से” लगाया प्रक्रिया जो विविधता वर्णों और पूर्णचौड़ाई बनाम अर्धचौड़ाई का भेद कुचलती है। मूल ज्यों-का-त्यों; प्रतिलिपि पर प्रसंस्करण सिद्धांत है। CSV अंतर-संचालन में वर्ण-एन्कोडिंग दुर्घटनाएँ “CSV "केवल पाठ" नहीं है” में गहराई से कवर हैं।

flowchart TB
    accTitle: मूल ज्यों-का-त्यों; प्रतिलिपि पर प्रसंस्करण
    accDescr: दर्ज स्ट्रिंग को मूल के रूप में ज्यों-का-त्यों सहेजें; खोज कुंजी बनाने जैसे उपयोग तक सीमित प्रतिलिपि पर सामान्यीकरण लगाएँ; मूल पर NFKC लगाने से विविधता वर्णों और पूर्णचौड़ाई बनाम अर्धचौड़ाई का भेद खो जाता है
    input["दर्ज स्ट्रिंग"] --> orig["मूल: जैसा दर्ज सहेजें"]
    input --> copy["प्रतिलिपि: उपयोग तक सीमित सामान्यीकरण"]
    copy -.-> use["खोज कुंजी बनाना आदि"]
    orig -.-> ng["मूल पर NFKC भेद कुचलता है"]

चित्र 15: सामान्यीकरण को उपयोग तक सीमित कर प्रतिलिपि पर लगाएँ; मूल जैसा दर्ज सहेजें।

10. सारांश

वर्ण-समस्या पहले “डेटा परत (वर्ण एन्कोडिंग)” और “दिखावट परत (फ़ॉन्ट)” में बाँटें। � डेटा-परत दुर्घटना का संकेत है, □ दिखावट-परत दुर्घटना का।
JIS X 0213:2004 ने 168 वर्णों के उदाहरण ग्लिफ़ बदले, और Windows Vista से JIS2004 ग्लिफ़ डिफ़ॉल्ट रखता है। 葛, 辻 और 飴 का वातावरण अनुसार अलग दिखना फ़ॉन्ट का इतिहास है, डेटा भ्रष्टता नहीं।
ग्लिफ़ को डेटा के रूप में स्थिर करने का मानक साधन IVS है, पर बिना समर्थक फ़ॉन्ट और समर्थक ऐप डिफ़ॉल्ट ग्लिफ़ पर गिरता है। कार्यान्वयन प्रभाव न भूलें कि एक वर्ण चार UTF-16 कोड इकाइयों तक हो सकता है।
गाइजी (EUDC) उस PC-विशिष्ट संपत्ति है और डेटा के साथ नहीं जा सकता। यथार्थ उत्तर माइग्रेशन पर सूची बनाना, पत्राचार तालिका से नियमित वर्णों या IVS में प्रतिस्थापित करना, और नए बनाना रोकना है।
व्यक्तिगत नाम सँभालने वाली प्रणाली स्वीकृत वर्ण सेट तय करे और कहे। सरकार कोसेकी एकीकृत वर्णों और चरित्र सूचना प्लेटफ़ॉर्म की नींव पर प्रशासनिक मामलों के मानक वर्णों की ओर मानकीकृत कर रही है, और अंतर-संचालन करने वाली प्रणाली उस गति का अनुसरण करे।
फ़ॉर्म और PDF के लिए “फ़ॉन्ट को स्क्रीन से संरेखित करें, लाइसेंस पुष्टि करें, और एम्बेड करें” आधार रेखा है। दीर्घकालिक प्रतिधारण के लिए PDF/A पर विचार करें।
NFKC सामान्यीकरण, कोड इकाई से स्लाइसिंग, और CP932 रूपांतरण वे तीन बिंदु हैं जो चुपचाप विविधता वर्णों और गाइजी तोड़ते हैं। मूल सहेजना और ग्रेफेम इकाइयों में प्रसंस्करण सिद्धांत बनाएँ।

अगली बार जब कहा जाए “वर्ण भिन्न है”, पहले प्रश्न इस तरह पुनः ढालें। क्या कोड पॉइंट एक हैं, या भिन्न? यदि एक हैं तो फ़ॉन्ट समस्या है; यदि भिन्न हैं तो डेटा समस्या है। वह एक चाल जाँच के ग़लत प्रवेश बिंदु से बचाती है।

flowchart TB
    accTitle: पहला प्रश्न जो जाँच का प्रवेश बिंदु तय करता है
    accDescr: जब कहा जाए वर्ण भिन्न है, पहले तुलना करें कि कोड पॉइंट एक हैं या भिन्न; यदि एक हैं जाँच फ़ॉन्ट समस्या के रूप में शुरू करें, यदि भिन्न हैं डेटा समस्या के रूप में
    said["कहा गया वर्ण भिन्न है"] --> cmp{"क्या कोड पॉइंट एक हैं?"}
    cmp -->|एक| fontp["फ़ॉन्ट समस्या"]
    cmp -->|भिन्न| datap["डेटा समस्या"]

चित्र 16: यदि कोड पॉइंट एक हैं, जाँच फ़ॉन्ट समस्या के रूप में शुरू करें; यदि भिन्न हैं, डेटा समस्या के रूप में।

संदर्भ लिंक

Morisawa Inc., JIS X 0213:2004 (JIS2004) | Font glossary. JIS X 0213:2004 में Hyogai Kanji Jitaihyo का अनुसरण कर 168 कांजी के उदाहरण ग्लिफ़ मुद्रण-मानक रूपों (तथाकथित कांग्शी शब्दकोश रूपों) में संशोधित होने पर; और Windows Vista में JIS2004-सक्षम फ़ॉन्ट मानक शामिल होने पर। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, MS Gothic font family. MS Gothic परिवार का डिफ़ॉल्ट ग्लिफ़ JIS2004-आधारित होने पर, और OpenType ‘jp90’ फ़ीचर से JIS90 विरासत ग्लिफ़ तक पहुँचने पर। ↩ ↩² ↩³
Microsoft Learn, The Unicode standard. विविधता अनुक्रम आधार वर्ण प्लस वैचारिक विविधता चयनकर्ता (VS1–VS256, U+FE00–U+FE0F और U+E0100–U+E01EF) से बना होने पर; U+845B 葛 को U+845B+U+E0100 (VS17) से अलग करने के उदाहरण पर (निशी-कासाई स्टेशन और कत्सुरागी नगर); और प्रदर्शन के लिए समर्थक फ़ॉन्ट आवश्यक होने पर। ↩ ↩² ↩³
Unicode Consortium, Ideographic Variation Database. UTS #37 पर आधारित IVS रजिस्ट्री। Adobe-Japan1 (2007), Hanyo-Denshi (2010), और Moji_Joho (2014) जैसे संग्रह पंजीकृत होने पर, और अगस्त 2026 संस्करण में Moji_Joho संग्रह में अतिरिक्त पंजीकरण भी होने पर। ↩ ↩²
Microsoft Learn, cmap — Character to Glyph Index Mapping Table (OpenType spec). OpenType फ़ॉन्ट cmap उपतालिका फ़ॉर्मैट 14 में Unicode विविधता अनुक्रम लागू करने पर; डिफ़ॉल्ट और गैर-डिफ़ॉल्ट UVS के भेद पर; और JIS2004-सक्षम फ़ॉन्ट में उपयोग उदाहरणों पर। ↩ ↩²
Microsoft Learn, End-User-Defined and Private Use Area Characters. गाइजी (EUDC) और निजी-उपयोग क्षेत्र (PUA) वर्ण उपयोगकर्ता या संगठन द्वारा स्वतंत्र परिभाषित होने पर, और एक ही कोड पॉइंट कंप्यूटर अनुसार भिन्न असाइनमेंट — और टकराव — रख सकने पर। ↩ ↩²
Microsoft Learn, Character Sets and Fonts. PUA (U+E000–U+F8FF आदि) Unicode EUDC उद्देश्यों के लिए उपयोग होने पर; निजी वर्ण संपादक में ग्लिफ़ बनाने पर; और EUDC फ़ॉन्ट .tte फ़ाइल के रूप में छिपे स्थापित होकर HKEY_CURRENT_USER\EUDC रजिस्ट्री में फ़ॉन्ट से जुड़ने पर। ↩ ↩²
Ministry of Justice, Koseki Unified Character Information — search-condition input. न्याय मंत्रालय द्वारा प्रदान कोसेकी एकीकृत वर्णों की आधिकारिक खोज साइट। परिवार रजिस्टरों में प्रयुक्त वर्णों के ग्लिफ़, पठन और संबंधित जानकारी खोजने पर। ↩ ↩²
Character Information Technology Promotion Council, Character Information Platform project. चरित्र सूचना प्लेटफ़ॉर्म (MJ वर्ण ग्लिफ़, MJ वर्ण-सूचना सूची, और IPAmj Mincho फ़ॉन्ट) पर, जिसे IPA ने अर्थव्यवस्था, व्यापार और उद्योग मंत्रालय आदि के समर्थन से व्यवस्थित किया और प्रशासनिक कार्य में प्रयुक्त लगभग 60,000 कांजी कवर करता है, अब परिषद को हस्तांतरित और प्रकाशित। ↩ ↩²
Digital Agency, Report of the Study Group on the Operation of Character Requirements in Local-Government Information Systems (July 2024). नगरपालिकाओं में प्रयुक्त गाइजी लगभग दो मिलियन वर्ण कहे जाने पर; चरित्र सूचना प्लेटफ़ॉर्म का विस्तार “प्रशासनिक मामलों के मानक वर्ण” (सामान्यतः MJ+) मानक-अनुरूप प्रणालियों में व्यक्तिगत नाम आदि का वर्ण सेट होने पर, वर्ण एन्कोडिंग JIS X 0221:2020; व्यक्तिगत नाम आदि के सूचना अंतर-संचालन के लिए प्रशासनिक मामलों के मानक वर्ण, और स्मार्टफ़ोन आदि से अंतर-संचालन के लिए JIS X 0213:2012 उपयोग पर; और पारंपरिक गाइजी को प्रशासनिक मामलों के मानक वर्णों के विरुद्ध अद्वितीय पहचानने और उपयोग न करने की नीति पर। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, OS/2 — OS/2 and Windows Metrics (OpenType spec). फ़ॉन्ट का fsType फ़ील्ड एम्बेडिंग लाइसेंस परिभाषित करने पर (Installable / Restricted License / Preview & Print / Editable, no-subsetting बिट आदि), और अनुप्रयोग को उस फ़ॉन्ट एम्बेड करने की अनुमति न होने पर जिसकी एम्बेडिंग लाइसेंस नहीं। ↩ ↩² ↩³
PDF Association, PDF/A Basics. दीर्घकालिक-प्रतिधारण PDF/A (ISO 19005) दस्तावेज़ प्रदर्शित करने के लिए आवश्यक तत्व फ़ाइल के अंदर शामिल करने की माँग करने पर, फ़ॉन्ट एम्बेडिंग प्रतिनिधि आवश्यक उदाहरण। ↩ ↩²
Microsoft Learn, Using Unicode Normalization to Represent Strings. चार Unicode सामान्यीकरण रूप NFC/NFD/NFKC/NFKD पर; और KC/KD रूप पूर्णचौड़ाई और अर्धचौड़ाई जैसे संगतता वर्ण एक कर जानकारी खो देने पर, इसलिए सामान्यतः स्ट्रिंग के प्रामाणिक संग्रहीत रूप के रूप में उपयुक्त नहीं। ↩ ↩²
Microsoft Learn, BIZ UDGothic font family. Morisawa सार्वभौमिक-डिज़ाइन टाइपफेस BIZ UD Gothic Windows 10 संस्करण 1809 से जापानी पूरक फ़ॉन्ट के रूप में शामिल होने पर। ↩
Microsoft Learn, Fonts (Globalization documentation). फ़ॉन्ट फ़ॉलबैक तंत्र पर; GDI फ़ॉन्ट लिंकिंग (FontLink\SystemLink रजिस्ट्री) पर; डिफ़ॉल्ट ग्लिफ़ (टोफ़ू) के अर्थ पर; और फ़ॉन्ट लिंकिंग सही फ़ॉन्ट चुनने का विकल्प न होने पर। ↩ ↩²

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

Windows वर्चुअलाइज़ेशन की गहराई (भाग 3) — सेकंडों में बूट होने वाली वर्चुअल मशीनें: WSL2, Windows Sandbox और कंटेनर इतने हल्के क्यों हैं

WSL2 और Windows Sandbox सेकंडों में शुरू होकर इतने हल्के क्यों लगते हैं? यह लेख डायनामिक बेस इमेज और डायरेक्ट मैप से डायनामिक मेमोरी आवंट...

लेख पढ़ें

Windows वर्चुअलाइज़ेशन की गहराई (भाग 2) — वह मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

संगत हार्डवेयर पर क्लीन इंस्टॉल पर VBS डिफ़ॉल्ट से सक्षम होता है और हाइपरवाइज़र तथा SLAT से कर्नेल से मज़बूत अलगाव बनाता है। यह लेख VTL, ...

लेख पढ़ें

Windows वर्चुअलाइज़ेशन की गहराई (भाग 1) — आपका Windows वास्तव में कहाँ चल रहा है? हाइपरवाइज़र और पार्टीशन

जब आप Hyper-V सक्षम करते हैं, तो होस्ट Windows स्वयं रूट पार्टीशन के रूप में हाइपरवाइज़र के ऊपर चलता है। यह लेख VT-x, SLAT और VMBus की भू...

लेख पढ़ें

Win32 Thread Pool API — CreateThreadpoolWork से थ्रेड बनाए बिना समवर्तिता

क्या आपके नेटिव कोड में CreateThread कॉल बिखरी पड़ी हैं? यह लेख Vista में पुनर्डिज़ाइन की गई Win32 थ्रेड पूल API — work, timer, wait और i...

लेख पढ़ें

Named Pipes व्यवहार में — डिज़ाइन से सुरक्षा तक, Windows की मानक IPC

Named pipes — Windows की मानक इंटर-प्रोसेस कम्युनिकेशन — की व्यावहारिक मार्गदर्शिका। यह लेख प्राथमिक स्रोतों से बाइट और मैसेज मोड का चुना...

लेख पढ़ें

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

Windows ऐप विकास

व्यावसायिक ऐप, डिवाइस एकीकरण और संचार उपकरण, आवश्यकताओं से विकास तक।

सेवा देखें संपर्क करें

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

एक ही 葛 अक्षर PC या मुद्रित फ़ॉर्म के अनुसार अलग क्यों दिखता है?: यह मोजीबाके से अधिक फ़ॉन्ट ग्लिफ़ का अंतर है। JIS X 0213:2004 (JIS2004) ने 168 कांजी के उदाहरण ग्लिफ़ मुद्रण-मानक रूपों में संशोधित किए, और Windows ने भी Vista से MS Gothic / MS Mincho आदि में JIS2004 ग्लिफ़ डिफ़ॉल्ट किए। 葛, 辻, 飴 जैसे प्रतिनिधि उदाहरण हैं: Unicode कोड पॉइंट (डेटा) वही रहता है, और केवल फ़ॉन्ट का ग्लिफ़ (दिखावट) बदला है। डेटा तुलना मेल खाती है; XP-युग फ़ॉर्म छवि और नए PC की स्क्रीन के आकार का बेमेल निर्दिष्ट व्यवहार है। यदि ग्लिफ़ भी संरेखित चाहें, स्क्रीन और फ़ॉर्म पर एक ही फ़ॉन्ट उपयोग करें, या वैचारिक विविधता चयनकर्ता से ग्लिफ़ निर्दिष्ट करें।
यदि वैचारिक विविधता चयनकर्ता (IVS) उपयोग करें, क्या हर व्यक्तिगत-नाम ग्लिफ़ समस्या हल होती है?: नहीं। IVS वह तंत्र है जो आधार वर्ण के तुरंत बाद U+E0100 से चयनकर्ता रखकर ग्लिफ़ डेटा के रूप में निर्दिष्ट करता है, और निर्दिष्ट ग्लिफ़ तभी दिखता है जब IPAmj Mincho जैसा समर्थक फ़ॉन्ट और समर्थक ऐप दोनों हों। असमर्थित वातावरण में निर्दिष्ट व्यवहार यह है कि चयनकर्ता अनदेखा हो और आधार वर्ण का डिफ़ॉल्ट ग्लिफ़ दिखे; कुछ वातावरण में चयनकर्ता □ भी दिख सकता है। आगे, एक IVS-युक्त वर्ण UTF-16 में चार कोड इकाइयों तक हो सकता है, जो वर्ण-गणना, स्लाइसिंग और DB कॉलम लंबाई के डिज़ाइन को प्रभावित करता है। यदि लाएँ, प्रदर्शन, मुद्रण और डाउनस्ट्रीम प्रणालियों से समर्थन का दायरा पुष्टि कर उपयोग करें।
गाइजी (EUDC) के रूप में पंजीकृत वर्ण दूसरे PC या PDF में दिख सकता है?: सिद्धांततः नहीं। गाइजी वह तंत्र है जिसमें उपयोगकर्ता उस PC की eudc.tte फ़ाइल में Unicode निजी-उपयोग क्षेत्र (U+E000 से) के कोड पॉइंट पर ग्लिफ़ पंजीकृत करता है; वही कोड पॉइंट दूसरे PC पर अपरिभाषित या भिन्न ग्लिफ़ है। मेल, PDF या दूसरी प्रणाली को सौंपने का भाग्य इसलिए □ होना या भिन्न वर्ण दिखना है। यदि गाइजी-युक्त विरासत डेटा पहले से है, माइग्रेशन पर यथार्थ पथ निजी-उपयोग क्षेत्र के उपयोगों की सूची बनाना, नियमित Unicode वर्णों या वैचारिक विविधता चयनकर्ताओं से पत्राचार तालिका बनाना, और प्रतिस्थापित करना है। नई प्रणाली में नया गाइजी बनाना टालें।
व्यावसायिक प्रणाली व्यक्तिगत नामों में वर्ण कितना स्वीकार करे?: पहली बात "स्वीकृत वर्ण सेट तय कर विनिर्देश के रूप में कहना" है। परिवार रजिस्टरों में लगभग 56,000 कोसेकी एकीकृत वर्ण हैं, और सरकार-मानक अनुरूप प्रणालियाँ प्रशासनिक मामलों के मानक वर्णों की ओर बढ़ रही हैं — चरित्र सूचना प्लेटफ़ॉर्म का विस्तार — पर सामान्य व्यावसायिक प्रणाली उसी स्तर को बिना सीमा स्वीकार करने को बाध्य नहीं। यथार्थ डिज़ाइन है "JIS X 0213 के दायरे तक" या "वैचारिक विविधता चयनकर्ता या निजी-उपयोग क्षेत्र स्वीकार न करें" जैसी सीमा तय करना, इनपुट पर मान्य करना, और दायरे-बाहर मामलों को चेतावनी या वैकल्पिक निरूपण से चलाना। केवल वे प्रणालियाँ जो सरकार या नगरपालिकाओं से अंतर-संचालन करती हैं प्रशासनिक मामलों के मानक वर्णों और JIS X 0221-आधारित अंतर-संचालन आवश्यकताओं का अनुसरण करें।
फ़ॉर्म या PDF स्क्रीन जैसे ही वर्ण कैसे दिखाए?: आधार रेखा स्क्रीन और फ़ॉर्म पर एक ही फ़ॉन्ट निर्दिष्ट करना, और PDF में फ़ॉन्ट एम्बेड करना है। यदि फ़ॉन्ट भिन्न हों, वही डेटा ग्लिफ़ बदल सकता है; यदि देखने वाले PC के पास फ़ॉन्ट न हो, स्थानापन्न फ़ॉन्ट से चित्रण होता है और दिखावट टूटती है। एम्बेडिंग की अनुमति फ़ॉन्ट के लाइसेंस (OpenType fsType) से तय होती है, इसलिए पुष्टि करें — रिपोर्ट लाइब्रेरी पर न छोड़ें। सबसेट एम्बेडिंग, जो केवल प्रयुक्त वर्ण एम्बेड करती है, फ़ाइल आकार भी घटाती है। यदि दीर्घकालिक प्रतिधारण आवश्यकता हो, PDF/A पर विचार करें, जो फ़ॉन्ट एम्बेडिंग माँगता है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।

प्रोफ़ाइल देखें संपर्क करें

सार्वजनिक लिंक

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ब्लॉग पर लौटें

जापानी फ़ॉन्ट और वर्ण के जाल — व्यावसायिक ऐप में JIS2004, IVS और गाइजी सँभालना

1. निष्कर्ष पहले

2. डेटा और दिखावट को अलग सोचना — कोड पॉइंट और ग्लिफ़

3. JIS90 से JIS2004 — कोड वही रहा, ग्लिफ़ बदला

4. वैचारिक विविधता चयनकर्ता (IVS) — ग्लिफ़ को डेटा के रूप में निर्दिष्ट करना

4.1. असमर्थित वातावरण में व्यवहार

4.2. कार्यान्वयन सावधानी — “एक वर्ण” चार कोड इकाइयों तक हो सकता है

5. गाइजी (EUDC) — वर्ण जो केवल उस PC पर दिखते हैं

5.1. पहले से गाइजी पा चुकी प्रणाली का यथार्थ उत्तर

6. सरकारी वर्ण प्लेटफ़ॉर्म — कोसेकी एकीकृत वर्णों से प्रशासनिक मामलों के मानक वर्णों तक

7. फ़ॉन्ट चुनना और एम्बेड करना — स्क्रीन और फ़ॉर्म संरेखित करना

7.1. सामान्य फ़ॉन्टों का चरित्र

7.2. फ़ॉर्म डिज़ाइन की बुनियाद — संरेखित करें, और एम्बेड करें

8. फ़ॉन्ट लिंकिंग और फ़ॉलबैक — “भिन्न फ़ॉन्ट मिल जाता है” घटना

9. व्यावसायिक ऐप के लिए कार्यान्वयन चेकलिस्ट

10. सारांश

संबंधित लेख

संबंधित परामर्श क्षेत्र

संदर्भ लिंक

Windows वर्चुअलाइज़ेशन की गहराई (भाग 2) — वह मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

Windows वर्चुअलाइज़ेशन की गहराई (भाग 1) — आपका Windows वास्तव में कहाँ चल रहा है? हाइपरवाइज़र और पार्टीशन

Win32 Thread Pool API — CreateThreadpoolWork से थ्रेड बनाए बिना समवर्तिता

Named Pipes व्यवहार में — डिज़ाइन से सुरक्षा तक, Windows की मानक IPC

संबंधित विषय

Windows के तकनीकी विषय

इस विषय से जुड़ी सेवाएँ

Windows ऐप विकास

अक्सर पूछे जाने वाले प्रश्न

लेखक की प्रोफ़ाइल

Go Komura