Japanese fonts और character के जाल — business apps में JIS2004, IVS और gaiji सँभालना

“Customer list का 葛 अक्षर screen और printed form पर अलग दिखता है। Customer ने शिकायत की कि data corrupt होना चाहिए।” — business-system maintenance में इस तरह का परामर्श दुर्लभ नहीं। दूसरा आम है “व्यक्ति के नाम का अक्षर सरकारी कार्यालय को सौंपे document पर display नहीं होता। पुराने PC पर दिखता था; बदलने के बाद □ हो गया।”

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

flowchart TB
    accTitle: दो आम परामर्श वास्तव में क्या हैं
    accDescr: परामर्श कि 葛 screen और form पर अलग दिखता है वह मामला है जहाँ data वही रहा और केवल दिखावट बदली; परामर्श कि PC बदलने के बाद □ हो गया वह मामला है जहाँ केवल उस PC पर मौजूद gaiji खो गया; दोनों encoding-mismatch mojibake से भिन्न समस्या हैं
    c1["परामर्श 1: आकार screen और form पर भिन्न"] --> r1["Data unchanged; केवल दिखावट बदली"]
    c2["परामर्श 2: बदलने के बाद □ हो गया"] --> r2["केवल उस PC पर मौजूद gaiji खो गया"]
    r1 --> diff["Encoding mojibake से भिन्न समस्या"]
    r2 --> diff

चित्र 1: “Mojibake” कहलाने वाले दोनों परामर्श encoding mismatch से भिन्न समस्या हैं।

इस लेख का वादा सरल है। यदि character-code (data) layer को font (दिखावट) layer से अलग करें, अधिकांश Japanese character-problem सुलझ जाती है। JIS2004 glyph changes, Ideographic Variation Selector (IVS), और gaiji (EUDC) से, government के character platform से होते, font चुनने और embed करने तक, business systems के developers और IT staff के decision के लिए व्यवस्थित है।

Shift_JIS ↔ UTF-8 conversion में होने वाला “mojibake” स्वयं existing लेखों में cover है, इसलिए यह लेख “code round-trip सही हैं, पर दिखावट या displayability गलत है” की समस्या पर केंद्रित है।

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

• “Mojibake” और “glyph भिन्न है” भिन्न समस्याएँ हैं। Mojibake byte sequence की गलत व्याख्या की data-layer accident है; glyph अंतर font के glyph के अंतर की दिखावट-layer accident है; treatment पूरी तरह भिन्न हैं।
• एक ही Unicode code point पर भी displayed glyph font पर निर्भर करता है। JIS X 0213:2004 ने 葛, 辻 और 飴 जैसे 168 characters के example glyphs printing-standard forms में संशोधित किए, और Windows ने भी Vista से MS Gothic / MS Mincho में JIS2004 glyphs default किए।¹²
• Glyph को data के रूप में स्थिर करने का standard means Ideographic Variation Selector (IVS) है। आप base character प्लस U+E0100 से selector के sequence से glyph specify करते हैं; Adobe-Japan1, Hanyo-Denshi, और Moji_Joho (Character Information Platform) जैसे collections Unicode के IVD में registered हैं।³⁴
• Unsupported environment में IVS का specified behavior यह है कि selector ignore हो और base character का default glyph display हो। पर एक IVS-युक्त character UTF-16 में चार code units तक हो सकता है, इसलिए character-count और slicing के implementations सावधानी चाहते हैं।⁵
• Gaiji (EUDC) का भाग्य “केवल उस PC पर दिख सकता है” है। Private Use Area code point का सहमत अर्थ नहीं, और eudc.tte में registered glyph दूसरे PC, mail या PDF तक नहीं जाता।⁶⁷
• व्यक्तिगत नाम सँभालने वाली system accepted character set तय करे और कहे। Government पक्ष पर, koseki unified characters और Character Information Platform पर बनकर, standard-conforming systems “प्रशासनिक मामलों के standard characters” उपयोग की ओर बढ़ रही हैं।⁸⁹¹⁰
• Forms और PDF के लिए “font को screen से align करें, और embed करें” base line है। Embedding की अनुमति font के license (fsType) से तय होती है, और long-term-retention PDF/A font embedding माँगता है।¹¹¹²
• व्यक्तिगत-नाम data पर normalization (NFKC) लापरवाही से न लगाएँ। Fullwidth और halfwidth एक करना, और compatibility characters बदलना, वे भेद खो देता है जो रखने चाहिए।¹³

एक वाक्य में: “कौन सा byte sequence store करें” data-design समस्या है; “कैसा दिखता है” font-design समस्या है। दोनों मिलाकर चर्चा करें तो हल करने योग्य समस्याएँ भी हल न हों।

2. Data और दिखावट को अलग सोचना — code point और glyph

Unicode में character एक संख्या से represent होता है जिसे code point कहते हैं। 葛 U+845B है, और यह संख्या हर PC पर एक है। वह संख्या screen या काग़ज़ पर कैसे खींची जाए, दूसरी ओर, font के glyph से तय होती है। एक ही U+845B का font A और font B के बीच आकार के विवरण में भिन्न होना normal behavior है।

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

विभाजन के संकेत के रूप में “�” और “□” का अंतर याद रखना उपयोगी है। U+FFFD (REPLACEMENT CHARACTER) का “�” data layer पर conversion failure का निशान है, और original character पहले ही खो चुका है। “□” दूसरी ओर कई मामलों में केवल यह है कि data अभी है पर font के पास glyph नहीं, और font बदलने से display हो सकता है।

flowchart TB
    accTitle: लक्षण को � बनाम □ से बाँटना
    accDescr: जब character सही display न हो, � data layer पर conversion failure का निशान है जिसमें original character खो चुका है; □ केवल यह है कि data अभी है पर font के पास glyph नहीं, और font बदलने से display हो सकता है
    symptom["Character सही display नहीं होता"] --> which{"क्या दिखता है?"}
    which -->|� दिखता है| datalayer["Data-layer accident"]
    datalayer -.-> lost["Conversion failure का निशान （original character खो गया）"]
    which -->|□ दिखता है| viewlayer["दिखावट-layer accident"]
    viewlayer -.-> noglyph["केवल यह कि font के पास glyph नहीं"]
    noglyph --> fixable["Font बदलने से display हो सकता है"]

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

Encoding की बुनियाद स्वयं (CP932 और UTF-8, BOM, newline codes) “Windows text encoding का परिचय - Linux से integration पर होने वाला mojibake” और “Windows text encoding और line endings - mojibake और CRLF/LF की बुनियाद” में cover है। यहाँ से दिखावट layer है, और उसकी सीमा पर होने वाली समस्याएँ।

3. JIS90 से JIS2004 — code वही रहा, glyph बदला

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

National Language Council की 2000 report “Hyogai Kanji Jitaihyo” (joyo list से बाहर kanji के रूपों की table) के अनुसार, 2004 amendment JIS X 0213:2004 (सामान्यतः JIS2004) ने 168 kanji के example glyphs printing-standard forms में संशोधित किए, तथाकथित Kangxi dictionary forms के निकट। 葛, 辻, 飴, 芦, 溢, 餅 जैसे representative उदाहरण हैं।¹

Windows ने इसके साथ align कर Windows Vista से MS Gothic / MS Mincho (और नए Meiryo) में JIS2004 glyphs default किए। Current MS Gothic भी JIS2004-based default glyphs रखता है, उस structure के साथ कि JIS90-era glyphs OpenType jp90 feature से accessible हैं।²¹

flowchart TB
    accTitle: Current MS Gothic की glyph structure
    accDescr: Vista से MS Gothic के default JIS2004 glyphs हैं, और OpenType jp90 feature से JIS90-era glyphs तक पहुँचना structure है
    msg["MS Gothic （Vista से）"] --> def["Default glyphs: JIS2004-based"]
    msg --> feat["jp90 feature से"]
    feat --> old["JIS90-era glyphs"]

चित्र 3: Current MS Gothic के default JIS2004 glyphs हैं, और jp90 feature से JIS90 glyphs पर switch कर सकते हैं।

यहाँ मायने यह है कि केवल font बदला; data बिल्कुल नहीं बदला।

• 葛 का code point XP और Windows 11 दोनों पर U+845B है
• XP (JIS90 glyph) पर वह रूप दिखता है जो wrapping radical के अंदर को ヒ सरल करता है; Vista से (JIS2004 glyph) वह रूप दिखता है जो अंदर 人 भी लिखता है
• इसलिए पुरानी system पर printed form की scan image और नए PC की screen display character के आकार में असहमत हैं। Data comparison पूरी तरह match खाती है

辻 के shinnyo radical में एक बिंदु है या दो, 飴 के “खाओ” radical का रूप, और जैसे वही हैं। यदि यह इतिहास न जानें, जाँच “migration में data corrupt हुआ” की गलत दिशा जाती है। जब कहा जाए कि migration के पहले-बाद character की दिखावट भिन्न है, पहले code point compare करें, और यदि match खाएँ, font glyph अंतर संदेह करें — वही सही क्रम है।

flowchart TB
    accTitle: एक ही code point, font अनुसार भिन्न glyphs
    accDescr: 葛 का code point U+845B XP और Windows 11 दोनों पर वही रहता है; केवल displayed आकार JIS90-glyph font और JIS2004-glyph font के बीच बदलता है, और data comparison पूरी तरह match खाती है
    cp["Code point U+845B （葛）"] --> f90["JIS90-glyph font （XP）"]
    cp --> f04["JIS2004-glyph font （Vista से）"]
    f90 --> g90["वह रूप जो अंदर को ヒ सरल करता है"]
    f04 --> g04["Printing-standard रूप जो अंदर 人 लिखता है"]
    g90 -.-> same["Data comparison पूरी तरह match खाती है"]
    g04 -.-> same

चित्र 4: केवल font बदला; code point U+845B हर environment में वही रहता है।

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

4. Ideographic Variation Selector (IVS) — glyph को data के रूप में specify करना

IVS (Ideographic Variation Sequence) वह mechanism है जो kanji के तुरंत बाद “Ideographic Variation Selector” नामक invisible code point रखकर glyph variation को data के रूप में specify करता है। प्रयुक्त selectors U+E0100–U+E01EF (VS17–VS256) हैं।³

कौन सा “base character + selector” sequence किस glyph को संदर्भित करता है, IVD (Ideographic Variation Database) नामक registry तय करती है, जिसे Unicode Consortium manage करता है। मुख्य collections निम्न हैं।⁴

Microsoft का documentation उदाहरण देता है कि अकेला U+845B (葛) Nishi-Kasai station के लेखन में उपयोग होता है, और U+845B+U+E0100 (VS17) Nara के Katsuragi town के लेखन में। एक ही 葛, पर कौन सा glyph है data के रूप में अलग किया जा सकता है।³

flowchart TB
    accTitle: IVS से एक ही 葛 को data के रूप में अलग करने का उदाहरण
    accDescr: अकेले U+845B के रूप में 葛 Nishi-Kasai station के लेखन में उपयोग होता है; U+845B के बाद VS17 का sequence Katsuragi town के लेखन में उपयोग होता है; कौन सा sequence किस glyph को संदर्भित करता है IVD registry तय करती है
    seq1["अकेला U+845B"] --> gl1["Nishi-Kasai station के लेखन में प्रयुक्त glyph"]
    seq2["U+845B + VS17"] --> gl2["Katsuragi town के लेखन में प्रयुक्त glyph"]
    ivd["IVD （registry）"] -.-> gl1
    ivd -.-> gl2

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

4.1. Unsupported environment में व्यवहार

Font पक्ष पर, IVS और glyph का correspondence OpenType cmap table (format 14) में implement होता है।⁵ जब supporting font (IPAmj Mincho आदि) और supporting app दोनों हों, specified glyph आता है; जब न हों, निम्न होता है।

• Specified सही behavior: Selector ignore हो और base character का default glyph display हो (selector स्वयं invisible)
• पुराने apps और कुछ rendering stacks: Selector स्वतंत्र unknown character माना जाता है, और extra □ display होता है

यानी IVS इस तरह design है कि “भले बिगड़े, base character readable रहे”, पर “हमेशा specified glyph में display होगा” की guarantee recipient के environment पर निर्भर है। सरकारी resident-record और family-register systems Character Information Platform font प्लस IVS का combination उपयोग करती हैं, पर यदि सामान्य business system इसे लापरवाही से स्वीकार करे, glyph display, printing या downstream system में कहीं गिरेगा।

flowchart TB
    accTitle: IVS-युक्त data कैसे display होता है
    accDescr: जब supporting font और supporting app दोनों हों specified glyph दिखता है; जब न हों, selector ignore हो और base character का default glyph दिखे; पुराने apps और कुछ rendering stacks में selector unknown character माना जाता है और extra □ दिखता है
    ivs["Base + IVS selector"] --> env{"Supporting font + app?"}
    env -->|हाँ| ok["Specified glyph"]
    env -->|नहीं| other{"कैसे खींचा जाता है?"}
    other -->|Ignore| ignore["Default glyph"]
    other -->|पुराना / कुछ stacks| tofu["Extra □"]
    ignore -.-> spec["Specified सही"]

चित्र 6: IVS बिगड़ने पर भी base character के रूप में readable रहता है, पर specified glyph आएगा या नहीं recipient के environment पर निर्भर है।

4.2. Implementation सावधानी — “एक character” चार code units तक हो सकता है

U+E0100 से IVS selectors supplementary plane पर code points हैं, इसलिए UTF-16 में हमेशा surrogate pair (दो code units) हैं। यदि base character supplementary-plane kanji हो (उदाहरण 𠮟 (U+20B9F), JIS2004 में जोड़ा), base अकेला पहले से दो code units है, और वह sequence जिसे user “एक character” मानता है UTF-16 में चार code units तक, और UTF-8 में आठ bytes तक है।

• C# का "葛󠄀" (葛+VS17) string.Length == 3 रखता है। Substring और fixed-length slicing base character को selector से अलग करने का जोखिम रखते हैं
• Character-count और slicing की assumption grapheme units में हो (StringInfo जैसे API), code units में नहीं
• DB column length के लिए (SQL Server का nvarchar(n) UTF-16 code units में है), यदि IVS स्वीकार करें, direct character-count का दो से चार गुना प्रावधान करें
• Search और comparison में, selector की उपस्थिति या अनुपस्थिति भिन्न string बनाती है। “葛” की search “葛+VS17” पर लगे या नहीं, requirement के रूप में तय कर implement करें

flowchart TB
    accTitle: एक IVS-युक्त character और UTF-16 code units
    accDescr: Base character और Ideographic Variation Selector का sequence जिसे user एक character मानता है selector के लिए हमेशा surrogate pair है, और यदि base character supplementary-plane kanji हो अन्य दो code units, UTF-16 में अधिकतम चार code units
    one["एक दृश्य character"] --> base["Base character"]
    one --> vs["Variation selector"]
    base -.-> bnote["Supplementary हो तो +2"]
    vs -.-> vnote["हमेशा 2 code units"]
    base --> total["4 UTF-16 units तक"]
    vs --> total
    total -.-> risk["Fixed slicing में टूटना"]

चित्र 7: एक IVS-युक्त character UTF-16 में चार code units तक हो सकता है; code unit से slice करना खतरनाक है।

5. Gaiji (EUDC) — characters जो केवल उस PC पर दिखते हैं

Gaiji वह mechanism है जिसमें user Unicode Private Use Area (PUA: U+E000–U+F8FF आदि) के code points पर अपना glyph assign करता है। Private Use Area code points का विश्वव्यापी सहमत अर्थ नहीं; एक ही U+E000 प्रति PC और प्रति organization भिन्न character assign हो सकता है।⁶

Windows पर आप glyphs Private Character Editor (eudcedit.exe) से बनाते हैं, और वह eudc.tte नामक font file में save होता है। यह file hidden font के रूप में install होती है और HKEY_CURRENT_USER\EUDC registry में प्रत्येक font से जुड़ती है।⁷ Shift_JIS (CP932) युग में gaiji range 0xF040–0xF9FC थी, और Unicode conversion पर Private Use Area में map होती है।

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

• eudc.tte उस PC (उस user) का है और data के साथ दूसरे पक्ष तक नहीं जाता
• Mail, PDF, web या दूसरी system को सौंपते ही □ हो जाता है या दूसरे पक्ष के भिन्न gaiji जैसा दिखता है
• OS migration या PC replacement में eudc.tte migrate करना भूलें तो “पुराने PC पर दिखने वाला character नहीं दिखता” होता है

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

flowchart TB
    accTitle: Gaiji केवल उस PC पर क्यों दिखते हैं
    accDescr: Private Character Editor में बना glyph eudc.tte में save होता है और उस PC की registry में font से जुड़ता है, इसलिए यदि केवल Private Use Area code mail, PDF या दूसरी system को जाए तो □ हो जाता है या भिन्न character दिखता है
    edit["PUA glyph बनाएँ"] --> tte["eudc.tte में save करें"]
    edit -.-> editN["Private Character Editor"]
    tte --> reg["Registry font mapping"]
    reg --> local["उस PC पर दिखता है"]
    tte -.-> stay["eudc.tte पीछे रह जाता है"]
    send["केवल PUA code जाता है"] --> dest["Mail / PDF / अन्य system"]
    dest --> broken["□ या गलत character"]
    local ~~~ send

चित्र 8: Glyph eudc.tte में रहता है; data में केवल Private Use Area संख्या बचती है, इसलिए gaiji PC छोड़ते ही टूटे दिखते हैं।

5.1. पहले से gaiji पा चुकी system का यथार्थ उत्तर

समस्या तब है जब legacy system से आए data में पहले से gaiji मिला हो। Migration कार्यों पर हम जो process सुझाते हैं वह निम्न है।

1. जाँचें: Database और files को Private Use Area (U+E000–U+F8FF) के regular expression से scan करें, और उपयोग में gaiji codes व उनकी गिनती list करें। प्रत्येक साइट के PC से eudc.tte इकट्ठा कर glyphs confirm करें
2. पहचानें: प्रत्येक gaiji के लिए जाँचें “regular Unicode character के रूप में represent हो सकता है”, “IVS से represent हो सकता है”, “Character Information Platform (MJ) में matching character है”, और substitute-character correspondence table बनाएँ। Practice में अधिकांश मामले केवल यह हैं कि पुराना रूप JIS gaiji के रूप में बना था
3. Replace करें: Correspondence table से data replace करें। केवल जब सचमुच matching character न हो, image के रूप में रखें या उस record से note जोड़ें
4. काटें: नई system में validation में Private Use Area input reject करें, और नया gaiji न बनाएँ

flowchart TB
    accTitle: Gaiji-युक्त data migrate करने की process
    accDescr: Private Use Area scan कर और eudc.tte इकट्ठा कर उपयोग में gaiji list करें, substitute-character correspondence table बनाएँ और replace करें, और नई system में validation में Private Use Area input reject करें और नया gaiji न बनाएँ
    st1["जाँचें: PUA scan"] --> st2["पहचानें: substitute table"]
    st2 --> st3["Table से replace करें"]
    st3 --> st4["काटें: कोई नया gaiji नहीं"]
    st1 -.-> tte["eudc.tte इकट्ठा करें"]
    st2 -.-> nomap["कोई map नहीं: image या note"]

चित्र 9: Gaiji को जाँचें, पहचानें, replace करें और काटें के चार चरणों में migrate करें, और नया gaiji न बनाएँ।

Government पक्ष पर दिशा वही है: municipalities के स्वयं बनाए gaiji (राष्ट्रव्यापी लगभग दो मिलियन characters कहे जाते हैं) को आगे प्रशासनिक मामलों के standard characters के विरुद्ध uniquely पहचानने, और उपयोग रोकने की policy कही गई है।¹⁰ “Gaiji न बढ़ाएँ; उन्हें standardized character set के विरुद्ध पहचानें” public और private दोनों क्षेत्रों में स्थापित migration pattern बन रहा है।

6. सरकारी character platform — koseki unified characters से प्रशासनिक मामलों के standard characters तक

व्यक्तिगत नाम सँभालने वाली system के design में, government-side character platform जानना “कितना स्वीकार करें” तय करने की सामग्री बनता है।

Municipality core-business systems (standard-conforming systems) में two-level structure standard spec में है: व्यक्तिगत नाम आदि के information interoperability के लिए प्रशासनिक मामलों के standard characters उपयोग करें, और बिना unified interoperability rules वाली बाहरी systems — smartphones आदि — से JIS X 0213:2012 के दायरे में interoperate करें।¹⁰ “अंदर चौड़ा character set रखें, और बाहर उस सीमा में आदान-प्रदान करें जो सामान्य environment display कर सके” की structure स्वयं private-sector systems के लिए भी संदर्भ है।

flowchart TB
    accTitle: Standard-conforming system का two-level interoperability
    accDescr: Municipality standard-conforming system व्यक्तिगत नाम आदि के information interoperability के लिए प्रशासनिक मामलों के standard characters उपयोग करती है, और बिना unified interoperability rules वाली smartphones जैसी बाहरी systems से JIS X 0213:2012 के दायरे में interoperate करती है
    sys["Municipality standard system"] --> renkei["नाम interoperability"]
    sys --> gaibu["बाहरी systems"]
    renkei --> mjp["प्रशासनिक standard characters"]
    mjp -.-> mjpN["व्यक्तिगत नाम आदि"]
    gaibu --> jis["JIS X 0213:2012 दायरा"]
    gaibu -.-> sumaho["कोई नियम नहीं （smartphones）"]
    mjp -.-> naibu["अंदर चौड़ा set रखा"]

चित्र 10: Two-level structure: सरकारी interoperability प्रशासनिक मामलों के standard characters उपयोग करता है; बिना नियमों वाला बाहरी interoperability JIS X 0213:2012 उपयोग करता है।

सामान्य business system के लिए practical guidance के रूप में हम निम्न सुझाते हैं।

• Accepted character set तय करें और उसे spec तथा input validation दोनों में कहें। उदाहरण “JIS X 0213:2012 का दायरा”, “Private Use Area और combining characters अनुमत नहीं”, “IVS स्वीकार नहीं (या स्वीकार है, पर display केवल IPAmj Mincho environment में guaranteed)”
• बिना सीमा स्वीकार न करें। “Unicode है, इसलिए कुछ भी चलेगा” design display, printing या interoperability में कहीं टूटेगा
• दायरे-बाहर characters का operations पहले तय करें। Alternative representation (नया रूप, katakana) replace करने का नियम और व्यक्ति को समझाए जाने वाले शब्द स्वयं system spec हैं
• जब government या finance जैसी downstream system का character-set नियम हो, उसे प्राधिकारी मानें और align करें

flowchart TB
    accTitle: Accepted character set design और operations
    accDescr: Accepted character set तय करें और उसे spec तथा input validation दोनों में कहें; दायरे में characters स्वीकार करें; दायरे-बाहर characters के लिए alternative representation replace करने के नियम और व्यक्ति को समझाए जाने वाले शब्दों सहित operations तय करें
    decide["Accepted character set तय करें"] --> spec["Spec में कहें"]
    decide --> valid["Input validation में कहें"]
    valid --> range{"दायरे में?"}
    range -->|हाँ| ok["स्वीकार करें"]
    range -->|नहीं| alt["Alternative representation replace करें"]
    alt -.-> word["व्यक्ति को समझाए जाने वाले शब्द भी spec हैं"]

चित्र 11: Accepted character set spec और input validation दोनों में कहें, और दायरे-बाहर operations भी तय करें।

7. Font चुनना और embed करना — screen और form align करना

7.1. सामान्य fonts का चरित्र

चुनाव में typeface पसंद से अधिक मायने यह है कि क्या वह font display, printing और PDF generation में शामिल हर environment में मौजूद है। Windows 10/11 पर Japanese supplemental fonts (BIZ UD आदि) configuration अनुसार कभी अनुपस्थित होते हैं, और server पक्ष पर PDF बनाने वाले configurations में server पर font की उपस्थिति या अनुपस्थिति का सीधा प्रभाव पड़ता है।

flowchart TB
    accTitle: Font चुनते समय confirm करने वाले environments
    accDescr: Font चुनने में typeface पसंद से अधिक मायने यह है कि क्या वह font display, printing और PDF generation में शामिल हर environment में मौजूद है; supplemental fonts का configuration और server पर font की उपस्थिति या अनुपस्थिति का सीधा प्रभाव पड़ता है
    cand["उम्मीदवार font"] --> exist["हर environment पर?"]
    exist --> scr["Display environment"]
    exist --> more{"Printing या PDF server?"}
    more --> prn["Printing environment"]
    more --> srv["PDF-generation server"]
    scr -.-> hojo["Supplemental fonts?"]
    hojo -.-> hojoN["अनुपस्थित हो सकता है"]
    srv -.-> eikyo["Server पर font मायने रखता है"]

चित्र 12: Font typeface पसंद से कम, display, printing और PDF generation के हर environment में उपस्थिति से अधिक चुनें।

7.2. Form design की बुनियाद — align करें, और embed करें

• Screen और form पर एक ही font specify करें। यदि fonts भिन्न हों, वही data भिन्न glyphs दिख सकता है, और आपको खुलती शिकायत मिलती है। “Screen पर Meiryo, form पर MS Mincho” जैसे configurations की कम से कम जाँच हो कि 168 JIS2004 characters पर glyph अंतर है या नहीं
• PDF में font embed करें। यदि embed न करें, देखने वाला पक्ष हाथ में font से substitute-rendering करता है, और न केवल glyph बल्कि layout बदल सकता है
• Embedding की अनुमति license तय करता है। OpenType font fsType field में embedding permissions declare करता है (Installable / Restricted / Preview & Print / Editable, no-subsetting आदि), और आप उस font को embed न करें जिसकी embedding license नहीं।¹¹ Commercial fonts के लिए contract confirm आवश्यक है
• Subset embedding base line बनाएँ। यदि केवल प्रयुक्त characters के glyphs embed करें, पूरे Japanese font (कई MB से दसियों MB) का बोझ नहीं लेना पड़ता
• यदि long-term-retention requirement हो, PDF/A। PDF/A (ISO 19005) वह standard है जो display के लिए आवश्यक resources file के अंदर पूरा करता है, और font embedding आवश्यक है।¹² “दस वर्ष बाद खोला और glyphs बदल गए” रोकने का सबसे विश्वसनीय तरीका भी है

flowchart TB
    accTitle: Font embedding का decision flow
    accDescr: PDF में font embed करने से पहले fsType embedding license confirm करें; यदि license हो, subset embedding base line बनाएँ; यदि long-term-retention requirement हो, PDF/A पर विचार करें, जो embedding माँगता है
    emb["PDF में font embed करें"] --> lic{"fsType से embedding license?"}
    lic -->|License है| sub["Subset embedding base line है"]
    lic -->|License नहीं| ng["Embed न करें"]
    sub -.-> gly["केवल प्रयुक्त characters के glyphs"]
    sub -->|Long-term-retention requirement| pdfa["PDF/A पर विचार करें"]
    pdfa -.-> must["Font embedding आवश्यक है"]

चित्र 13: Embedding fsType license confirm मानती है; subset embedding और PDF/A base line हैं।

Printing और PDF output के implementation means कैसे चुनें, “Windows business apps में printing और PDF output” में गहराई से cover है।

8. Font linking और fallback — “भिन्न font मिल जाता है” घटना

जिस character का specified font के पास glyph नहीं, वह कुछ नहीं दिखता नहीं; दूसरे font में substitute-rendering आधुनिक rendering stack का default behavior है। GDI में registry (FontLink\SystemLink) में defined “font linking” यह करता है; DirectWrite, WPF और browsers में “font fallback” करता है।¹⁵

flowchart TB
    accTitle: Font linking और fallback का प्रवाह
    accDescr: यदि specified font के पास glyph हो वह ज्यों-का-त्यों दिखता है; यदि न हो, link या fallback font में substitute-rendering होता है; यदि कहीं glyph न हो □ हो जाता है, पर data अक्सर अभी जीवित है
    disp["Character display करें"] --> has{"Specified font के पास glyph?"}
    has -->|हाँ| draw["Specified font में display करें"]
    has -->|नहीं| fb{"Link या fallback target में है?"}
    fb -->|हाँ| alt["दूसरे font में substitute-rendering"]
    alt -.-> mixed["Mixed typeface अनुभूति का कारण"]
    fb -->|नहीं| tofu["□ （tofu） display होता है"]
    tofu -.-> alive["Data अक्सर अभी जीवित है"]

चित्र 14: □ fallback failure का निशान है; substitute-rendering succeed हो या नहीं “mixed” और “tofu” का द्वार है।

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

• Latin और Japanese के बीच typeface अनुभूति भिन्न: क्योंकि Latin font पहले specified था, केवल Japanese भाग link या fallback Japanese font में खींचा जा रहा है
• Japanese वाक्य के केवल kanji Chinese-style glyphs हो जाते हैं: Fallback target Chinese font पर resolve हुआ। उन web pages या apps में आसान जहाँ language जानकारी (lang attribute या locale) सही नहीं जा रही
• Tofu (□) आता है: न specified font न fallback target के पास glyph। अर्थात् □ “fallback failure का निशान” है, और data अक्सर अभी जीवित है

Fallback राहत mechanism है; शुरुआत से सही font चुनने का विकल्प नहीं।¹⁵ Business app में स्वस्थ स्थिति है “मुख्य display और printing paths पर design किए fonts अकेले पूरे करें; fallback unexpected characters का बीमा है”। Multilingual UI में font चयन की सोच के लिए “WinForms/WPF app localization” भी देखें।

9. Business apps के लिए implementation checklist

अंत में, input से interoperability तक प्रत्येक layer पर confirm बिंदु table में सारांशित हैं।

Normalization विशेष रूप से वह जाल है जो इस लेख का विषय स्वयं है: “अच्छे इरादे से” लगाया process जो variant characters और fullwidth बनाम halfwidth का भेद कुचलती है। Original ज्यों-का-त्यों; copy पर processing सिद्धांत है। CSV interoperability में character-encoding accidents “CSV "केवल text" नहीं है” में गहराई से cover हैं।

flowchart TB
    accTitle: Original ज्यों-का-त्यों; copy पर processing
    accDescr: दर्ज string को original के रूप में ज्यों-का-त्यों save करें; search key बनाने जैसे उपयोग तक सीमित copy पर normalization लगाएँ; original पर NFKC लगाने से variant characters और fullwidth बनाम halfwidth का भेद खो जाता है
    input["दर्ज string"] --> orig["Original: जैसा दर्ज save करें"]
    input --> copy["Copy: उपयोग तक सीमित normalization"]
    copy -.-> use["Search key बनाना आदि"]
    orig -.-> ng["Original पर NFKC भेद कुचलता है"]

चित्र 15: Normalization को उपयोग तक सीमित कर copy पर लगाएँ; original जैसा दर्ज save करें।

10. सारांश

• Character-problem पहले “data layer (character encoding)” और “दिखावट layer (font)” में बाँटें। � data-layer accident का संकेत है, □ दिखावट-layer accident का।
• JIS X 0213:2004 ने 168 characters के example glyphs बदले, और Windows Vista से JIS2004 glyphs default रखता है। 葛, 辻 और 飴 का environment अनुसार अलग दिखना font का इतिहास है, data corruption नहीं।
• Glyph को data के रूप में स्थिर करने का standard means IVS है, पर बिना supporting font और supporting app default glyph पर गिरता है। Implementation प्रभाव न भूलें कि एक character चार UTF-16 code units तक हो सकता है।
• Gaiji (EUDC) उस PC-specific asset है और data के साथ नहीं जा सकता। यथार्थ उत्तर migration पर list बनाना, correspondence table से regular characters या IVS में replace करना, और नए बनाना रोकना है।
• व्यक्तिगत नाम सँभालने वाली system accepted character set तय करे और कहे। Government koseki unified characters और Character Information Platform की नींव पर प्रशासनिक मामलों के standard characters की ओर standardize कर रही है, और interoperate करने वाली system उस गति का अनुसरण करे।
• Forms और PDF के लिए “font को screen से align करें, license confirm करें, और embed करें” base line है। Long-term retention के लिए PDF/A पर विचार करें।
• NFKC normalization, code unit से slicing, और CP932 conversion वे तीन बिंदु हैं जो चुपचाप variant characters और gaiji तोड़ते हैं। Original save करना और grapheme units में processing सिद्धांत बनाएँ।

अगली बार जब कहा जाए “character भिन्न है”, पहले प्रश्न इस तरह पुनः ढालें। क्या code points एक हैं, या भिन्न? यदि एक हैं तो font समस्या है; यदि भिन्न हैं तो data समस्या है। वह एक चाल जाँच के गलत प्रवेश बिंदु से बचाती है।

flowchart TB
    accTitle: पहला प्रश्न जो जाँच का प्रवेश बिंदु तय करता है
    accDescr: जब कहा जाए character भिन्न है, पहले compare करें कि code points एक हैं या भिन्न; यदि एक हैं जाँच font समस्या के रूप में शुरू करें, यदि भिन्न हैं data समस्या के रूप में
    said["कहा गया character भिन्न है"] --> cmp{"क्या code points एक हैं?"}
    cmp -->|एक| fontp["Font समस्या"]
    cmp -->|भिन्न| datap["Data समस्या"]

चित्र 16: यदि code points एक हैं, जाँच font समस्या के रूप में शुरू करें; यदि भिन्न हैं, data समस्या के रूप में।

संबंधित लेख

• Windows text encoding का परिचय - Linux से integration पर होने वाला mojibake
• Windows text encoding और line endings - mojibake और CRLF/LF की बुनियाद
• Windows business apps में printing और PDF output — System.Drawing.Printing, WPF और report library के बीच चुनाव
• WinForms/WPF app localization — resx, satellite assemblies, और culture switch practice में
• CSV “केवल text” नहीं है: C# business apps में CSV सँभालने का practical guide (encoding, Excel compatibility, injection रक्षा)
• Windows app accessibility का परिचय — UI Automation और reasonable accommodation requirements की तैयारी

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

KomuraSoft LLC business systems में characters के इर्द-गिर्द design और जाँच सँभालता है। “Screen और form पर character भिन्न है” या “migration के बाद व्यक्तिगत नाम □ हो गया” जैसे लक्षणों का कारण अलग करने से, legacy system से migration पर gaiji list बनाना और substitute-character table बनाना, व्यक्तिगत नाम सँभालने वाली system का accepted character set design करना, और forms व PDF की font-embedding configuration review तक, हम code layer और font layer दोनों cover करते हैं।

• Windows app development
• Existing assets का reuse और migration
• Technical consulting और design review
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

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

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

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

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

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

यह mojibake से अधिक font glyph का अंतर है। JIS X 0213:2004 (JIS2004) ने 168 kanji के example glyphs printing-standard forms में संशोधित किए, और Windows ने भी Vista से MS Gothic / MS Mincho आदि में JIS2004 glyphs default किए। 葛, 辻, 飴 जैसे representative उदाहरण हैं: Unicode code point (data) वही रहता है, और केवल font का glyph (दिखावट) बदला है। Data comparison match खाती है; XP-era form image और नए PC की screen के आकार का mismatch specified behavior है। यदि glyphs भी align चाहें, screen और form पर एक ही font उपयोग करें, या Ideographic Variation Selector से glyph specify करें।

यदि Ideographic Variation Selector (IVS) उपयोग करें, क्या हर personal-name glyph problem हल होती है?

नहीं। IVS वह mechanism है जो base character के तुरंत बाद U+E0100 से selector रखकर glyph data के रूप में specify करता है, और specified glyph तभी दिखता है जब IPAmj Mincho जैसा supporting font और supporting app दोनों हों। Unsupported environment में specified behavior यह है कि selector ignore हो और base character का default glyph दिखे; कुछ environments में selector □ भी दिख सकता है। आगे, एक IVS-युक्त character UTF-16 में चार code units तक हो सकता है, जो character-count, slicing और DB column length के design को प्रभावित करता है। यदि लाएँ, display, printing और downstream systems से support का दायरा confirm कर उपयोग करें।

Gaiji (EUDC) के रूप में registered character दूसरे PC या PDF में दिख सकता है?

सिद्धांततः नहीं। Gaiji वह mechanism है जिसमें user उस PC की eudc.tte file में Unicode Private Use Area (U+E000 से) के code points पर glyph register करता है; वही code point दूसरे PC पर undefined या भिन्न glyph है। Mail, PDF या दूसरी system को सौंपने का भाग्य इसलिए □ होना या भिन्न character दिखना है। यदि gaiji-युक्त legacy data पहले से है, migration पर यथार्थ path Private Use Area के उपयोगों की list बनाना, regular Unicode characters या Ideographic Variation Selectors से correspondence table बनाना, और replace करना है। नई system में नया gaiji बनाना टालें।

Business system व्यक्तिगत नामों में characters कितना स्वीकार करे?

पहली बात "accepted character set तय कर spec के रूप में कहना" है। Family registers में लगभग 56,000 koseki unified characters हैं, और government-standard conforming systems प्रशासनिक मामलों के standard characters की ओर बढ़ रही हैं — Character Information Platform का विस्तार — पर सामान्य business system उसी स्तर को बिना सीमा स्वीकार करने को बाध्य नहीं। यथार्थ design है "JIS X 0213 के दायरे तक" या "Ideographic Variation Selector या Private Use Area स्वीकार न करें" जैसी सीमा तय करना, input पर validate करना, और दायरे-बाहर मामलों को warning या alternative representation से चलाना। केवल वे systems जो government या municipalities से interoperate करती हैं प्रशासनिक मामलों के standard characters और JIS X 0221-based interoperability requirements का अनुसरण करें।

Form या PDF screen जैसे ही characters कैसे दिखाए?

Base line screen और form पर एक ही font specify करना, और PDF में font embed करना है। यदि fonts भिन्न हों, वही data glyph बदल सकता है; यदि देखने वाले PC के पास font न हो, substitute font से rendering होता है और दिखावट टूटती है। Embedding की अनुमति font के license (OpenType fsType) से तय होती है, इसलिए confirm करें — report library पर न छोड़ें। Subset embedding, जो केवल प्रयुक्त characters embed करती है, file size भी घटाती है। यदि long-term retention requirement हो, PDF/A पर विचार करें, जो font embedding माँगता है।

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

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

Go Komura

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

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