מלכודות גופנים ותווים יפניים — JIS2004, IVS ו-gaiji באפליקציות עסקיות

“השם זהה, אבל צורת התו שונה בין המסך לטופס המודפס.” “אחרי שהחלפנו את המחשב, תו שהוצג בעבר הפך ל-□.” מערכות עסקיות שמטפלות ביפנית מושכות פניות כאלה.

הדבר הראשון לבדוק הוא אם נתוני התו השתנו, או שרק המראה של אותם נתונים השתנה. אם מנסים לתקן את זה כ-“mojibake” בלי להפריד בין השניים, נכנסים לחקירה מהדלת הלא נכונה.

המאמר יוצא משתי פניות: 葛 ברשימת לקוחות שנראה שונה במסך ובטופס המודפס, ושם במסמך שמוגש למשרד ממשלתי שאחרי החלפת מחשב כבר לא היה אפשר להציג.

אף אחת משתי הפניות האלה אינה ה-mojibake שאי-התאמת קידוד גורמת. בראשונה אף ביט בנתונים לא השתנה ורק המראה השתנה; בשנייה, “gaiji” (תו שמשתמש הקצה מגדיר) שהתקיים רק על אותו מחשב אבד.

flowchart TB
    accTitle: מה שתי הפניות הנפוצות באמת
    accDescr: הפנייה ש-葛 נראה שונה במסך ובטופס המודפס היא מקרה שבו רק המראה השתנה והנתונים נשארו זהים, הפנייה שתו הפך ל-□ אחרי החלפת מחשב היא מקרה שבו gaiji שהתקיים רק על אותו מחשב אבד, ושניהם בעיה שונה מ-mojibake של אי-התאמת קידוד
    c1["פנייה 1: הצורה שונה במסך ובטופס"] --> r1["הנתונים לא השתנו; רק המראה השתנה"]
    c2["פנייה 2: הפך ל-□ אחרי שהמחשב הוחלף"] --> r2["gaiji שהתקיים רק על אותו מחשב אבד"]
    r1 --> diff["בעיה שונה מ-mojibake של קידוד"]
    r2 --> diff

איור 1: שתי הפניות שנוטות להיקרא “mojibake” שתיהן בעיה שונה מאי-התאמת קידוד.

מפרידים את קוד התו (שכבת הנתונים) מהגופן (שכבת המראה), ורוב בעיות התווים היפניים נהיות ניתנות לטיפול. המאמר הזה כתוב למפתחי מערכות עסקיות ולאנשי IT, ועובר בסדר מבידוד הסימפטום, דרך איך JIS2004, IVS ו-gaiji עובדים, עד טווח התווים לקבל ועיצוב טפסים מודפסים ו-PDF.

השיבוש שקורה בהמרה בין Shift_JIS ל-UTF-8 מכוסה במאמרים קיימים, לכן המאמר הזה מתרכז בבעיה שבה הקודים עושים הלוך-חזור נכון אבל המראה, או האם התו ניתן להצגה בכלל, סוטה.

1. קודם המסקנה

“איזה רצף בתים לשמור” היא שאלת עיצוב נתונים; “איך זה נראה” היא שאלת עיצוב גופן. כשמחליטים איך להגיב, מפרידים את שלושת הדברים הבאים.

קודם מאשרים אם הנתונים זהים

“Mojibake” היא בעיית שכבת נתונים: רצף בתים שמפורש לא נכון. לעומת זאת, אותו code point של Unicode יכול לקבל glyph שונה בגופן אחר. JIS2004 שינה את ה-glyphs לדוגמה של 168 תווים, כולל 葛, 辻, 飴, ומ-Vista ואילך glyphs של JIS2004 הם ברירת המחדל ב-MS Gothic ו-MS Mincho של Windows.¹²

לא מערבבים בין ציון glyph לבין העברת gaiji

IVS הוא האמצעי הסטנדרטי לציין glyph כנתון. הוא צריך גופן תומך ואפליקציה תומכת, אבל בסביבה בלי אלה ההתנהגות הנכונה היא להתעלם מה-selector ולהציג את glyph ברירת המחדל של תו הבסיס. כי מה שנראה כתו אחד יכול להיות עד ארבע יחידות קוד UTF-16, זה משפיע לא רק על תצוגה אלא גם על ספירת תווים וחילוץ מחרוזות משנה.³⁴

Gaiji (EUDC, תווים שמשתמש הקצה מגדיר) הם עניין נפרד: למספר ב-Private Use Area אין משמעות משותפת בכל העולם. ה-glyph ב-eudc.tte לא נוסע אל הצד השני יחד עם הנתונים, ולכן מעבר דורש סקר ומיפוי לתווים חלופיים.⁵⁶

כותבים במפרט את התווים שמתקבלים ואת סביבת הפלט

מערכת שמטפלת בשמות אנשים מחליטה על ערכת התווים שהיא מקבלת ומציינת אותה במפורש. במקום שהמערכת מתממשקת עם הממשל, גם עוקבים אחרי התווים הסטנדרטיים לעניינים מנהליים, שנבנים על תווי Koseki מאוחדים ועל Character Information Platform.⁷⁸⁹ לטפסים מודפסים ול-PDF, הבסיס הוא להשתמש באותו גופן כמו המסך, לאשר את הרישיון, ולהטמיע את הגופן. לשמירה ארוכת טווח, שוקלים PDF/A.¹⁰¹¹

גם, לא מפעילים NFKC normalization בקלות על המקור של שם אדם. החלפת צורות fullwidth ו-halfwidth ותווי compatibility מאבדת הבחנות שצריך לשמור.¹²

בוחרים מאיפה לקרוא לפי הסימפטום או המטרה

כדי להבין את התמונה המלאה, קוראים מפרק 2 בסדר; כדי לחקור את הסימפטום שלפניכם, מתחילים מהסעיף הרלוונטי בטבלה. כשמממשים אמצעי נגד, בודקים את ההשפעה על השכבות האחרות בפרק 9 בסוף.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 14, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מפרידים נתונים ממראה — code points ו-glyphs

המספר והצורה שמצוירת הם דברים שונים

ב-Unicode, תו מיוצג במספר שנקרא code point. 葛 הוא U+845B, והמספר הזה זהה בכל מחשב.

איך המספר הזה מצויר על מסך או על נייר, לעומת זאת, נקבע לפי ה-glyph שהגופן מחזיק. זה נורמלי שאותו U+845B ייבדל בפרטי הצורה בין גופן A לגופן B.

מפרידים את שכבת החקירה לפי הסימפטום

עם שתי השכבות האלה כהנחה, הסימפטומים שפוגשים בשטח אפשר לפצל כך.

כסימן לפיצול, כדאי לזכור את ההבדל בין “�” ל-“□”.

“�” הוא עקבות של המרה שנכשלה. ברגע שהוחלף ב-U+FFFD (REPLACEMENT CHARACTER), התו המקורי כבר אבד. חוקרים את שכבת הנתונים.

“□” הוא, ברוב המקרים, תצוגה של “glyph לא נמצא”. אם הנתונים עדיין שם והגופן רק חסר glyph, החלפת הגופן עשויה לאפשר תצוגה. חוקרים את שכבת המראה.

flowchart TB
    accTitle: פיצול הסימפטום לפי � מול □
    accDescr: כשתו לא מוצג נכון, � הוא עקבות של כשל המרה בשכבת הנתונים שבו התו המקורי אבד, בעוד □ אומר רק שהנתונים עדיין שם אבל לגופן אין glyph, והחלפת הגופן עשויה לאפשר תצוגה
    symptom["תו לא מוצג נכון"] --> which{"מה רואים?"}
    which -->|� נראה| datalayer["כשל בשכבת הנתונים"]
    datalayer -.-> lost["עקבות של המרה שנכשלה (התו המקורי אבד)"]
    which -->|□ נראה| viewlayer["כשל בשכבת המראה"]
    viewlayer -.-> noglyph["הגופן רק חסר glyph"]
    noglyph --> fixable["החלפת הגופן עשויה לאפשר תצוגה"]

איור 2: � מסמן כשל בשכבת הנתונים ו-□ כשל בשכבת המראה, ונקודת הכניסה לחקירה משתנה בהתאם.

יסודות הקידוד עצמם (CP932 ו-UTF-8, BOM, סופי שורה) מכוסים ב-“מבוא לקידודי טקסט ב-Windows - ה-mojibake שקורה באינטגרציה עם Linux” וב-“קידודי טקסט וסופי שורה ב-Windows - יסודות mojibake ו-CRLF/LF”. מכאן ואילך הנושא הוא שכבת המראה והבעיות שקורות בגבול שלה.

3. מ-JIS90 ל-JIS2004 — ה-glyph השתנה, הקוד נשאר

הסיבה האמיתית מאחורי הפתיחה “葛 נראה שונה במסך ובטופס” נמצאת, ברוב המקרים, כאן.

מה השתנה: glyphs ברירת המחדל של הגופן

בעקבות Hyogai Kanji Jitaihyo (טבלת צורות ל-kanji מחוץ לרשימת Joyo) שדיווחה המועצה הלאומית לשפה ב-2000, התיקון מ-2004 JIS X 0213:2004 (המכונה בדרך כלל JIS2004) שינה את ה-glyphs לדוגמה של 168 kanji לצורות תקן הדפוס, שקרובות לצורות מילון Kangxi. 葛, 辻, 飴, 芦, 溢, 餅 הם דוגמאות מייצגות.¹

Windows הלך בעקבותיהם והפך את glyphs של JIS2004 לברירת המחדל ב-MS Gothic ו-MS Mincho (וב-Meiryo שהוצג אז) מ-Windows Vista ואילך. גם MS Gothic הנוכחי מחזיק glyphs ברירת מחדל מבוססי JIS2004, ואת ה-glyphs מתקופת JIS90 אפשר להגיע אליהם דרך ה-feature jp90 של OpenType.²¹

flowchart TB
    accTitle: איך ה-glyphs של MS Gothic הנוכחי מאורגנים
    accDescr: ל-MS Gothic מ-Vista ואילך יש את glyphs של JIS2004 כברירת מחדל, ואת ה-glyphs מתקופת JIS90 אפשר להגיע אליהם דרך ה-feature jp90 של OpenType
    msg["MS Gothic (מ-Vista ואילך)"] --> def["glyphs ברירת מחדל: מבוססי JIS2004"]
    msg --> feat["דרך ה-feature jp90"]
    feat --> old["glyphs מתקופת JIS90"]

איור 3: MS Gothic הנוכחי ברירת המחדל שלו היא glyphs של JIS2004, ואפשר לעבור ל-glyphs של JIS90 עם ה-feature jp90.

מה לא השתנה: ה-code point של התו

מה שחשוב כאן הוא שרק הגופן השתנה; הנתונים לא השתנו בכלל.

• ה-code point של 葛 הוא U+845B גם ב-XP וגם ב-Windows 11
• XP (glyphs של JIS90) מציג את הצורה שבה פנים ה-勹 מפושטים ל-ヒ; מ-Vista ואילך (glyphs של JIS2004) מוצגת הצורה שכותבת גם 人 בפנים
• לכן תמונה סרוקה של טופס שהמערכת הישנה הדפיסה ומסך המחשב החדש לא מסכימים על צורת התו. השוואת הנתונים תואמת לגמרי

האם ל-radical shinnyo של 辻 יש נקודה אחת או שתיים, וצורת radical האוכל ב-飴, הם אותו סוג של דבר. בלי לדעת את ההיסטוריה הזאת, חקירה נוטה ללכת לכיוון הלא נכון: “המעבר השחית את הנתונים”.

סדר החקירה הוא: משווים את ה-code points לפני ואחרי המעבר → אם הם תואמים, חושדים בהבדל glyph בין גופנים. לא מסיקים שהנתונים מושחתים רק כי זה נראה שונה.

flowchart TB
    accTitle: אותו code point, glyph שונה לפי הגופן
    accDescr: ה-code point U+845B של 葛 נשאר זהה ב-XP וב-Windows 11 כאחד, רק הצורה המוצגת נבדלת בין גופן עם glyphs של JIS90 לגופן עם glyphs של JIS2004, והשוואת הנתונים תואמת לגמרי
    cp["code point U+845B של 葛"] --> f90["גופן עם glyphs של JIS90 (XP)"]
    cp --> f04["גופן עם glyphs של JIS2004 (מ-Vista ואילך)"]
    f90 --> g90["צורה שבה פנים ה-勹 מפושטים ל-ヒ"]
    f04 --> g04["צורת תקן הדפוס שכותבת 人 בפנים"]
    g90 -.-> same["השוואת הנתונים תואמת לגמרי"]
    g04 -.-> same

איור 4: רק הגופן השתנה; ה-code point U+845B נשאר זהה בכל סביבה.

שימו לב שכי התו עצמו לא השתנה, שני ה-glyphs הם “אותו תו”. בשמות אנשים, לעומת זאת, האדם או המשרד הממשלתי לפעמים מתעקשים על צורה מסוימת, והמענה לדרישה להבחין בזה “כנתונים” הוא העבודה של הנושא הבא, IVS.

4. Ideographic Variation Selectors (IVS) — ציון glyph כנתון

הפרק הזה מסתכל בנפרד על המנגנון שמציין glyph, התנאים שבהם אפשר להציג אותו, וההשפעה על המימוש.

IVS (Ideographic Variation Sequence) הוא מנגנון שמניח code point בלתי-נראה שנקרא “ideographic variation selector” מיד אחרי kanji כדי לציין וריאנט glyph כנתון. ה-selectors שבשימוש הם U+E0100 עד U+E01EF (VS17 עד VS256).³

המיפוי של ה-glyph נקבע ברישום IVD

איזה רצף “תו בסיס + selector” מתייחס לאיזה glyph נקבע ברישום שנקרא IVD (Ideographic Variation Database), שמנוהל בידי Unicode Consortium.

האוספים העיקריים הם כדלקמן.¹³

למשל, התיעוד של Microsoft נותן את U+845B לבד (葛) כצורה שבשימוש בשם תחנת Nishi-Kasai, ואת U+845B ואחריו U+E0100 (VS17) כצורה שבשימוש בשם העיר Katsuragi במחוז Nara. אותו 葛, ובכל זאת הנתונים יכולים לומר איזה glyph הכוונה.³

flowchart TB
    accTitle: דוגמה להבחנה של אותו 葛 כנתון עם IVS
    accDescr: 葛 כ-U+845B לבד משמש בשם תחנת Nishi-Kasai, הרצף של U+845B ואחריו VS17 משמש בשם העיר Katsuragi, ואיזה רצף מתייחס לאיזה glyph נקבע ברישום IVD
    seq1["U+845B לבד"] --> gl1["Glyph שבשימוש בשם תחנת Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["Glyph שבשימוש בשם העיר Katsuragi"]
    ivd["IVD (רישום)"] -.-> gl1
    ivd -.-> gl2

איור 5: גם לאותו 葛, נוכחות או היעדר selector מאפשרים לנתונים לומר איזה glyph הכוונה.

4.1. התנהגות בסביבה שאינה תומכת

בצד הגופן, המיפוי בין IVS ל-glyph ממומש בטבלת cmap של OpenType (format 14).⁴ כשגופן תומך (כמו IPAmj Mincho) ואפליקציה תומכת שניהם נוכחים, ה-glyph שצוין מופיע.

כשהם לא, ה-glyph שצוין אינו מובטח לשרוד. מפרידים את שני המקרים הבאים.

• ההתנהגות הנכונה לפי המפרט: ה-selector מתעלמים ממנו ומוצג glyph ברירת המחדל של תו הבסיס (ה-selector עצמו בלתי-נראה)
• אפליקציות ישנות וחלק מ-rendering stacks: ה-selector מטופל כתו לא-ידוע עצמאי, ו-□ נוסף מוצג

במילים אחרות, IVS מתוכנן כך ש”גם כשהוא יורד באיכות, תו הבסיס נשאר קריא”, אבל האם “תמיד מוצג ב-glyph שצוין” תלוי בסביבת הקבלה.

מערכות מרשם תושבים ומרשם משפחה ממשלתיות משתמשות בשילוב של גופן Character Information Platform ועוד IVS, אבל אם מערכת עסקית כללית מקבלת את זה בקלות, ה-glyph נושר איפשהו לאורך תצוגה, הדפסה או מערכת במורד הזרם.

flowchart TB
    accTitle: איך נתונים עם IVS מוצגים
    accDescr: כשגופן תומך ואפליקציה תומכת שניהם נוכחים זה מוצג ב-glyph שצוין, כשהם לא ה-selector מתעלמים ממנו ומוצג glyph ברירת המחדל של תו הבסיס, ובאפליקציות ישנות ובחלק מ-rendering stacks ה-selector מטופל כתו לא-ידוע ו-□ נוסף מוצג
    ivs["תו בסיס + ideographic variation selector"] --> env{"גופן תומך ואפליקציה שניהם נוכחים?"}
    env -->|כן| ok["מוצג ב-glyph שצוין"]
    env -->|לא| ignore["ה-selector מתעלמים ממנו; glyph ברירת מחדל מוצג"]
    env -->|אפליקציות ישנות או חלק מ-rendering stacks| tofu["□ נוסף מוצג"]
    ignore -.-> spec["זו ההתנהגות הנכונה לפי המפרט"]

איור 6: IVS נשאר קריא כתו הבסיס גם כשהוא יורד באיכות, אבל האם ה-glyph שצוין מופיע תלוי בסביבת הקבלה.

4.2. נקודות במימוש — “תו אחד” יכול להיות עד ארבע יחידות קוד

Selectors של IVS מ-U+E0100 ואילך הם code points של supplementary plane, ולכן ב-UTF-16 הם תמיד surrogate pair (שתי יחידות קוד). אם תו הבסיס עצמו הוא kanji של supplementary plane (למשל 𠮟 (U+20B9F), שנוסף ב-JIS2004), הבסיס לבדו הוא שתי יחידות קוד, והרצף שמשתמש תופס כ”תו אחד” הוא עד ארבע יחידות קוד ב-UTF-16 ועד שמונה בתים ב-UTF-8.

ספירת תווים ומחרוזות משנה: לא חותכים את התו הנראה

ב-C#, "葛󠄀" (葛 + VS17) מקבל string.Length == 3. Substring וחיתוך באורך קבוע מסכנים הפרדה של תו הבסיס מה-selector שלו.

מאמתים ספירת תווים ומחלצים מחרוזות משנה ביחידות grapheme, עם APIs כמו StringInfo, לא ביחידות קוד.

אחסון: בודקים את יחידת אורך העמודה

nvarchar(n) של SQL Server נמדד ביחידות קוד UTF-16. אם מקבלים IVS, מתכננים אורכי עמודות DB פי שניים עד ארבעה מספירת התווים הנראית.

חיפוש והשוואה: מחליטים אם selectors מובחנים

נוכחות או היעדר selector יוצרים מחרוזת שונה. האם חיפוש של “葛” צריך לפגוע ב-“葛 + VS17” זה משהו שצריך להחליט כדרישה ולממש.

flowchart TB
    accTitle: תו אחד עם IVS ויחידות קוד UTF-16
    accDescr: הרצף של תו בסיס ו-ideographic variation selector שמשתמש תופס כתו אחד כולל selector שהוא תמיד surrogate pair, ועוד שתי יחידות קוד אם תו הבסיס הוא kanji של supplementary plane, עד ארבע יחידות קוד ב-UTF-16
    one["תו אחד כפי שהמשתמש תופס אותו"] --> base["תו בסיס"]
    one --> vs["ideographic variation selector"]
    base -.-> bnote["שתי יחידות קוד אם זה kanji של supplementary plane"]
    vs -.-> vnote["תמיד surrogate pair (שתי יחידות קוד)"]
    base --> total["עד ארבע יחידות קוד ב-UTF-16"]
    vs --> total
    total -.-> risk["חיתוך באורך קבוע מסכן פיצול שלהם"]

איור 7: תו אחד עם IVS יכול להיות עד ארבע יחידות קוד UTF-16, לכן חיתוך לפי יחידת קוד מסוכן.

5. Gaiji (EUDC) — תווים שמוצגים רק על אותו מחשב

Gaiji הם מנגנון שבו משתמש מקצה glyph משלו ל-code point ב-Private Use Area של Unicode (PUA: U+E000 עד U+F8FF וטווחים אחרים). ל-code point ב-Private Use Area אין משמעות משותפת בכל העולם; אותו U+E000 יכול לקבל תו אחר בכל מחשב ובכל ארגון.⁵

ה-glyph חי בגופן ה-gaiji; בנתונים נשאר רק המספר

ב-Windows יוצרים את ה-glyph ב-Private Character Editor (eudcedit.exe), והוא נשמר בקובץ גופן שנקרא eudc.tte.

הקובץ הזה מותקן כגופן מוסתר ומשויך לכל גופן דרך מפתח הרישום HKEY_CURRENT_USER\EUDC.⁶ בעידן Shift_JIS (CP932) טווח ה-gaiji היה 0xF040 עד 0xF9FC, והמרה ל-Unicode ממפה אותו ל-Private Use Area.

מספר בנתונים לא אומר שלצד השני יש את אותו glyph. המנגנון הזה מוליד את הבעיות הבאות.

• eudc.tte שייך לאותו מחשב (לאותו משתמש) ואינו נוסע אל הצד השני יחד עם הנתונים
• ברגע שהנתונים מגיעים לדואר, ל-PDF, לאינטרנט או למערכת אחרת, התו הופך ל-□ או נראה כמו gaiji אחר בצד השני
• אם שוכחים להעביר את eudc.tte במעבר OS או בהחלפת מחשב, קורה “תו שהוצג במחשב הישן כבר לא מוצג”

זו הסיבה האמיתית מאחורי הפנייה השנייה בפתיחה.

flowchart TB
    accTitle: למה gaiji מוצגים רק על אותו מחשב
    accDescr: glyph שנוצר ב-Private Character Editor נשמר ב-eudc.tte ומשויך לגופנים דרך הרישום של אותו מחשב, לכן כשרק קוד ה-Private Use Area נוסע לדואר, ל-PDF או למערכת אחרת, הוא הופך ל-□ או נראה כתו אחר
    edit["יוצרים את ה-glyph ב-Private Character Editor"] --> tte["נשמר ב-eudc.tte"]
    tte --> reg["משויך לגופנים דרך הרישום"]
    reg --> local["מוצג על אותו מחשב"]
    tte -.-> stay["eudc.tte לא נוסע עם הנתונים"]
    send["רק קוד ה-Private Use Area מגיע לצד השני"] --> dest["דואר, PDF, מערכות אחרות"]
    dest --> broken["הופך ל-□ או נראה כתו אחר"]

איור 8: ה-glyph חי ב-eudc.tte ורק מספר Private Use Area נשאר בנתונים, לכן gaiji נראים שבורים ברגע שהם יוצאים מהמחשב.

5.1. תשובה מציאותית למערכת שכבר קיבלה gaiji

הבעיה היא כשנתונים שעברו בירושה ממערכת legacy כבר מכילים gaiji. מה שאנחנו ממליצים בפרויקטי מעבר הוא הליך בארבעה שלבים: סקר → זיהוי → החלפה → חסימה.

1. סקר: אוספים את המספרים שבשימוש ואת ה-glyphs המקוריים

סורקים מסדי נתונים וקבצים עם ביטוי רגולרי ל-Private Use Area (U+E000 עד U+F8FF) וממפים את קודי ה-gaiji שבשימוש ואת הספירות שלהם. אוספים eudc.tte מהמחשבים בכל אתר ובודקים את ה-glyphs.

2. זיהוי: בונים טבלת מיפוי לתווים חלופיים

לכל gaiji בודקים אם אפשר לייצג אותו בתו Unicode רגיל, אם אפשר לייצג אותו עם IVS, ואם ל-Character Information Platform (MJ) יש תו תואם, ובונים טבלת מיפוי לתווים חלופיים. בפועל, רוב המקרים מתבררים כלא יותר מצורת תו ישנה שנוצרה כ-gaiji של JIS.

3. החלפה: מחליפים את הנתונים לפי הטבלה

מחליפים את הנתונים לפי טבלת המיפוי. רק כשאין תו תואם בכלל, שומרים את התו כתמונה או מצרפים הערה לרשומה הנוגעת בדבר.

4. חסימה: לא מוסיפים gaiji חדשים

במערכת החדשה, דוחים קלט Private Use Area באימות ולא יוצרים gaiji חדשים.

flowchart TB
    accTitle: הליך מעבר לנתונים שמכילים gaiji
    accDescr: ממפים את ה-gaiji שבשימוש בסריקת Private Use Area ובאיסוף eudc.tte, בונים טבלת מיפוי לתווים חלופיים ומחליפים, ובמערכת החדשה דוחים קלט Private Use Area באימות ולא יוצרים gaiji חדשים
    st1["סקר: סורקים את ה-Private Use Area"] --> st2["זיהוי: בונים את טבלת המיפוי לתווים חלופיים"]
    st2 --> st3["החלפה: מחליפים לפי הטבלה"]
    st3 --> st4["חסימה: לא יוצרים gaiji חדשים"]
    st1 -.-> tte["אוספים eudc.tte מכל אתר"]
    st2 -.-> nomap["תמונה או הערה רק במקום שאין מיפוי"]

איור 9: מעבירים gaiji בארבעה שלבים, סקר, זיהוי, החלפה וחסימה, ולא יוצרים gaiji חדשים.

הכיוון זהה גם בצד הממשל: המדיניות המוצהרת היא לזהות באופן ייחודי את ה-gaiji שרשויות מקומיות יצרו בעצמן (נאמר שמספרם כשני מיליון תווים ברחבי המדינה) מול התווים הסטנדרטיים לעניינים מנהליים שמתוארים בהמשך, ולהפסיק להשתמש בהם.⁹ “לא להוסיף gaiji; לזהות אותם מול ערכת תווים סטנדרטית” הופך לדפוס המעבר המבוסס גם במגזר הציבורי וגם בפרטי.

6. תשתית התווים של הממשל — מתווי Koseki מאוחדים לתווים סטנדרטיים לעניינים מנהליים

כשמתכננים מערכת שמטפלת בשמות אנשים, ידיעת תשתית התווים של הממשל נותנת חומר להחלטה “עד כמה לקבל”.

קודם מפרידים שמות ותפקידים של תשתיות התווים

מפרידים החלפה בתוך הממשל מהחלפה מול החוץ הכללי

למערכות ליבה עירוניות (מערכות שתואמות לתקן), המפרט הסטנדרטי הוא סידור דו-שכבתי: משתמשים בתווים הסטנדרטיים לעניינים מנהליים להחלפת מידע של שמות וכדומה, ומחליפים בטווח JIS X 0213:2012 עם מערכות חיצוניות שאין להן כללי החלפה מאוחדים, כמו סמארטפונים.⁹

הסידור הזה, “מחזיקים ערכת תווים רחבה בפנים ומחליפים עם החוץ בטווח שסביבה כללית יכולה להציג”, הוא עצמו ייחוס שימושי למערכות במגזר הפרטי.

flowchart TB
    accTitle: ההחלפה הדו-שכבתית של מערכת שתואמת לתקן
    accDescr: מערכת עירונית שתואמת לתקן משתמשת בתווים הסטנדרטיים לעניינים מנהליים להחלפת מידע של שמות וכדומה, ומחליפה בטווח JIS X 0213:2012 עם מערכות חיצוניות כמו סמארטפונים שאין להן כללי החלפה מאוחדים
    sys["מערכת עירונית שתואמת לתקן"] --> renkei["החלפת מידע של שמות וכדומה"]
    sys --> gaibu["החלפה עם מערכות חיצוניות"]
    renkei --> mjp["תווים סטנדרטיים לעניינים מנהליים"]
    gaibu --> jis["טווח JIS X 0213:2012"]
    gaibu -.-> sumaho["צדדים שאין להם כללים, כמו סמארטפונים"]
    mjp -.-> naibu["ערכת תווים רחבה מוחזקת בפנים"]

איור 10: סידור דו-שכבתי: החלפה ממשלתית משתמשת בתווים הסטנדרטיים לעניינים מנהליים, והחלפה חיצונית בלי כללים משתמשת ב-JIS X 0213:2012.

מחליטים על הטווח שהמערכת שלכם מקבלת

כהנחיה מעשית למערכת עסקית כללית, אנחנו ממליצים על הבאים.

• מחליטים על ערכת התווים שמתקבלת ומציינים אותה גם במפרט וגם באימות הקלט. למשל, “טווח JIS X 0213:2012”, “בלי Private Use Area ובלי combining characters”, או “IVS לא מתקבל (או מתקבל, עם תצוגה מובטחת רק בסביבת IPAmj Mincho)”
• לא מקבלים בלי גבול. תכנון של “זה Unicode, אז הכול עובר” יישבר איפשהו לאורך תצוגה, הדפסה או אינטגרציה
• מחליטים מראש איך מטפלים בתווים מחוץ לטווח. הכלל להחלפה בייצוג חלופי (צורה בסגנון חדש או katakana) והניסוח שבו מסבירים את זה לאדם הם חלק ממפרט המערכת
• במקום שלצד במורד הזרם כמו סוכנות ממשלתית או מוסד פיננסי יש כללי ערכת תווים, מתייחסים אליהם כסמכות ומתאימים אליהם

flowchart TB
    accTitle: תכנון והפעלה של ערכת התווים שמתקבלת
    accDescr: מחליטים על ערכת התווים שמתקבלת ומציינים אותה גם במפרט וגם באימות הקלט, מקבלים תווים בטווח, ולתווים מחוץ לטווח מחליטים על ההפעלה מראש, כולל הכלל להחלפה בייצוג חלופי והניסוח שבו מסבירים את זה לאדם
    decide["מחליטים על ערכת התווים שמתקבלת"] --> spec["מציינים אותה במפרט"]
    decide --> valid["מציינים אותה באימות הקלט"]
    valid --> range{"בטווח?"}
    range -->|כן| ok["מקבלים"]
    range -->|לא| alt["מחליפים בייצוג חלופי"]
    alt -.-> word["גם הניסוח שמוסבר לאדם הוא חלק מהמפרט"]

איור 11: מציינים את ערכת התווים שמתקבלת גם במפרט וגם באימות הקלט, ומחליטים גם על הטיפול בתווים מחוץ לטווח.

7. בחירת גופנים והטמעה — יישור המסך והטופס המודפס

כאן סדר החשיבה הוא: מאשרים שהגופן קיים בסביבות שבהן משתמשים → משתמשים באותו גופן במסך ובטופס → מאשרים את הרישיון ומטמיעים אותו ב-PDF.

7.1. האופי של הגופנים הסטנדרטיים

בודקים את הסביבות שבשימוש, לא רק את שם הגופן

מה שחשוב בבחירה אינו העדפת typeface אלא האם הגופן קיים בכל סביבה שמעורבת בתצוגה, בהדפסה ובייצור PDF.

גופני ההשלמה היפניים ב-Windows 10/11 (BIZ UD ואחרים) עשויים לא להיות מותקנים לפי התצורה, ובתצורה שמייצרת PDF בצד השרת, נוכחות הגופן בשרת משפיעה ישירות.

flowchart TB
    accTitle: הסביבות לבדוק כשבוחרים גופן
    accDescr: כשבוחרים גופן, מה שחשוב אינו העדפת typeface אלא האם הגופן קיים בכל סביבה שמעורבת בתצוגה, בהדפסה ובייצור PDF, ותצורת גופני ההשלמה והאם הגופן נוכח בשרת משפיעים ישירות
    cand["גופן מועמד"] --> exist["נוכח בכל סביבה?"]
    exist --> scr["סביבת תצוגה"]
    exist --> prn["סביבת הדפסה"]
    exist --> srv["שרת ייצור PDF"]
    scr -.-> hojo["גופני השלמה עשויים להיעדר לפי התצורה"]
    srv -.-> eikyo["נוכחות הגופן בשרת משפיעה ישירות"]

איור 12: בוחרים גופן לא לפי העדפת typeface אלא לפי האם הוא נוכח בכל סביבה לתצוגה, להדפסה ולייצור PDF.

7.2. יסודות עיצוב טפסים — מיישרים, ואז מטמיעים

משתמשים באותו גופן במסך ובטופס

מציינים את אותו גופן במסך ובטופס. אם הגופנים נבדלים, אותם נתונים יכולים להיראות כמו glyph שונה, ומקבלים את התלונה מהפתיחה. תצורה כמו “Meiryo במסך, MS Mincho בטופס” צריכה לפחות להיבדק להבדלי glyph ב-168 תווי JIS2004.

מטמיעים ב-PDF, אחרי אישור הרישיון

מטמיעים את הגופן ב-PDF. אם לא, צד הצפייה מצייר עם איזה גופן שיש לו בהישג יד, ולא רק ה-glyphs אלא גם הפריסה יכולים להשתנות.

האם הטמעה מותרת נקבע לפי הרישיון. גופן OpenType מכריז על הרשאות ההטמעה שלו בשדה fsType (Installable, Restricted, Preview & Print, Editable, בלי subsetting, וכן הלאה), ואסור להטמיע גופן שההטמעה שלו אינה מותרת.¹⁰ לגופנים מסחריים, בדיקת החוזה היא חובה.

הופכים הטמעת subset לברירת מחדל. אם מטמיעים רק את ה-glyphs של התווים שבשימוש, אין צורך לשאת גופן יפני שלם (כמה MB עד עשרות MB).

שוקלים PDF/A לשמירה ארוכת טווח

אם שמירה ארוכת טווח היא דרישה, משתמשים ב-PDF/A. PDF/A (ISO 19005) הוא תקן שהופך את המשאבים הנחוצים לתצוגה לעצמאיים בתוך הקובץ, והטמעת גופן היא חובה.¹¹ זה גם הדרך האמינה ביותר למנוע “פתחנו את זה אחרי עשר שנים וה-glyphs השתנו”.

flowchart TB
    accTitle: זרימת ההחלטה להטמעת גופן
    accDescr: לפני שמטמיעים גופן ב-PDF, בודקים את רישיון ההטמעה ב-fsType, הופכים הטמעת subset לברירת מחדל אם זה מותר, ושוקלים PDF/A, שבו הטמעה היא חובה, אם שמירה ארוכת טווח היא דרישה
    emb["מטמיעים את הגופן ב-PDF"] --> lic{"הטמעה מותרת לפי fsType?"}
    lic -->|מותר| sub["הטמעת subset היא ברירת המחדל"]
    lic -->|לא מותר| ng["אסור להטמיע"]
    sub -.-> gly["רק ה-glyphs של התווים שבשימוש"]
    sub -->|דרישת שמירה ארוכת טווח| pdfa["שוקלים PDF/A"]
    pdfa -.-> must["הטמעת גופן היא חובה"]

איור 13: הטמעה מניחה בדיקת רישיון fsType; הטמעת subset ו-PDF/A הם הבסיס.

איך לבחור גישת מימוש להדפסה ולפלט PDF מכוסה בפירוט ב-“הדפסה ופלט PDF באפליקציות עסקיות של Windows”.

8. Font linking ו-fallback — תופעת “גופן אחר מתערבב”

תו שלגופן שצוין אין לו glyph לא נשאר ריק; ברירת המחדל של rendering stacks מודרניים היא לצייר אותו בגופן אחר במקום.

ב-GDI, “font linking” שמוגדר ברישום (FontLink\SystemLink) עושה את זה; ב-DirectWrite, WPF ודפדפנים, “font fallback” עושה.¹⁵

flowchart TB
    accTitle: הזרימה של font linking ו-fallback
    accDescr: אם לגופן שצוין יש את ה-glyph הוא מוצג כמו שהוא, אם לא הוא מצויר בגופן מקושר או fallback במקום, ואם אין glyph בשום מקום הוא הופך ל-□, אבל הנתונים בדרך כלל עדיין שלמים
    disp["מציגים תו"] --> has{"האם לגופן שצוין יש את ה-glyph?"}
    has -->|כן| draw["מוצג בגופן שצוין"]
    has -->|לא| fb{"האם לגופן מקושר או fallback יש אותו?"}
    fb -->|כן| alt["מצויר בגופן אחר במקום"]
    alt -.-> mixed["הסיבה לתחושת typeface מעורב"]
    fb -->|לא| tofu["□ (tofu) מוצג"]
    tofu -.-> alive["הנתונים בדרך כלל עדיין שלמים"]

איור 14: □ הוא עקבות של fallback שנכשל; האם ציור חלופי מצליח הוא המזלג בין “מעורב” ל-“tofu”.

קוראים את תוצאת הציור החלופי מהסימפטום

ידיעת המנגנון הזה מאפשרת להסביר את המקרים המוכרים הבאים.

• תחושת ה-typeface נבדלת בין אלפבית לטיני ליפנית: גופן לטיני צוין ראשון, ולכן רק החלק היפני מצויר בגופן היפני המקושר או ה-fallback
• רק ה-kanji במשפט יפני מקבלים glyphs בסגנון סיני: ה-fallback הגיע לגופן סיני. זה קורה בקלות בדפי אינטרנט ובאפליקציות שלא מעבירים מידע שפה (מאפיין lang או locale) נכון
• מופיע tofu (□): לא לגופן שצוין ולא לגופן ה-fallback יש את ה-glyph. במילים אחרות, □ הוא “עקבות של fallback שנכשל”, והנתונים בדרך כלל עדיין שלמים

Fallback אינו תחליף לתכנון

Fallback הוא רשת ביטחון; הוא אינו תחליף לבחירת הגופן הנכון מלכתחילה.¹⁵

באפליקציה עסקית, העמדה הבריאה היא “נתיבי התצוגה וההדפסה העיקריים שלמים עם הגופנים שתוכננו לבדם, ו-fallback הוא ביטוח מול תווים לא-צפויים”. לאיך לחשוב על בחירת גופן ב-UI רב-לשוני, ראו גם “לוקליזציה של אפליקציות WinForms/WPF”.

9. רשימת בדיקה למימוש באפליקציות עסקיות

לבסוף, הטבלה למטה מסכמת את הנקודות לבדוק בכל שכבה, מקלט עד אינטגרציה. לא עוצרים ב-“זה מוצג במסך”; בודקים גם אחסון, הדפסה ואינטגרציה.

מפרידים שמירת המקור מעיבוד לחיפוש

Normalization בפרט הוא המלכודת שהיא עצם נושא המאמר: עיבוד שמופעל “בכוונות טובות” שמשטח את ההבחנות בין תווי וריאנט ובין fullwidth ל-halfwidth. שומרים את המקור כמו שהוא; מעבדים עותק הוא העיקרון.

תקלות קידוד באינטגרציית CSV מכוסות בפירוט ב-“CSV אינו “סתם טקסט””.

flowchart TB
    accTitle: שומרים את המקור כמו שהוא ומעבדים עותק
    accDescr: שומרים את המחרוזת שהוזנה כמקור בדיוק כפי שהוזנה, מפעילים normalization על עותק שמוגבל לשימושים כמו יצירת מפתחות חיפוש, ומציינים שהפעלת NFKC על המקור מאבדת את ההבחנות בין תווי וריאנט ובין fullwidth ל-halfwidth
    input["מחרוזת שהוזנה"] --> orig["מקור: נשמר כפי שהוזן"]
    input --> copy["עותק: מנורמל לשימוש מוגבל"]
    copy -.-> use["יצירת מפתחות חיפוש וכדומה"]
    orig -.-> ng["NFKC על המקור משטח את ההבחנות"]

איור 15: מגבילים normalization לשימוש ספציפי ומפעילים אותו על עותק; שומרים את המקור כפי שהוזן.

10. סיכום

חקירה: מפרידים נתונים ממראה

• מפצלים בעיית תו קודם לשכבת “נתונים (קידוד תווים)” ולשכבת “מראה (גופנים)”. � מסמן כשל בשכבת הנתונים, □ כשל בשכבת המראה.
• JIS X 0213:2004 שינה את ה-glyphs לדוגמה של 168 תווים, ו-Windows ברירת המחדל שלו היא glyphs של JIS2004 מ-Vista ואילך. 葛, 辻, 飴 שנראים שונה בין סביבות הם היסטוריית גופנים, לא השחתת נתונים.

תכנון: מחליטים איך מציינים glyphs ומה מתקבל

• האמצעי הסטנדרטי לנעול glyph בנתונים הוא IVS, אבל בלי גופן תומך ואפליקציה תומכת הוא יורד ל-glyph ברירת המחדל. לא שוכחים את השפעת המימוש שתו אחד יכול להיות עד ארבע יחידות קוד UTF-16.
• Gaiji (EUDC) הם נכסים ספציפיים לאותו מחשב ואינם יכולים לנסוע עם הנתונים. התשובה המציאותית היא למפות אותם בזמן מעבר, להחליף אותם דרך טבלת מיפוי לתווים רגילים או ל-IVS, ולהפסיק ליצור חדשים.
• מערכת שמטפלת בשמות אנשים מחליטה על ערכת התווים שמתקבלת ומציינת אותה. הממשל מתקנן לכיוון התווים הסטנדרטיים לעניינים מנהליים על הבסיס של תווי Koseki מאוחדים ו-Character Information Platform, ומערכות שמתממשקות איתו צריכות לעקוב אחרי התנועה הזאת.

מימוש ופלט: שומרים על המקור ומיישרים את נתיבי התצוגה

• לטפסים ול-PDF, הבסיס הוא “משתמשים באותו גופן כמו המסך, מאשרים את הרישיון, ומטמיעים”. שוקלים PDF/A לשמירה ארוכת טווח.
• NFKC normalization, חיתוך לפי יחידת קוד, והמרת CP932 הם שלוש הנקודות הגדולות ששוברות בשקט תווי וריאנט ו-gaiji. הופכים שמירת המקור ועיבוד ביחידות grapheme לכלל.

בפעם הבאה שמישהו אומר לכם “התו שונה”, מתחילים בשאלה הזאת: האם ה-code points זהים, או שונים? אם הם זהים, זו בעיית גופן; אם הם נבדלים, זו בעיית נתונים. המהלך האחד הזה מונע כניסה לחקירה מהדלת הלא נכונה.

flowchart TB
    accTitle: השאלה הראשונה שמחליטה את נקודת הכניסה לחקירה
    accDescr: כשאומרים שתו שונה, קודם משווים אם ה-code points זהים או שונים, ומתחילים את החקירה כבעיית גופן אם הם זהים וכבעיית נתונים אם הם נבדלים
    said["נאמר שהתו שונה"] --> cmp{"האם ה-code points זהים?"}
    cmp -->|זהים| fontp["בעיית גופן"]
    cmp -->|שונים| datap["בעיית נתונים"]

איור 16: אם ה-code points זהים, מתחילים את החקירה כבעיית גופן; אם הם נבדלים, כבעיית נתונים.

מאמרים קשורים

• מבוא לקידודי טקסט ב-Windows - ה-mojibake שקורה באינטגרציה עם Linux
• קידודי טקסט וסופי שורה ב-Windows - יסודות mojibake ו-CRLF/LF
• הדפסה ופלט PDF באפליקציות עסקיות של Windows — בחירה בין System.Drawing.Printing, WPF וספריות דוחות
• לוקליזציה של אפליקציות WinForms/WPF — resx, satellite assemblies והחלפת Culture בפועל
• CSV אינו “סתם טקסט”: מדריך מעשי לטיפול ב-CSV באפליקציות עסקיות ב-C# (קידוד, תאימות Excel, הגנה מפני injection)
• יסודות נגישות באפליקציות Windows — UI Automation והכנה לחובת reasonable accommodation

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתכנון ובחקירה של טיפול בתווים במערכות עסקיות. אנחנו עובדים גם משכבת הקוד וגם משכבת הגופן: בידוד הגורם לסימפטומים כמו “התו שונה במסך ובטופס” או “שם הפך ל-□ אחרי המעבר”, סקר gaiji ובניית טבלאות תווים חלופיים במעבר ממערכות legacy, תכנון ערכת התווים שמתקבלת למערכות שמטפלות בשמות אנשים, וסקירת תצורת הטמעת הגופן של טפסים ו-PDF.

• Windows Custom Software Development
• שימוש חוזר והעברה של נכסים קיימים
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

למה אותו תו 葛 נראה שונה לפי המחשב או הטופס המודפס?

סביר יותר שזה הבדל ב-glyphs של גופן, לא mojibake. JIS X 0213:2004 (JIS2004) שינה את ה-glyphs לדוגמה של 168 kanji לצורות תקן הדפוס, וגם Windows הפך את glyphs של JIS2004 לברירת המחדל ב-MS Gothic, MS Mincho ואחרים מ-Vista ואילך. 葛, 辻, 飴 הם דוגמאות מייצגות: ה-code point של Unicode (הנתונים) נשאר זהה, ורק ה-glyph שהגופן מחזיק (המראה) השתנה. משווים את הנתונים והם תואמים; אי-התאמת צורה בין תמונת טופס מתקופת XP למסך של מחשב חדש היא ההתנהגות המוגדרת. אם רוצים ליישר גם את ה-glyphs, משתמשים באותו גופן על המסך ועל הטופס, או מציינים את ה-glyph עם ideographic variation selector.

אם משתמשים ב-ideographic variation selectors (IVS), זה פותר כל בעיית glyph של שמות אנשים?

לא. IVS הוא מנגנון שמניח selector מ-U+E0100 ואילך מיד אחרי תו הבסיס כדי לציין את ה-glyph כנתון, וה-glyph שצוין מוצג רק כשגופן תומך כמו IPAmj Mincho ואפליקציה תומכת שניהם נוכחים. בסביבה בלי תמיכה, ההתנהגות הנכונה היא שה-selector מתעלמים ממנו ומוצג glyph ברירת המחדל של תו הבסיס; בחלק מהסביבות ה-selector יכול גם להופיע כ-□. נוסף על כך, תו אחד עם IVS יכול להיות עד ארבע יחידות קוד ב-UTF-16, וזה משפיע על ספירת תווים, חילוץ מחרוזות משנה ותכנון אורכי עמודות DB. אם מאמצים אותו, מאשרים את היקף התמיכה דרך תצוגה, הדפסה וכל מערכת במורד הזרם לפני השימוש.

האם תו שנרשם כ-gaiji (EUDC) יכול להיות מוצג על מחשב אחר או ב-PDF?

ככלל, לא. Gaiji הוא מנגנון שבו המשתמש רושם glyph בקובץ eudc.tte של אותו מחשב ב-code point ב-Private Use Area של Unicode (מ-U+E000 ואילך), ולכן על מחשב אחר אותה נקודת קוד אינה מוגדרת או היא glyph אחר. לכן גורל ה-gaiji הוא להפוך ל-□ או להיראות כתו אחר ברגע שהם מגיעים לדואר, ל-PDF או למערכת אחרת. אם כבר מחזיקים נתונים שמכילים gaiji, הגישה המציאותית במעבר היא למצוא כל שימוש ב-Private Use Area, לבנות טבלת מיפוי לתווי Unicode רגילים או ל-ideographic variation selectors, ולהחליף. יצירת gaiji חדשים במערכת חדשה כדאי להימנע ממנה.

עד כמה מערכת עסקית צריכה לקבל תווים בשמות אנשים?

הצעד הראשון הוא להחליט על ערכת התווים שמתקבלת ולציין אותה במפורש כמפרט. במרשמי משפחה יש כ-56,000 תווי Koseki מאוחדים, ומערכות שתואמות לתקן הממשלתי נעות לכיוון התווים הסטנדרטיים לעניינים מנהליים, הרחבה של Character Information Platform, אבל מערכת עסקית כללית אינה מחויבת לקבל את אותה רמה בלי גבול. תכנון מציאותי מחליט על טווח כמו "עד היקף JIS X 0213" או "בלי ideographic variation selectors ובלי Private Use Area", מאמת בזמן קלט, ומטפל בתווים מחוץ לטווח בהתראה או בייצוג חלופי. רק מערכות שמתממשקות עם מערכות ממשלתיות או רשויות מקומיות צריכות לעקוב אחרי ההתפתחויות בתווים הסטנדרטיים לעניינים מנהליים ובדרישות ההחלפה שמבוססות על JIS X 0221.

איך גורמים לטופס מודפס או ל-PDF להציג את אותם תווים כמו המסך?

הבסיס הוא לציין את אותו גופן על המסך ועל הטופס, ולהטמיע את הגופן ב-PDF. אם הגופנים שונים, אותם נתונים יכולים להפיק glyphs שונים, ואם למחשב הצפייה אין את הגופן, משתמשים בגופן חלופי לציור והמראה נשבר. האם הטמעה מותרת נקבע לפי רישיון הגופן (OpenType fsType), לכן בודקים בעצמכם במקום להשאיר לספריית הדוחות. הטמעת subset, שמטמיעה רק את התווים שבשימוש, גם שומרת על גודל הקובץ. אם שמירה ארוכת טווח היא דרישה, שוקלים PDF/A, שבו הטמעת גופן היא חובה.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.