פונט כתוביות בעברית: למה הוא נשבר בפרמייר ואיך נראה תקין
לא כל "תמיכה בעברית" זהה. יש הבדל בין פונט שרק מצייר אותיות עבריות לבין מנוע כתוביות שמבין כיוון קריאה, מיקום פיסוק ומספרים בתוך משפט עברי.
בוחרים פונט יפה ב-Essential Graphics, מקלידים כתובית בעברית, לוחצים פליי — ועל המסך מופיעה שורה שנראית כאילו מישהו ערבב את התווים. זה לא באג נדיר, וברוב המקרים זו גם לא אשמת הפונט.
כדאי להפריד בין שלוש שכבות שנוטים לערבב ביניהן: הפונט (הצורה הגרפית של האותיות), הקידוד (איך התווים נשמרים ונקראים כטקסט) וכיוון הטקסט (RTL, מימין לשמאל). פונט יכול להיות מושלם מבחינה ויזואלית ועדיין להציג ג'יבריש אם הקידוד לא תואם. וגם כשהקידוד תקין, הטקסט עדיין עלול להיראות הפוך אם התוכנה לא מיישמת RTL אמיתי — כלומר לא רק יישור לימין, אלא סדר קריאה נכון של מילים, פיסוק ומספרים.
המאמר הזה לא מסתפק בתיאור כללי של הבעיה. הוא מראה איך שורה שבורה נראית לצד אותה שורה תקינה, כדי שתוכלו לזהות תוך שנייה אם מה שמופיע אצלכם על המסך הוא כשל קידוד, כשל כיווניות, או פשוט מנוע שלא נבנה לעברית.
תרגום שנשמע טבעי.
בכל שפה.
ניסוח של דובר שפת אם, לא מילה במילה. חותמות זמן ברמת המילה, צרובות בווידאו או כקובץ SRT — תוך שניות.
מה זה מוג'יבייק, ולמה זו לא אשמת הפונט
כשקובץ טקסט עברי נשמר בקידוד אחד ונקרא בקידוד אחר — למשל קובץ 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 | משתנה לפי הכלי |
איך בוחרים פונט שבאמת מכיל עברית, ומה קורה כשהוא לא
עד עכשיו דיברנו על תקלות שהפונט לא אחראי להן. אבל יש גם תקלה אחת שכן נובעת ישירות מהגופן: פונט שאין בו גליפים עבריים בכלל. הרבה פונטים לטיניים פופולריים — בדיוק אלה שמופיעים בתבניות כתוביות "טרנדיות" — מכילים רק את האלפבית הלטיני. כשמקלידים בהם עברית, פרמייר לא יכול לצייר את האות, ואז קורה אחד משני דברים: או שמוצגים ריבועים ריקים במקום אותיות, או שהמערכת מחליפה בשקט לפונט גיבוי אחר. במקרה השני הכתובית נראית תקינה, אבל לא בגופן שבחרתם, ולפעמים במשקל ובגובה שונים לגמרי מהשורות הלטיניות שלידה.
הבדיקה לוקחת עשר שניות: לפני שמעצבים טראק שלם, הקלידו שורת מבחן אחת שכוללת את כל המקרים הבעייתיים — אותיות סופיות (ך ם ן ף ץ), גרש וגרשיים (צ׳יפס, צה״ל), מספר, סימן שאלה ומירכאות. אם משהו מזה יוצא כריבוע או בגופן אחר, הפונט לא מתאים לכתוביות בעברית, גם אם האותיות הרגילות נראות בו מצוין.
שלוש נקודות נוספות ששוות בדיקה:
- משקלים. פונט עברי שמגיע רק במשקל Regular יקבל מפרמייר "בולד מזויף" (Faux Bold) כשתלחצו על כפתור ההדגשה. זה עובה את הקווים באופן מלאכותי, ובגדלים קטנים האותיות ד/ר ו-ה/ח מתחילות להתמזג. עדיף פונט שיש לו משקל Bold או Black אמיתי.
- גובה האות. אותיות עבריות יושבות בגובה שונה מאותיות לטיניות באותו גודל נקודות. אם אתם מערבבים בשורה שם מותג באנגלית, בדקו שהוא לא נראה גדול או קטן בצורה בולטת.
- שורת המבחן במסך הסופי. פונט דק שנראה אלגנטי במוניטור של 27 אינץ' נעלם במסך טלפון. בדקו את הכתובית בגודל שבו היא תיצפה בפועל.
כל זה נוגע לשכבת העיצוב בלבד. Captain Cut כותב את הטקסט לטראק כתוביות סטנדרטי של פרמייר, כך שבחירת הגופן, המשקל והגודל נשארת אצלכם ב-Essential Graphics — והכיווניות נשמרת לא משנה באיזה פונט עברי בחרתם.
Track Style, פרויקט שעובר בין מחשבים, וייצוא SRT: איפה הפונט הולך לאיבוד
גם אחרי שבחרתם פונט נכון, יש שלושה רגעים בזרימת העבודה שבהם הוא נוטה להיעלם. כדאי להכיר אותם מראש.
1. עיצוב כתובית אחת במקום כל הטראק. טעות נפוצה היא לסמן כתובית בודדת, לשנות לה פונט ב-Essential Graphics (Window > Essential Graphics), ולגלות שכל שאר הכתוביות נשארו בגופן ברירת המחדל. הדרך הנכונה: לעצב כתובית אחת, ואז בפאנל Essential Graphics, תחת Track Style, לבחור Create Style ולתת לסגנון שם. מרגע זה הסגנון חל על כל הכתוביות בטראק, ושינוי בו מתעדכן בכולן בבת אחת. סגנון שמור גם חוסך את העיצוב מחדש בפרויקט הבא.
2. פרויקט שנפתח במחשב אחר. קובץ הפרויקט של פרמייר שומר את שם הפונט, לא את הפונט עצמו. אם העורך השני או מחשב הרנדר לא מותקן עליו אותו גופן, פרמייר יחליף אותו בגופן אחר — ואם הגופן החלופי לא מכיל עברית, חוזרים בדיוק לבעיית הריבועים מהסעיף הקודם. לפני מסירה, ודאו שהפונט מותקן אצל כל מי שפותח את הפרויקט. לתיקון פונטים חסרים בפרויקט קיים יש בפרמייר את Graphics and Titles > Replace Fonts in Projects.
3. ייצוא SRT. קובץ SRT הוא טקסט נקי עם חותמות זמן — אין בו שום מידע על פונט, צבע, גודל או מיקום. כשמעלים SRT ליוטיוב או לפלטפורמה אחרת, הכתוביות מוצגות בגופן של הנגן, לא בגופן שעיצבתם בפרמייר. זה לא באג, זו הדרך שבה הפורמט עובד. אם העיצוב חלק מהמסר — למשל ברילס — צריך לצרוב את הכתוביות לתוך הווידאו בייצוא. אם הצופה צריך אפשרות לכבות אותן, או שהפלטפורמה מתרגמת אותן, SRT הוא הבחירה הנכונה, ואז מה שחשוב הוא שהקובץ יהיה UTF-8 תקין.
בפועל הרבה עורכים מייצאים את שניהם: גרסה צרובה לסושיאל, וקובץ SRT ליוטיוב. Captain Cut מאפשר את שני המסלולים מאותו טראק — עיצוב ב-Essential Graphics לצריבה, וייצוא SRT לקובץ נפרד.
שאלות נפוצות
לא. הפונט קובע רק את הצורה הגרפית של האותיות — איך האות ת' או ש' נראית על המסך. הוא לא קובע באיזה סדר התווים מוצגים, מאיפה המשפט מתחיל, או איפה נשברת השורה. גם עם הפונט העברי היפה ביותר, אם המנוע שמאחורי הכתוביות לא מיישם כיווניות (bidi) כראוי, תקבלו את אותה שורה הפוכה ואת אותו פיסוק במקום שגוי. הבעיה נמצאת ברמת עיבוד הטקסט, לא ברמת הגופן.
אנגלית וספרדית נכתבות משמאל לימין, ובקידוד הבסיסי כל תו שלהן תופס בית אחד — בדיוק מה שמנועי טקסט מערביים תוכננו לתמוך בו מהיום הראשון. עברית נכתבת מימין לשמאל, ובנוסף דורשת טיפול בכיווניות מעורבת בגלל מספרים ופיסוק. מנוע שנבנה קודם כול לשפות מערביות, ורק אחר כך הוסיפו לו עברית, נוטה לפספס בדיוק את המקרים המורכבים האלה, גם כשהוא מציג אותיות עבריות תקינות במשפטים פשוטים.
אם אתם רואים סימנים לטיניים משונים במקום אותיות עבריות, זו בעיית קידוד — הקובץ נקרא בטבלת קידוד שגויה. אם האותיות העבריות תקינות אבל סדר המילים או מיקום הפיסוק נראה הפוך, זו בעיית כיווניות. שתי התקלות דורשות תיקון שונה לגמרי: קידוד נפתר בשמירה מחדש כ-UTF-8, וכיווניות דורשת מנוע שמיישם RTL אמיתי.
תלוי במקור הכתוביות. אם אתם מייבאים קובץ SRT חיצוני, ודאו שהוא נשמר כ-UTF-8 — רוב עורכי הטקסט המודרניים מציגים ומאפשרים לבחור את הקידוד. אם אתם מייצרים כתוביות ישירות דרך Captain Cut בתוך פרמייר, אין שלב של קובץ טקסט חיצוני: התמלול נכתב ישירות לטראק כתוביות סטנדרטי של פרמייר, ואפשר לעצב אותו ב-Essential Graphics או לייצא ל-SRT.
אם מדובר בקידוד, לפעמים אפשר לפתוח את הקובץ מחדש בקידוד הנכון ולשמור כ-UTF-8 — זה תלוי אם המידע המקורי עדיין קיים ורק מוצג לא נכון, או שנהרס בהמרה. אם מדובר בשבירת שורות או בפיסוק שיצא במקום הלא נכון, בדרך כלל אין תיקון פשוט לטקסט קיים, וכדאי לתמלל מחדש עם מנוע שמטפל בכיווניות מלכתחילה.
"תמיכה בעברית" פירושה בדרך כלל שהמוצר לא קורס כשמזינים תווים עבריים ומציג אותם בגופן קריא. RTL אמיתי פירושו שהמנוע מבין כיוון קריאה, ממקם פיסוק נכון, ומטפל כראוי בשורות שמערבבות עברית ומספרים. הבדיקה המהירה: הקלידו משפט שמשלב מספר וסימן שאלה, וראו אם הוא יוצא נכון. זה בדיוק המקרה שבו מנועים שלא נבנו ל-RTL נכשלים.
ריבועים ריקים במקום אותיות הם סימן מובהק לכך שהפונט שבחרתם לא מכיל גליפים עבריים. זו לא בעיית קידוד ולא בעיית כיווניות: הטקסט תקין, אבל לגופן אין צורה לצייר אותו. הפתרון הוא להחליף לפונט שכולל עברית. לפני שמעצבים טראק שלם, הקלידו שורת מבחן עם אותיות סופיות, גרש וגרשיים, מספר וסימן שאלה, וודאו שכולם מוצגים באותו גופן.
כי קובץ SRT לא נושא שום מידע עיצובי. הוא מכיל רק טקסט וחותמות זמן, ולכן יוטיוב וכל נגן אחר מציגים אותו בגופן שלהם. הפונט, הצבע והמיקום שהגדרתם ב-Essential Graphics קיימים רק בתוך פרמייר. אם העיצוב חשוב לכם, צרבו את הכתוביות לתוך הווידאו בייצוא. אם אתם רוצים שהצופה יוכל לכבות אותן, העלו SRT וקבלו את הגופן של הפלטפורמה.
מעצבים כתובית אחת בפאנל Essential Graphics (Window > Essential Graphics), ואז תחת Track Style בוחרים Create Style ונותנים לסגנון שם. מאותו רגע הסגנון חל על כל הכתוביות בטראק, וכל שינוי בו — פונט, גודל, צבע או קו מתאר — מתעדכן בכולן יחד. אפשר להשתמש באותו סגנון שמור גם בפרויקטים הבאים, כך שלא צריך לעצב מחדש בכל עבודה.
קובץ הפרויקט של פרמייר שומר רק את שם הפונט, לא את קובץ הפונט עצמו. אם הגופן לא מותקן במחשב השני, פרמייר מחליף אותו בגופן אחר, ולפעמים בגופן שאין בו עברית בכלל. התקינו את אותו פונט בכל מחשב שפותח את הפרויקט, ולתיקון פרויקט קיים השתמשו ב-Graphics and Titles > Replace Fonts in Projects. הטקסט וחותמות הזמן לא נפגעים, רק העיצוב.
לא. Captain Cut מתמלל, מסדר את הטקסט עם RTL אמיתי וחותמות זמן ברמת המילה, וכותב אותו לטראק כתוביות סטנדרטי של פרמייר. הבחירה בפונט, במשקל, בגודל ובמיקום נשארת שלכם ב-Essential Graphics, כמו בכל טראק כתוביות אחר. היתרון הוא שהכיווניות, הפיסוק והמספרים נשמרים תקינים בכל פונט עברי שתבחרו, ואפשר גם לייצא את אותו טראק ל-SRT.
רוצים כתוביות בעברית שלא נשברות?
Captain Cut כותב כתוביות ישירות לפרמייר עם RTL אמיתי — כיוון, מיקום פיסוק, מספרים ושורות מעורבות. 7 ימי ניסיון חינם בכל התוכניות, אפשר לבטל בכל שלב.
התחילו בחינם