מה באמת נשבר ביצירת PDF בעברית: הטמעת גופן, סידור דו-כיווני, מספרים ומטבע לצד עברית, סדר עמודות בטבלה ושבירת עמוד, עם רשימת בדיקה ויזואלית לפני שליחה.
עיקרי הדברים
- כישלון הגופן שקט. בבדיקה שהרצתי, קריאה ל-`insert_text` ב-PyMuPDF עם גופן הבסיס `helv` וטקסט עברי החזירה ערך הצלחה, וההמרה חזרה כתווים חסרי משמעות. שום חריגה לא נזרקה.
- דפדפן מבצע סידור דו-כיווני לפי אלגוריתם Unicode בעצמו. PyMuPDF אינו עושה זאת, ולכן טקסט עברי צריך לעבור `get_display` של python-bidi לפני הציור.
- הסידור הזה מייצר קובץ שנראה נכון אך הטקסט בתוכו כבר אינו בסדר הלוגי. בבדיקה, המחרוזת `שלום 5 ש"ח` חזרה מחילוץ הטקסט בסדר אחר לגמרי.
- כותרת עליונה ותחתונה ב-Puppeteer אינן יורשות את הגופן של המסמך. בבדיקה שהרצתי, טקסט עברי בתחתית העמוד נפל חזרה ל-ArialMT עד שהצהרת `@font-face` הוכנסה לתוך תבנית הכותרת עצמה.
- `insert_textbox` מחזיר מספר שלילי כשהטקסט אינו נכנס למלבן. זהו הסימן היחיד שמאפשר הקטנה אוטומטית של הגופן במקום טקסט שנעלם.
שלוש התקלות שמייצרות כמעט כל מסמך עברי פגום הן גופן שאין בו אותיות עבריות, טקסט שלא עבר סידור דו-כיווני, ומספר או סימן פיסוק שנחתו בצד הלא נכון. כל אחת מהן מייצרת קובץ תקין טכנית שנראה שבור לעין, ולכן הבדיקה חייבת להיות ויזואלית.
איזה גופן באמת מוטמע בקובץ?
זו השאלה הראשונה, כי כישלון גופן אינו מדווח. גופני הבסיס של תקן PDF אינם מכילים אותיות עבריות. בבדיקה שהרצתי, ציור טקסט עברי עם helv לא זרק חריגה ולא החזיר שגיאה, והחילוץ מהקובץ שנוצר החזיר תווים שאינם הטקסט שנשלח. אותה תקלה בדפדפן נראית כמלבנים ריקים או כאותיות בגופן שלא בחרתם.
מה שעושים במקום:
- מטמיעים קובץ גופן שיש בו את הטווח העברי, ורושמים אותו במפורש לפני הציור. בצד PyMuPDF זו קריאת
insert_fontעם נתיב לקובץ TTF. - בצד HTML מצרפים את הגופן כ-
@font-face, ומעדיפים קידוד base64 בתוך המסמך על פני כתובת חיצונית, כי בזמן ההמרה אין ודאות שמשאב חיצוני ייטען. - מוסיפים גופן חלופי ברשימת
font-family, אבל לא סומכים עליו. גופן חלופי הוא מה שמסתיר את התקלה, לא מה שפותר אותה. - בודקים את הקובץ שנוצר: פותחים אותו ומוציאים את רשימת הגופנים שבו. אם מופיע שם גופן שלא התכוונתם אליו, יש נפילה לחלופי.
מי מסדר את הכיווניות, המנוע או אתם?
התשובה שונה בין שני המסלולים, וזה שורש רוב הבלבול. דפדפן מיישם את אלגוריתם הכיווניות של Unicode בעצמו, ולכן ב-HTML מספיק להצהיר על כיוון ולתת לו לעבוד. ספריית PyMuPDF אינה מיישמת אותו, ולכן היא מציירת את התווים בסדר שבו קיבלה אותם, ומחרוזת עברית שנמסרת כמו שהיא תיראה הפוכה.
הפתרון המקובל הוא להעביר את המחרוזת דרך get_display של python-bidi לפני הציור, וזה מה שנעשה במערכת שממנה נלקחו הבדיקות האלה. חשוב להבין מה המחיר: הפונקציה מחזירה את המחרוזת בסדר התצוגה, כלומר סדר האחסון בקובץ כבר אינו הסדר הלוגי.
בבדיקה שהרצתי, המחרוזת שלום 123 ABC חזרה מ-get_display כשהרצף הלטיני והספרות נשארו בסדרם והאותיות העבריות התהפכו. וכשחילצתי טקסט מקובץ שנחתם כך, המחרוזת שלום 5 ש"ח לא חזרה כפי שנשלחה. בדיקה שנשענת על העתקה מהקובץ תיכשל אפוא גם כשהעמוד נכון לחלוטין. המסקנה המעשית: הבדיקה הקובעת היא ויזואלית, וחילוץ טקסט משמש רק לזיהוי הגופן שנפל.
תסמין, סיבה סבירה, ובדיקה
| מה רואים | הסיבה הסבירה | הבדיקה |
|---|---|---|
| מלבנים ריקים במקום אותיות | הגופן אינו מכיל את הטווח העברי | הוצאת רשימת הגופנים מהקובץ |
| מילים עבריות הפוכות | לא בוצע סידור דו-כיווני לפני הציור | השוואת שורה אחת מול המקור על המסך |
| מספר שנחת בצד הלא נכון | ערך מעורב בלי הצהרת כיוון מפורשת | עטיפת התא בהצהרת כיוון והשוואה |
| נקודה או פסיק בתחילת שורה | פיסוק שקיבל את כיוון ההקשר ולא את הרצוי | בדיקת סוף המשפט בכל פסקה |
| טקסט שנעלם באמצע | המלבן קטן מדי והוחזר ערך שלילי | בדיקת הערך המוחזר מ-insert_textbox |
| גופן שונה בתחתית העמוד | תבנית הכותרת אינה יורשת גופן מהמסמך | הצהרת גופן בתוך התבנית עצמה |
מספרים, מטבע ופיסוק לצד עברית
זו התקלה שהלקוח מבחין בה מיד, כי סכום כסף שנראה שגוי הורס את אמון המסמך כולו. שלושה כללים מעשיים:
- הצהירו כיוון מפורש על כל ערך מספרי בתוך פסקה עברית, במקום להסתמך על ההקשר. ב-CSS זהו שילוב של
direction: ltrעםunicode-bidi: embedעל אותו אלמנט. - בטבלאות, הצמידו את ההצהרה לתאי הכמות, המחיר והסך. תא שמכיל רק מספר וסימן מטבע הוא בדיוק המקום שבו הכיוון ההקשרי נותן תוצאה לא צפויה.
- השתמשו בספרות בעלות רוחב אחיד לעמודות מספריות. זה אינו קשור לכיווניות, אבל הוא מונע את המראה המרוסק שמלווה טבלאות מחיר.
נקודה שנשכחת: סימן הפיסוק בסוף משפט עברי המכיל מונח לטיני מקבל את הכיוון מההקשר שסביבו. בדקו את הנקודה בסוף כל פסקה שמסתיימת במונח באנגלית, כי שם היא נוטה להופיע בצד הלא נכון.
טבלאות, כותרות עמודים ושבירת עמוד
בטבלה, סדר העמודות נקבע לפי כיוון האלמנט. הצהרת dir="rtl" על הטבלה הופכת את סדר העמודות מימין לשמאל, וזה מה שרוצים במסמך עברי. הבעיה הנפוצה היא מסמך שמצהיר כיוון על הגוף אך לא על הטבלה, או להיפך, ואז הכותרות והערכים מסתדרים בכיוונים מנוגדים.
לגבי כותרות עליונות ותחתונות, יש כאן ממצא שכדאי לדעת מראש. Puppeteer מקבל תבנית HTML נפרדת לכותרת ולתחתית, ובבדיקה שהרצתי הצהרת @font-face שהופיעה ב-head של המסמך לא חלה עליהן: התחתית העברית נפלה חזרה ל-ArialMT. כשהעברתי את אותה הצהרה אל תוך תבנית התחתית עצמה, הגופן המוטמע נכנס לשימוש. אם התחתית שלכם מכילה עברית, זהו סעיף בדיקה נפרד.
לשבירת עמוד, שני כללים:
- סמנו כל בלוק שאסור לו להישבר, למשל שורת חתימה או כרטיס פרטי לקוח, ב-
page-break-inside: avoid. - אל תסמכו על השוליים בלבד. הגדירו את גודל העמוד ואת השוליים ב-
@pageובקשו מהממיר לכבד אותם, אחרת אזור התחתית עלול לחפוף לתוכן.
בדקו תמיד מסמך של שלושה עמודים לפחות. מסמך של עמוד אחד אינו מגלה אף אחת מהתקלות האלה. עוד על ההתנהגות של ממשקים עבריים באופן כללי יש בעברית ו-RTL בתוכנה עסקית, ועל מסמכים שנשלחים לחתימה בחתימה אלקטרונית לעסק ובתיעוד ראיות בחתימה דיגיטלית על הצעת מחיר.
רשימת הבדיקה הוויזואלית לפני שליחה
- פתחו את הקובץ בקורא PDF, לא בתצוגה המקדימה של המערכת שיצרה אותו.
- השוו שורה עברית אחת מול המקור, אות באות, ובדקו שהיא אינה הפוכה.
- בדקו סכום כסף אחד שמופיע לצד טקסט עברי, כולל מיקום סימן המטבע.
- בדקו את הנקודה בסוף פסקה שמסתיימת במונח לטיני.
- הריצו על מסמך של שלושה עמודים ובדקו שהתחתית זהה בכל העמודים.
- ודאו שהתחתית מוצגת באותו גופן כמו הגוף.
- חפשו טקסט שנחתך בקצה מלבן, במיוחד בשמות ארוכים.
- בדקו שסדר העמודות בטבלה זהה בין הכותרות לבין שורות הנתונים.
- הפיקו את הקובץ עם שם לקוח ארוך ועם שם קצר, ובדקו את שניהם.
- הוציאו את רשימת הגופנים המוטמעים וודאו שאין שם גופן שלא התכוונתם אליו.
מקורות
שאלות נפוצות
למה הטקסט נראה תקין בדפדפן ושבור ב-PDF?
כי הדפדפן מיישם את אלגוריתם הכיווניות של Unicode ומוצא גופן חלופי בעצמו, ואילו ספריית PDF מציירת בדיוק את מה שקיבלה. אם הגופן אינו מוטמע או הסידור הדו-כיווני לא בוצע, המסך יכסה על התקלה והקובץ יחשוף אותה. לכן הבדיקה חייבת להיות על הקובץ.
האם אפשר לבדוק תקינות עברית בעזרת חילוץ טקסט מהקובץ?
לא כבדיקה מכרעת. בבדיקה שהרצתי, מחרוזת עברית שנחתמה אחרי סידור דו-כיווני חזרה מהחילוץ בסדר שונה מהמקור, ושורה עברית שנוצרה בדפדפן חזרה בסדר התצוגה ולא בסדר הלוגי. חילוץ טקסט שימושי כדי לגלות נפילה לגופן חלופי, ולא כדי לאשר את הניסוח או את סדר המילים.
מה עושים כשטקסט עברי נחתך במלבן?
מזהים את זה תכנותית במקום בעין. `insert_textbox` מחזיר ערך שלילי כשהטקסט אינו נכנס למלבן; בבדיקה שהרצתי אותו מלבן החזיר כ-336 מינוס לטקסט ארוך וערך חיובי לטקסט קצר. הקטנת גופן בלולאה עד שהערך אינו שלילי היא המימוש המקובל, והיא עדיפה על חיתוך שקט.
איזה גופן עברי כדאי להטמיע?
כל גופן שמכיל את הטווח העברי, שמורשה להטמעה, ושאתם יכולים לשלוח יחד עם הקוד. במערכת שממנה נלקחו הבדיקות האלה מוטמע Noto Sans Hebrew כקובץ בתוך המאגר עצמו, כדי שהמסמך ייראה זהה בשרת ובמחשב מקומי בלי תלות בגופנים שמותקנים במכונה שמייצרת אותו.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.