המרתי דוח שני עמודים ל-Word כדי לבדוק משהו, והפסקה השנייה חזרה כך:
ההכנסות עלו במספר העובדים השלישי צמחו בארבעה, רבעון על גב שניים כולם בתמיכה. החידושים הגדולים של גיוס חתמו בתוכנית לרבעון הרביעי באוגוסט. השוליים הוחזקו שטוחים. הוא ללא שינוי בשישה תפקידים.
שתי עמודות של פרוזה רגילה לחלוטין, נקראות על פני המרזב שורה אחר שורה, כך שכל משפט נקשר למשפט שלידו. שום דבר לא נשבר. הממיר עשה בדיוק מה שממיר יכול לעשות, והפער בין זה לבין מה שהביטוי "pdf ל-word" מבטיח הוא כל הנושא של המדריך הזה. כל פלט שצוטט להלן הגיע מהפעלת ההמרה, לא מתיאורה.
TL;DR: PDF מאחסן גליפים בקואורדינטות. הוא אינו מאחסן פסקאות, עמודות, טבלאות או כותרות, ולכן ממיר צריך להסיק אותם ממיקומים, וחלק מהמסקנות הללו שגויות בדרכים שאתה יכול לחזות. נמדד בדוח בדיקה: שתי עמודות משולבות שורה אחר שורה, טבלת ארבע שורות פחוסה לשורה אחת קריאה "אזור Q2 Q3 EMEA 412 455 Amer 388 401 APAC 120 166", כותרת ממוזגת לפסקה שמתחתיה, ודף ללא שכבת טקסט לא לא הפיק כלל כלום. מה שאתה מקבל בחזרה באופן אמין הוא פרוזה ניתנת לעריכה בסדר דפים, שלרוב העבודות זה מה שרצית. כְּכ ממיר PDF ל-Word עושה את זה בדפדפן, כך שהמסמך לא מועלה.
מה מאוחסן בתוך PDF?
הוראות לצביעת דף, לא מסמך.
זרם תוכן של PDF אומר דברים כמו "הגדר את הגופן הזה בגודל הזה, עבור ל-x 60, y 720, הצג את הגליפים האלה". כְּכ מפרט עצמו הוא תיאור של דגם ציור, ומפעילי הטקסט יושבים לצד אלה לציור קווים ומילוי צורות. אין אובייקט בקובץ שפירושו "פסקה", אין אובייקט שפירושו "זהו טבלה", ושום דבר שמתעד ששני בלוקים של טקסט הם עמודות ולא אחת רחבה. הפורמט עוצב כך שעמוד מודפס באופן זהה בכל מקום, והוא משיג זאת על ידי תיאור העמוד כסימנים ולא כתוכן.
אז ממיר מקבל רשימה של ריצות ממוקמות. pdf.js, המנתח שזה פועל עליו, מחזיר אותם בדיוק כשהדף מצייר אותם. בקובץ הבדיקה, עמוד ראשון הפיק 34 מהם ועמוד שני הפיק 4. כל ריצה היא מחרוזת עם X, Y, רוחב וגובה גופן, והסדר שבו הם מגיעים הוא הסדר שבו צויר העמוד, וזה לא בהכרח הסדר שהיית קורא אותם.
כל מה שמסמך Word צריך שאין ל-PDF, הממיר צריך לשחזר מארבעת המספרים האלה. השחזור הזה הוא כל מה שאחריו, כולל בכל מקום שהוא משתבש.
איך ממיר בונה מחדש פסקאות מקואורדינטות?
בשני מעברים, עם סף על כל אחד.
קבוצות המעבר הראשונות נכנסות לשורות לפי קו בסיס: ריצות שערכי ה-y שלהן יושבים בטווח של חצי גובה גופן אחד מהשני הם שורה אחת. השני מקבץ שורות לפסקאות לפי הפער האנכי ביניהן. פער גדול מ-1.45 בערך מהמרווח הרגיל של השורות מתחיל פסקה חדשה, כאשר "רגיל" הוא הפער החציוני באותו עמוד ולא מספר קבוע, כך שהכלל מסתגל למסמך שנקבע ב-9 נקודות או 14 נקודות.
יש סף שלישי בתוך קו. PDF.js לעתים קרובות מפצל מילה בודדת על פני מספר ריצות ללא פער ביניהן, כך שההצטרפות פועלת על רווח הופכת את "שם הקובץ" ל- "F i l e n a m e". התיקון הוא להכניס רווח רק כאשר הפער האופקי חורג מרבע מגובה הגופן, שהוא בערך רוחב של רווח מילים אמיתי.
שלושת המספרים הללו מחליטים כמעט הכל על הפלט. כשהתוצאה טובה, הם צדקו. כאשר כותרת נדבקת לפסקה שמתחתיה, הפער היה מתחת לפי 1.45 מהחציון והכלל אמר פסקה אחת.
מדוע יוצאים שני עמודים משולבים?
כי הראיה היחידה לעמוד היא פער אופקי, וקיבוץ הקו מסתכל תחילה על המיקום האנכי.
שני הבלוקים בדף הבדיקה שלי עמדו על x 60 ו-x 320, עם השורות שלהם על קווי בסיס משותפים. הקיבוץ ראה שישה קווי בסיס, כל אחד נושא טקסט משני הצדדים, וקרא כל אחד מהם. התוצאה היא הפסקה בראש המדריך הזה: כל שורה בעמודה השמאלית ואחריה מיד השורה שלידו.
זהו אותו כשל כמו עמודות מקושקשות ב-OCR, ויש לו את אותו שורש: סדר קריאה הוא שיפוט לגבי פריסה, העשויה מגיאומטריה, על ידי משהו שאינו יכול לקרוא.
ממירים המטפלים היטב בעמודות בצעו שלב פילוח עמודים תחילה, מחפשים פס אנכי עקבי של רווח לבן המריץ את גובה העמוד ומפצלים את העמוד שם לפני כל קיבוץ שורות. זה עובד על עיתון או עיתון יומן, שבו המרזב רחב וקבוע. זה פחות אמין במקרים הנפוצים, שבהם סרגל צד, ציטוט משיכה או טבלת שתי עמודות שוברים את הרצועה.
אם למסמך שלך יש עמודות, התשובה המעשית היא לבדוק את הפלט ולתקן את הפסקה הראשונה של כל עמוד, או להמיר עמודה בכל פעם אם המסמך ארוך מספיק כדי להיות שווה את זה.
מה קורה לשולחן?
זה הופך למשפט.
לקובץ הבדיקה שלי הייתה טבלת ארבע שורות עם שלוש עמודות. הנה כל זה לאחר ההמרה:
Region Q2 Q3 EMEA 412 455 AMER 388 401 APAC 120 166
כל ערך שרד. המבנה לא. אתה לא יכול לדעת מהשורה הזו ש-412 הוא דמות ה-Q2 של EMEA מבלי לספור מיקומים ולדעת את צורת המקור.
הסיבה היא שרוב קובצי ה-PDF אינם מכילים גם טבלאות. טבלה ב-PDF היא בדרך כלל טקסט מצויר בקואורדינטות עם כמה קווים מצוירים סביבו, והקווים הם פעולות גרפיות שאין בהן שום דבר בקובץ המחבר אותן לטקסט שהן מקיפות. ממיר יצטרך לזהות את יישור המספרים, להסיק רשת ולהחליט אילו ריצות שייכות לאיזה תא, שהיא בעיה מחקרית ולא ניתוח.
חלק מקובצי PDF אכן נושאים מבנה אמיתי, דרך תגים שנוספו לצורך נגישות, ואלה ממירים הרבה יותר טוב. הם מיעוט: קובצי PDF מתויגים מגיעים מיצוא זהיר של Word או InDesign, לא ממנהל התקן הדפסה.
אם הטבלה היא הדבר שאתה רוצה, העתק אותה לגיליון אלקטרוני ביד, או המר את ה-PDF לטקסט ועצב אותו מחדש שם. קובץ Word שהומר לא ייתן לך תאים.
מדוע הכותרת שלי התמזגה לפסקה?
כי החלל מתחתיו לא היה גדול מספיק כדי להכשיל את כלל הפסקה.
בעמוד השני של קובץ הבדיקה, הכותרת "הערות" ישבה 40 נקודות מעל הטקסט בעוד קווי הגוף היו במרחק של 18 נקודות זה מזה. הפער הזה הוא פי 2.2 מרווח השורות, שהיה צריך לפצל אותם, והוא לא קרה, כי הפער החציוני בדף עם ארבע ריצות בלבד אינו אומדן מהימן של דבר. הפלט היה:
Notes Note 14 covers intercompany revenue and the treatment of
deferred items carried over from the prior year.
זו הצורה הכנה של כל הבעיה. חוקי סף עובדים היטב על דף עם מספיק טקסט כדי לבסס קצב בסיס ודל על קצב דליל. עמוד שער, הערה קצרה, גיליון שער או טופס יחזרו לרוב כפסקה אחת.
זה גם הדבר הכי קל לתקן לאחר מעשה. כותרות ברורות לקורא אנושי, ולחיצה על Return במקום הנכון לוקחת שנייה, שזה פחות זמן מכל כלי שייקח כדי לעשות את זה נכון.
מה קורה לדף סרוק?
שום דבר לא יוצא, וזו ההתנהגות הנכונה.
בעמוד השלישי של קובץ הבדיקה שלי לא הייתה שכבת טקסט בכלל, רק מלבן אפור עומד לסריקה. PDF.JS החזיר אפס ריצות והממיר הפיק עבורו אפס פסקאות.
העמוד עדיין נספר. הוא מופיע בקובץ Word כעמוד ריק, כך שהעמוד נשבר לאחר שהוא נשאר מיושר עם המקור, מה שחשוב כשמישהו עובד ממספרי עמודים. ממיר שהפיל אותו בשקט יעבור כל עמוד מאוחר יותר באחד.
PDF שכל הדפים שלו הם כל התמונות הוא סריקה, ואף ממיר לא יכול לחלץ ממנו טקסט כי אין טקסט לחלץ. מה שזה צריך הוא OCR, שקורא את התמונה של האותיות והניחושים של התווים, ואשר מביא שיעור שגיאות משלו. הגרסה המדודה של המסחר הזה נמצאת המדריך על מה שובר OCR: הטיה מעבר לשלוש מעלות זה מה שהורס סריקה, לא רזולוציה.
כלל אצבע שימושי: פתח את ה-PDF ונסה לבחור משפט עם הסמן שלך. אם הטקסט מדגיש, ממיר יכול לקרוא אותו. אם אתה מקבל מלבן בחירה על פני תמונה, אתה צריך קודם OCR.
מה יש בתוך ה-.docx שיוצא?
שלושה קבצים ב-zip, וזה באמת כל מה שצריך.
.docx הוא ארכיון כנס אריזה פתוח, סטנדרטי כ ECMA-376: zip המכיל חלקי XML בתוספת מניפסט האומר מהו כל חלק. של מיקרוסופט משלו סקירה כללית של הפורמט הולך על אותם שלושה חלקים. המינימום שנפתח כמסמך Word הוא שלושה ערכים:
| חלק | מטרה |
|---|---|
[Content_Types].xml |
מכריז על סוג המדיה של כל חלק בחבילה |
_rels/.rels |
נקודות בחלק המסמך הראשי |
word/document.xml |
התוכן עצמו |
כל השאר שקובץ Word נושא בדרך כלל, סגנונות, גופנים, ערכות נושא, הגדרות, הגדרות מספור, הוא אופציונלי. השאר אותם בחוץ והקורא מחיל את ברירות המחדל שלו.
מסמך הבדיקה, 83 מילים על פני שלושה עמודים, הגיע ל-1,305 בתים .docx של מי word/document.xml הוא 1,169 בתים. פתחתי אותו עם קורא המסמכים של אפל, שזה מה ש-TextEdit ו-Pages משתמשים בו, וזה עשה כל פסקה לפי הסדר עם מעבר העמוד ללא פגע. חבילה מינימלית אינה מושפלת.
פרט אחד בכך ש-XML חשוב יותר ממה שהוא נראה. כל ריצה נכתבת עם xml:space="preserve". בלעדיו, ריצה שמתחילה או מסתיימת ברווח מאבדת אותו, וכל שורה שהייתה עטופה במקור חוזרת עם המילה האחרונה שלה מחוברת למילה הבאה.
מה קורה לתמונות?
הם נשמטים, וקובץ Word לא מזכיר זאת.
החבילה הכתובה כאן כוללת שלושה חלקים ואף אחד מהם אינו חלק תקשורתי. לוגו, תרשים, חתימה סרוקה, צילום מסך המוטבע בדוח: הכל נעלם, ללא מציין מיקום היכן הם היו. הטקסט שהקיף אותם נסגר כאילו מעולם לא היו שם.
זוהי תוצאה של אותו עיצוב שהופך את הפלט לקטן ואמין. נשיאת תמונה על פניה פירושה חילוץ שלה מה-PDF, להחליט על הפורמט שלה, לכתוב אותה לתוכו word/media/, הוספת סוג תוכן עבורו, הוספת חלק קשר והצבת אלמנט ציור בנקודה הנכונה בזרימה. כל אחד מאלה הוא מקום לקורא לדחות את הקובץ, ומעבד .docx שמעבד תמלילים מסרב לפתוח גרוע יותר מאחד שחסר לו לוגו.
זה הכי חשוב עבור המסמכים שבהם תמונה היא התוכן ולא הקישוט. תרשים בדוח ממיר לכלום, ולקורא של קובץ Word אין דרך לדעת שתרשים היה שם אי פעם. בדוק את המקור לצד ההמרה כאשר מתייחסים לדמות בפרוזה.
למה הקובץ לפעמים מסרב להיפתח בכלל?
תווי שליטה, ש-XML אוסר וקובצי PDF מכילים.
שכבת טקסט של PDF קולטת תווים מכל מה שיצר אותו: FORM FEED FE FED מצינור הדפסה, בתים אפסים מקידוד שבור, קודי בקרה אחרים של C0 שלא אומרים כלום במסמך. XML 1.0 לא מאפשר את רובם, אפילו בריחה: טווח התווים שהמפרט מאפשר מתחיל בכרטיסייה, קו חדש וחזור עגלה ומדלג על שאר הבלוק C0.
הכישלון אינו חינני. Word לא מזהיר או מפיל את התו; הוא מסרב לפתוח את הקובץ ואומר שהתוכן אינו קריא. אז הממיר מפשיט את התווים האלה לפני הכתיבה, במקום לנסות לברוח מהם. לא היה להם משמעות במקור והם יעלו לך את כל המסמך.
אם אי פעם תקבל .docx שמעבד תמלילים דוחה כלא קריא, זה הדבר הראשון שיש לחשוד בו, וזו הסיבה שכותב ממיר XML ביד צריך לחשוב על זה בכלל.
האם כדאי להמיר ל-Word או לטקסט רגיל?
מילה אם אתה מתכוון לערוך אותו, שלח הודעה אם אתה מתכוון לעבד אותו.
הם חולקים את אותה מיצוי. ההבדל הוא רק מה שנכתב בסוף: אחד כותב פסקאות ל-zip של xml, השני כותב אותם לקובץ .txt.
| אתה רוצה ל | להשתמש | בגלל |
|---|---|---|
| ערוך את הפרוזה ושלח אותה הלאה | pdf למילה | מבנה פסקה, מעברי עמודים, משהו שעמית יכול לפתוח |
| חפש, grep או הזן אותו לתסריט | PDF לטקסט | אין סימון בדרך |
| שמור על הפריסה בדיוק | גם לא | ערוך את ה-PDF, או קבל את הקובץ המקורי |
| קרא סריקה | OCR ראשון | אין שכבת טקסט לחלץ |
השורה השלישית היא זו ששווה לשבת איתה. אם הפריסה היא מה שחשוב, המרה ל-Word היא בכיוון הלא נכון, מכיוון שההמרה היא המקום שבו הפריסה אובדת. שאל את מי ששלח את ה-PDF עבור הקובץ שממנו יצא. זה לוקח הודעה אחת וזו הגישה היחידה ששומרת על העיצוב.
כמה זמן לוקחת ההמרה?
מספיק זמן כדי לקרוא את הקובץ, ולא עוד.
אין שלב קידוד ואין עיבוד תמונה. העבודה מנתחת את מבנה ה-PDF, משיכת תוכן הטקסט של כל עמוד, קיבוץ ריצות וסידור XML ב-ZIP. קובץ הבדיקה לקח כמה אלפיות שניות, וזה לא מספר שימושי כי זה היה שלושה עמודים. דוח של מאתיים עמודים מוגבל על ידי PDF.JS המנתח אותו, שהוא בערך ליניארי במספר העמודים ומהיר.
מה שאתה כן מבחין במסמך גדול הוא זיכרון, מכיוון שהקובץ כולו מוחזק בלשונית הדפדפן יחד עם המבנה המנותח. זו התקרה האמיתית כאן ולא המהירות.
מה כדאי לבדוק בפלט?
ארבעה דברים, לפי הסדר הם צפויים לטעות.
- הפסקה הראשונה של כל עמוד. כאן מופיעים מיזוגים של שזירה וכותרות של עמודות.
- כל שולחן. אשר שהמספרים קיימים, ואז קבל שהרשת נעלמה ובנה אותה מחדש אם אתה צריך אותה.
- מילים מקוף בקצוות השורה. מילה שנשברה על פני שורה ב-PDF חוזרת עם המקף באמצעו.
- ספירת עמודים. זה צריך להתאים למקור, כולל כל דפים ריקים או סרוקים.
הרשימה הזו לוקחת דקה על מסמך של עשרה עמודים והיא ההבדל בין קובץ שאתה יכול לשלוח עליו לבין קובץ שמכיל בשקט משפט שחבור.
למה זה פועל בדפדפן?
מכיוון שהמסמכים שאנשים ממירים הם חוזים, הצהרות, מכתבים, תוצאות רפואיות ודברים תחת אמברגו.
ההמרה היא ניתוח וריכס, שניהם דפדפן מצליחים לחלוטין. הקובץ נקרא מהדיסק שלך לתוך הדף, מנותח שם עם pdf.js הידור עבור האינטרנט, מורכב ל-.docx בזיכרון, ומוחזר כהורדה. שום בקשה לא נושאת את המסמך, שום דבר לא מאוחסן בשרת, ושום דבר לא קיים כדי שמישהו ימחק מאוחר יותר.
האלטרנטיבה הרגילה היא אתר שלוקח את ה-PDF שלך, ממיר אותו במכונה שאינך יודע עליה דבר ושולח לך קישור במייל. עבור עלון ציבורי זה בסדר. עבור חוזה עבודה זו החלטה שלא התבקשת לקבל במודע.
העלות היא הזיכרון של ה-TAB בקבצים גדולים מאוד, וללא OCR בצד השרת עבור דפים סרוקים. שניהם גבולות גלויים ולא שקטים, וזה המסחר ששווה לעשות.
