רוב מחלצי ה-PDF משתמשים ב-API הלא נכון
רוב כלי ה-PDF משתמשים במקור הנתונים הלא נכון.
כשמפתחים מדברים על חילוץ PDF, הם בדרך כלל מתכוונים ל-getTextContent(). מתודה זו מספקת פריטי טקסט ואת המיקומים שלהם. זהו ברירת המחדל כמעט עבור כל כלי בצד הדפדפן.
אך getTextContent() הוא תצוגה מעובדת. זוהי גרסה מפושטת של מה שזמין בפועל.
ישנן שלוש רמות של נתונים ב-PDF.js:
• getStructTree(): זה אומר לכם מה המשמעות של המסמך. הוא מכיל טבלאות, כותרות ונוסחאות.
• getOperatorList(): זה אומר לכם מה המסמך מצייר. זה כולל קווים, נתיבים (paths) וצורות.
• getTextContent(): זוהי תצוגה מסוננת של מה שהמסמך מצייר.
רוב הכלים משתמשים באפשרות השלישית. זה עובד עבור 80% מהמסמכים, כמו דוחות פשוטים. עם זאת, זה נכשל במאמרים אקדמיים ובפרסומים מורכבים.
שימוש ב-getTextContent() בלבד יוצר ארבע בעיות עיקריות:
- אתם מאבדים את מבנה הטבלאות. אתם נאלצים לנחש היכן נמצאות התאים על בסיס מיקומי הטקסט.
- אתם שוברים משוואות מתמטיות. משוואות LaTeX מופיעות לעיתים קרובות כבלוקים טקסטואליים בודדים וענקיים.
- אתם מפספסים קווי עמודות. פריסות רבות משתמשות בקווים ממשיים כדי להפריד בין עמודות. הקווים הללו אינם קיימים בתוכן הטקסט.
- אתם מקבלים סדר קריאה שגוי. טקסט מופיע לעיתים קרובות בסדר שבו הוא צויר, ולא כפי שאדם קורא אותו.
הדרך הנכונה לבנות מעבד PDF היא מערכת בעלת שלוש שכבות:
- בדקו קודם כל את
getStructTree(). אם למסמך יש מבנה לוגי, השתמשו בו כדי למצוא טבלאות וכותרות באופן מיידי. - בדקו לאחר מכן את
getOperatorList(). השתמשו בקווים ובנתיבים מפורשים כדי למצוא גבולות עמודות. - השתמשו ב-
getTextContent()כגיבוי. השתמשו במתמטיקה גיאומטרית רק כאשר שתי השכבות הראשונות אינן מספקות נתונים.
הגישה הזו אינה דורשת יותר עבודה. שכבות 1 ו-2 פועלות כ"יציאות מהירות". אם המסמך בנוי היטב, אתם מדלגים על המתמטיקה הקשה. אתם משתמשים בהסקה מורכבת רק כאשר המסמך אינו מתויג.
ארכיטקטורה זו מטפלת הן בקבצים ארגוניים פשוטים והן במאמרים מדעיים מורכבים.
מקור: https://dev.to/bonzai2carn/most-pdf-extractors-use-the-wrong-api-heres-what-we-built-instead-5dgh