פונט כתוביות בעברית: למה הוא נשבר בפרמייר ואיך נראה תקין
לא כל "תמיכה בעברית" זהה. יש הבדל בין פונט שרק מצייר אותיות עבריות לבין מנוע כתוביות שמבין כיוון קריאה, מיקום פיסוק ומספרים בתוך משפט עברי.
בוחרים פונט יפה ב-Essential Graphics, מקלידים כתובית בעברית, לוחצים פליי — ועל המסך מופיעה שורה שנראית כאילו מישהו ערבב את התווים. זה לא באג נדיר, וברוב המקרים זו גם לא אשמת הפונט.
כדאי להפריד בין שלוש שכבות שנוטים לערבב ביניהן: הפונט (הצורה הגרפית של האותיות), הקידוד (איך התווים נשמרים ונקראים כטקסט) וכיוון הטקסט (RTL, מימין לשמאל). פונט יכול להיות מושלם מבחינה ויזואלית ועדיין להציג ג'יבריש אם הקידוד לא תואם. וגם כשהקידוד תקין, הטקסט עדיין עלול להיראות הפוך אם התוכנה לא מיישמת RTL אמיתי — כלומר לא רק יישור לימין, אלא סדר קריאה נכון של מילים, פיסוק ומספרים.
המאמר הזה לא מסתפק בתיאור כללי של הבעיה. הוא מראה איך שורה שבורה נראית לצד אותה שורה תקינה, כדי שתוכלו לזהות תוך שנייה אם מה שמופיע אצלכם על המסך הוא כשל קידוד, כשל כיווניות, או פשוט מנוע שלא נבנה לעברית.
Translated naturally.
In every language.
Native phrasing, not word-for-word. Word-level timestamps, burned-in or exported as SRT — in seconds.
מה זה מוג'יבייק, ולמה זו לא אשמת הפונט
כשקובץ טקסט עברי נשמר בקידוד אחד ונקרא בקידוד אחר — למשל קובץ UTF-8 שנפתח כאילו הוא Windows-1255 או להפך — כל תו עברי מוחלף בסימן אחר לפי טבלת ההמרה השגויה. לתופעה קוראים מוג'יבייק (mojibake), והיא לא קשורה לגופן. אפשר להריץ את אותו טקסט דרך עשרה פונטים עבריים שונים ולקבל בדיוק את אותה תצוגה שבורה, כי הבעיה נמצאת בבתים עצמם ולא בצורת האות.
כך זה נראה בפועל: המילה "שלום" בקידוד תקין מוצגת כמו שצריך, ואילו אותו קובץ שנקרא בטבלת קידוד לטינית עלול להופיע כרצף סימנים כמו ×©×œ×•× — לא אותיות עבריות בכלל, אלא סימנים לטיניים שהחליפו כל בית בנפרד.
למה זה קורה דווקא בעברית ולא באנגלית? תו לטיני בסיסי תופס בית אחד, ואילו תו עברי ב-UTF-8 תופס שני בתים. קריאה בקידוד שמפרש כל בית בנפרד הופכת כל אות עברית לשני סימנים חסרי משמעות. אנגלית "שורדת" קידוד שגוי, עברית לא.
הפתרון אינו החלפת פונט, אלא לוודא שהקובץ נשמר ונקרא ב-UTF-8 לאורך כל הדרך: מהתמלול, דרך קובץ ה-SRT, ועד הייבוא לפאנל הכתוביות. ב-Captain Cut התמלול נכתב ישירות לטראק כתוביות סטנדרטי של פרמייר, בלי לעבור דרך קובץ ביניים שנשמר בקידוד לא ידוע.
שורה שנשברת באמצע מילה: איך נראית שגויה ואיך נראית נכונה
בעיה נפרדת מקידוד היא שבירת שורות. מנוע שמחשב את נקודת השבירה לפי ספירת תווים בלבד עלול לחתוך במיקום שרירותי, בלי להתחשב בגבולות המילה — והתוצאה היא שורה שנשברת באמצע מילה במקום בנקודה טבעית במשפט.
דוגמה. המשפט המלא: "אני רוצה להודות לכל מי שהגיע היום למופע המיוחד הזה".
שבירה שגויה:
- שורה 1: "אני רוצה להודות לכל מי שהגי"
- שורה 2: "ע היום למופע המיוחד הזה"
המילה "שהגיע" נקרעה לשתיים. שבירה תקינה של אותו משפט:
- שורה 1: "אני רוצה להודות לכל מי שהגיע היום"
- שורה 2: "למופע המיוחד הזה"
כל שורה היא יחידת משמעות שלמה, בלי מילה חצויה. על הנייר ההבדל נראה קטן, אבל בכתובית שמופיעה על המסך לשנייה בודדת, מילה קרועה מאלצת את הצופה לעצור ולקרוא שוב — בדיוק מה שכתובית טובה אמורה למנוע.
הקושי גדל במשפטים שמשלבים מספרים או שמות, כי אז מצטרפת לבעיית הקריאוּת גם בעיית הכיווניות, ושתיהן מופיעות באותה שורה.
פיסוק במקום הלא נכון: משפטים עם מספרים וסימני שאלה
השכבה השלישית, והכי מטעה, היא כיווניות מעורבת. עברית נקראת מימין לשמאל, אבל ספרות מוצגות תמיד משמאל לימין — גם בתוך משפט עברי. לתופעה קוראים טקסט דו-כיווני (bidi). מנוע שלא מיישם אותה כראוי ממקם את סימן השאלה, הנקודתיים או הסוגריים בצד הלא נכון של השורה.
דוגמה. המשפט התקין: "הפגישה נקבעה ל-14:30, זה בסדר?" — סימן השאלה יושב בסוף המשפט, והמספר 14:30 מוצג משמאל לימין בתוך זרימת הטקסט העברי.
במנוע שלא מטפל ב-bidi כראוי, אותה שורה עלולה לצאת עם סימן השאלה בתחילת המשפט, ועם המקף שלפני השעה מנותק מהמספר ומודבק למילה הלא נכונה. זו לא שגיאת הקלדה: זו תוצאה ישירה של מנוע שמחיל כיוון אחד גורף על כל השורה, במקום להחליף כיוון נכון בכל מעבר בין עברית למספר ובחזרה.
אותה תופעה מופיעה עם מירכאות בשמות: השורה "הסרט "אביב" יצא ב-2024" עלולה לצאת כשהמירכאות והמקף בצד ההפוך. בדיוק לכן כתוביות RTL אמיתיות דורשות יותר מדגל כיוון אחד על כל השורה — נדרש טיפול נפרד בכל מילה, מספר וסימן פיסוק. זה מה ש-Captain Cut מטפל בו בעברית ובערבית: כיוון, מיקום פיסוק, שורות מעורבות כיוון וספרות.
טיפול בכיווניות ובפלט: מה משנה בפועל
| Captain Cut | מנוע כתוביות שלא נבנה ל-RTL | |
|---|---|---|
| כיוון טקסט | RTL אמיתי בעברית ובערבית | לרוב יישור לימין בלבד |
| מיקום פיסוק | ממוקם לפי כיוון הקריאה הנכון | עלול לקפוץ לצד ההפוך |
| מספרים בשורה מעורבת | נשמרים בכיוון הנכון בתוך הזרימה העברית | עלולים לזוז או להתנתק מהמקף |
| שמירת שמות | שמות נשמרים כפי שנאמרו | משתנה לפי הכלי |
| פלט | טראק כתוביות סטנדרטי של פרמייר, עיצוב ב-Essential Graphics וייצוא SRT | משתנה לפי הכלי |
שאלות נפוצות
לא. הפונט קובע רק את הצורה הגרפית של האותיות — איך האות ת' או ש' נראית על המסך. הוא לא קובע באיזה סדר התווים מוצגים, מאיפה המשפט מתחיל, או איפה נשברת השורה. גם עם הפונט העברי היפה ביותר, אם המנוע שמאחורי הכתוביות לא מיישם כיווניות (bidi) כראוי, תקבלו את אותה שורה הפוכה ואת אותו פיסוק במקום שגוי. הבעיה נמצאת ברמת עיבוד הטקסט, לא ברמת הגופן.
אנגלית וספרדית נכתבות משמאל לימין, ובקידוד הבסיסי כל תו שלהן תופס בית אחד — בדיוק מה שמנועי טקסט מערביים תוכננו לתמוך בו מהיום הראשון. עברית נכתבת מימין לשמאל, ובנוסף דורשת טיפול בכיווניות מעורבת בגלל מספרים ופיסוק. מנוע שנבנה קודם כול לשפות מערביות, ורק אחר כך הוסיפו לו עברית, נוטה לפספס בדיוק את המקרים המורכבים האלה, גם כשהוא מציג אותיות עבריות תקינות במשפטים פשוטים.
אם אתם רואים סימנים לטיניים משונים במקום אותיות עבריות, זו בעיית קידוד — הקובץ נקרא בטבלת קידוד שגויה. אם האותיות העבריות תקינות אבל סדר המילים או מיקום הפיסוק נראה הפוך, זו בעיית כיווניות. שתי התקלות דורשות תיקון שונה לגמרי: קידוד נפתר בשמירה מחדש כ-UTF-8, וכיווניות דורשת מנוע שמיישם RTL אמיתי.
תלוי במקור הכתוביות. אם אתם מייבאים קובץ SRT חיצוני, ודאו שהוא נשמר כ-UTF-8 — רוב עורכי הטקסט המודרניים מציגים ומאפשרים לבחור את הקידוד. אם אתם מייצרים כתוביות ישירות דרך Captain Cut בתוך פרמייר, אין שלב של קובץ טקסט חיצוני: התמלול נכתב ישירות לטראק כתוביות סטנדרטי של פרמייר, ואפשר לעצב אותו ב-Essential Graphics או לייצא ל-SRT.
אם מדובר בקידוד, לפעמים אפשר לפתוח את הקובץ מחדש בקידוד הנכון ולשמור כ-UTF-8 — זה תלוי אם המידע המקורי עדיין קיים ורק מוצג לא נכון, או שנהרס בהמרה. אם מדובר בשבירת שורות או בפיסוק שיצא במקום הלא נכון, בדרך כלל אין תיקון פשוט לטקסט קיים, וכדאי לתמלל מחדש עם מנוע שמטפל בכיווניות מלכתחילה.
"תמיכה בעברית" פירושה בדרך כלל שהמוצר לא קורס כשמזינים תווים עבריים ומציג אותם בגופן קריא. RTL אמיתי פירושו שהמנוע מבין כיוון קריאה, ממקם פיסוק נכון, ומטפל כראוי בשורות שמערבבות עברית ומספרים. הבדיקה המהירה: הקלידו משפט שמשלב מספר וסימן שאלה, וראו אם הוא יוצא נכון. זה בדיוק המקרה שבו מנועים שלא נבנו ל-RTL נכשלים.
רוצים כתוביות בעברית שלא נשברות?
Captain Cut כותב כתוביות ישירות לפרמייר עם RTL אמיתי — כיוון, מיקום פיסוק, מספרים ושורות מעורבות. 7 ימי ניסיון חינם בכל התוכניות, אפשר לבטל בכל שלב.
התחילו בחינם