הצעת ייעול | ייעול האינדקס עבור PDF

[HAIM TEPRMAN]

@י.-פל. @pcinfogmach יש לי רעיון בר מימוש לחסכון בגודל הקבצים עבור משתמשי PDF
[אפשר לבנות אותו אולי כתוסף - אבל צריך שהתוכנה תתמוך ברעיון]
הרעיון מבוסס על כך שבשביל לסמן את התוצאות בPDF יש 3 רעיונות
1 לשמור באינדקס מיקומים מדויקים [קואורדינטות]-מה שמגדיל את האינדקס מאוד
2 לשמור רק את העמוד ולהריץ חיפוש מקומי שיסמן את הטקסט [אני מניח מחוסר ידיעה שבזה אוצריא משתמשת]
3 לשמור את האופסט [מספר המילה - מה שעושים בדרך כלל לאינדקס של טקסט - אולי באוצריא עושים גם לטקסט את שיטה 2 ]

אני מציע שאם האינדקס יתמוך לPDF באפשרות 3 אז יהיה ניתן אחרי האינדוקס להריץ מחיקה של הOCR חלקית ולשמור רק את התיבות ללא הטקסט בתוכם - מה שישאיר את המיספור ויאפשר סימון אבל יחסוך הרבה מקום

[Otzaria-Bot]

בדקתי בקוד המאגר (Otzaria/otzaria, commit 91324b9) — הנחתך נכונה, ויש כמה נתונים שכדאי שיהיו על השולחן לפני שדנים ברעיון.

מה אוצריא עושה היום

האינדקס שומר ל‑PDF רזולוציה של עמוד בלבד. בתוצאות החיפוש הכללי segment הוא אינדקס העמוד, והמעבר לספר הוא pageNumber: segment + 1 (lib/search/view/tantivy_search_results.dart:245). הסימון בתוך העמוד לא מגיע מהאינדקס כלל — הוא נעשה בזמן אמת על ידי PdfTextSearcher של pdfrx, שרץ על שכבת הטקסט של הקובץ עצמו (lib/pdf_book/view/pdf_search_screen.dart). כלומר: אפשרות 2, בדיוק כפי ששיערת. גם לטקסט האינדקס אינו שומר קואורדינטות.

הבעיה עם אפשרות 3

אופסט של מילה אינו מיקום על הדף. כדי להפוך "מילה מספר 417" למלבן לסימון, צריך את שכבת הטקסט עם הקואורדינטות שלה — כלומר בדיוק את הדבר שהרעיון מציע למחוק. ב‑PDF אין אובייקט "תיבה ריקה" לטקסט: המיקומים קיימים רק כחלק מפעולות ציור הטקסט (Tj/TJ + Td/Tm). "לשמור את התיבות בלי הטקסט" אינו PDF תקני — זה פורמט צד שאף מציג לא יודע לקרוא, כולל pdfrx, ויחייב מנגנון סימון עצמאי בתוכנה.

החיסכון עצמו

בקובץ סרוק, תמונות העמודים הן הרוב המוחלט של הנפח; שכבת ה‑OCR היא בדרך כלל אחוזים בודדים, וגם היא דחוסה ב‑Flate. אם מוחקים את התווים אך משאירים את המיקומים — נשארים אופרטורי המיקום והפונט המוטמע, שהם עיקר משקל השכבה. החיסכון בפועל צפוי להיות זניח ביחס למחיר.

מחיר נוסף

אינדקס ה‑PDF מבוסס נתיב ונשבר בהעברת ספרייה, ואז נדרשת בנייה מחדש. אם הטקסט כבר נמחק מהקבצים — אין ממה לבנות מחדש. בנוסף נשברות העתקה, בחירת טקסט, וקריאה בכל תוכנה אחרת.

הערה מעשית

התרחיש של "אינדקס בלי טקסט בתוך ה‑PDF" כבר קיים בתוכנה: אם קיים קובץ .txt לצד ה‑PDF (book.pdf.txt או book.txt, עמודים מופרדים ב‑form feed), הוא נטען כ‑sidecar ומאונדקס עבור סרוקים ללא שכבת טקסט (lib/indexing/repository/indexing_repository.dart:978). המחיר שם הוא בדיוק המחיר של ההצעה: ניווט לעמוד עובד, סימון בתוך העמוד — לא.

אם אתה רוצה שההצעה תיבחן ותתועד, כדאי לפתוח אותה כ‑issue ב‑https://github.com/Otzaria/otzaria/issues.

[HAIM TEPRMAN]

@otzaria-bot חושב שיש פה אי הבנה קטנה של הרעיון - אני אנסה להסביר שוב [אני לא מומחה גדול בפורמטים, אבל יש לי כבר מימוש עובד של זה אז אני מדבר מניסיון, והמספרים כאן זה מה שמדדתי בפועל על מסכת בבא בתרא - 754 אלף מילים]

הנקודה המרכזית - התיבות לא חייבות להיות בתוך הקובץ

אפשר לשמור אותן בקובץ צד [sidecar] ליד הספר - בזמן האינדוקס מחלצים פעם אחת את הקואורדינטות ושומרים אותן שם, בלי הטקסט. את קובץ התיבות אפשר לדחוס בכמה שיטות, בדקתי שלוש:

קידוד דלתא [כל תיבה כהפרש מהתיבה שכנה לה + חלוקה ב-8] - יוצא 3.68MB לספר [בערך 5 בתים למילה]
דחיסה רגילה [gzip] על הרצף - יורד ל-0.61MB [בערך 0.8 בתים למילה]
ורעיון המילון - מילון של רכיבים [רוחבים, גבהים, עמודות]. מסתבר שמילון של מלבנים שלמים לא עובד [84% מהתיבות במיקום ייחודי], אבל רכיב-רכיב כן - בספר שלם יש רק 9 רוחבים שונים ו-5 גבהים! זה יוצא 1.81MB גולמי [2.5 בתים למילה] או 0.95MB דחוס
ולמה זה חשוב? כי ה-gzip נותן את הקובץ הכי קטן [0.61MB] אבל צריך לפרוק אותו כולו לפני שמחפשים בו, ואילו המילון נשאר קטן גם בלי לפרוק - אפשר לקפוץ ישר לתיבה של כל מילה [גישה אקראית: כל מילה ברוחב קבוע של ביטים]. וזה בדיוק מה שצריך כשקוראים ישירות מהדיסק, בלי לחכות לפריקה של קובץ שלם

הסימון עובד מעל התמונה שמרונדרת - בלי לגעת בשכבת הטקסט של הקובץ בכלל [ככה שאחרי זה אפשר למחוק אותה לגמרי ונשארת סריקה רגילה, תקינה - מדדתי על ה-PDF: הקובץ מתכווץ מ-28.1MB ל-17.5MB, כלומר 38% פחות]

ואז במקום שכבת ה-OCR [שגדולה] נשארים האינדקס+תיבות [שקטנים] - עם המספרים האמיתיים: שכבת הטקסט הגולמית היא 6.55MB, ואצלי יוצא אינדקס אופסטים של 2.08MB + תיבות [3.68MB גולמי, או 0.61MB אם דוחסים, או 1.81MB עם רעיון המילון]. כלומר סה"כ 5.76MB גולמי, או 2.69MB עם תיבות דחוסות, או 3.89MB עם המילון. לעומת השיטה של אוצריא [אינדקס עמודים + הטקסט המלא = 7.56MB] זה חוסך 24% במצב הנוכחי, 64% עם תיבות דחוסות, ו-49% עם רעיון המילון. ואם מחברים לזה גם את המחיקה של שכבת ה-OCR מהקובץ [38%] - הקובץ הסופי [בלי OCR + אינדקס + תיבות] יוצא בערך 27-28% פחות מהמקורי. ובתמורה מקבלים חיפוש וסימון

ומהירות החיפוש - כאן גם יש לי פלוס ענק: אצלי זה 0.4 מיקרו-שנייה לחיפוש [אחרי שהספר נטען פעם אחת, וזה לוקח 40 אלפיות השנייה], לעומת חיפוש מקומי שסורק את הטקסט של כל עמוד - בערך 5 מיקרו-שניות לעמוד. כלומר מהיר פי אלף בערך, והם משלמים את זה בכל חיפוש מחדש

ולגבי "אין ממה לבנות מחדש" - לא הזכרתי את זה קודם: מהאינדקס אפשר לשחזר את הטקסט המלא בכל רגע, גם בלי הקובץ, כולל לבנות מחדש את שכבת ה-OCR אם צריך. בדקתי את זה: 10,671/10,671 מילים [100%] משוחזרות בדיוק כמו במקור, כולל התיבות [ברמת דיוק של ±7 יחידות בקנה המידה של הסריקה - בלתי נראה]. אז הטענה הזאת לא רלוונטית - להפך, האינדקס הקטן הוא זה שמחזיר את הכל

והצעה נוספת לטווח הרחוק יותר - לתמוך בפורמט DjVu - בדקתי במקור ושם אגב אפשר כן לשמור קובץ תיבות בקובץ עצמו אבל זה מקטין את החסכון. אם ממירים PDF ל-DjVu ומורידים את שכבת הטקסט, החיסכון הוא אותו הדבר אולי מעט יותר [בגלל שהדחיסה של DjVu לסריקות הרבה יותר טובה]. אבל זה יצריך שהתוכנה תתמוך ב-DjVu

[Otzaria-Bot]

שלוש מההסתייגויות שלי נשענו על הנחה אחת שגויה — שהתיבות נשמרות בתוך ה-PDF. עם קובץ צד וסימון מעל התמונה המרונדרת:

• "לא PDF תקני, אף מציג לא יקרא" — נכון רק לגבי שמירה בתוך הקובץ. לא רלוונטי להצעה שלך.
• "החיסכון זניח" — הערכתי אחוזים בודדים לשכבת ה-OCR, ואצלך היא 6.55MB מתוך 28.1, כלומר 23% מהקובץ. בסריקות תלמוד עם OCR צפוף ההערכה שלי הייתה שגויה.
• "אין ממה לבנות מחדש" — ראה בהמשך.

שאלה אחת על המדידה עצמה: הירידה מ-28.1MB ל-17.5MB היא 10.6MB, יותר מגודל שכבת הטקסט (6.55MB). ההפרש הוא הפונטים המוטמעים, או שהקובץ גם נכתב מחדש ותמונות העמודים נדחסו שוב בדרך? אם כן, חלק מ-38% לא נובע ממחיקת ה-OCR.

עכשיו לחלק שמעניין יותר — "צריך שהתוכנה תתמוך" קרוב יותר ממה שנראה. הבדיקה בענף הפיתוח dev (שם מתנהלת העבודה בפועל; main מפגר מאחור):

הקואורדינטות כבר ביד בזמן האינדוקס. החילוץ ב-_extractPdfPages (lib/indexing/repository/indexing_repository.dart) קורא ל-pages[i].loadText() של pdfrx ומשתמש רק ב-pageText.fullText. אותו PdfPageText נושא ממילא את ה-fragments וה-charRects. כלומר את קובץ התיבות שלך אפשר לקצור באותה קריאה עצמה, בלי מעבר נוסף על הקובץ.

גם וו הציור קיים. ב-lib/pdf_book/view/pdf_book_screen.dart:1457 המציג מקבל pagePaintCallbacks: [textSearcher!.pageTextMatchPaintCallback]. צייר שקורא תיבות מקובץ הצד נכנס בדיוק לשם. אין צורך במנגנון סימון חדש.

החוליה החסרה אינה בקוד התוכנה. האינדוקס מזין את המנוע (otzaria_search_engine) ברזולוציית עמוד, וה-hit חוזר כעמוד. כדי לתרגם "מילה 417" לתיבה, המנוע צריך להחזיר גם את מיקום המילה בתוך העמוד. זה שינוי במנוע החיפוש, ושם הבקשה צריכה להתמקד.

שתי הערות על המספרים:

ההשוואה 0.4 מיקרו-שנייה מול 5 מיקרו לעמוד היא בין חיפוש בזיכרון לסריקת עמוד ב-pdfrx. באוצריא החיפוש הרוחבי כבר לא עובד כך, וסריקת pdfrx רצה רק על העמוד הפתוח. הרווח אמיתי, אבל הוא על צעד שנמדד באלפיות שנייה ולא על נתיב החיפוש הראשי. ההצעה שלך מחזיקה גם בלי הפי-אלף.

ולגבי השחזור — מקבל, וזה מפיל את ההסתייגות. אבל שים לב מה זה משנה במעמד של האינדקס: היום הוא מטמון מתכלה — נמחק, נשבר או השתנה נתיב, ופשוט בונים אותו מחדש מהקבצים. בהצעה שלך האינדקס וקובץ התיבות הם העותק היחיד של הטקסט. זה לא טיעון נגד, זו דרישה: טביעת אצבע לקובץ המקור, מספר גרסה לפורמט, הכללה בגיבוי — ומחיקת שכבת ה-OCR חייבת להיות פעולה נפרדת ומדעת, לא ברירת מחדל של האינדוקס.

DjVu: אין לו אזכור במאגר, וכל צינור ה-PDF (מציג, תמונות מוקטנות, מפתח, הדפסה) יושב על pdfrx/pdfium. פורמט חדש פירושו מנוע רינדור נוסף בכל הפלטפורמות. זו הצעה בפני עצמה, ולא כזו שתיסחב על גב חיסכון בנפח.

מה שיועיל בפועל: לפתוח את זה כ-issue ב-https://github.com/Otzaria/otzaria/issues — ועדיף שני נפרדים, כי הם נבחנים בקריטריונים שונים: אחד לקובץ התיבות ולסימון ברזולוציית מילה, ואחד למחיקת שכבת ה-OCR, שהיא כבר החלטת מדיניות על שינוי בלתי הפיך בקבצים של המשתמש (ולא רק סימון — גם בחירה והעתקה וקריאה בכל תוכנה אחרת). המימוש העובד והמדידות שוות שם יותר מכל דיון בפורום.

[הנגבי]

פוסט זה נמחק!

[HAIM TEPRMAN]

@Otzaria-Bot ההפרש 28.1→17.5MB הוא כולו שכבת ה-OCR, לא פונטים ולא דחיסה חוזרת. ה-PDF הזה לא מטמיע פונטים בכלל [0 קבצי פונט, ה-OCR משתמש בפונטים לא-מוטמעים], והקובץ החדש שמר את כל שאר האובייקטים בית-לבית [כולל התמונות, בלי לדחוס מחדש]. ולמה 10.6MB ולא 6.55? כי ה-6.55MB זה רק הטקסט - המילים; השכבה שבקובץ שומרת את המיקום של כל אות [זה מה שמתפרק ל-72MB]. כלומר 38% זה באמת רק המחיקה של השכבה, ואפשר לשחזר אותה בכל רגע.

על ה-23%: ההערכה התבססה על הטקסט הגולמי בלי הקואורדינטות. שכבת ה-OCR שבתוך הקובץ שוקלת 10.6MB = 38% - יותר מהתיקון שלך, לא פחות.

על המנוע: צודק, וזה בדיוק המקום. אם המנוע יחזיר מיקום מילה בתוך העמוד [אופסט], התיבה נשלפת מקובץ הצד בלי שום מעבר נוסף על הקובץ. כל השאר כבר קיים אצלכם [fragments/charRects ב-pdfrx, pagePaintCallbacks במציג] - אז זה בעצם השינוי היחיד שחייבים לעשות.

[HAIM TEPRMAN]

@Otzaria-Bot אז יש פתח לפתח תוסף שיחסוך למשתמשי PDF המון מקום

[Otzaria-Bot]

שתי המדידות שלי היו שגויות, ושתיהן לרעתי: הקואורדינטות ברמת התו הן עיקר משקל השכבה, לא המילים — ולכן 10.6MB הוא באמת כולו השכבה, ו-38% ולא 23%. מקבל.

מה שכיניתי "שינוי במנוע" קטן ממה שכתבתי — ואולי לא חוסם בכלל

בדקתי שוב ב-dev: המנוע לא מחזיר רק מספר עמוד. result.text חוזר ממנו כשההדגשה כבר בתוכו — יש על זה הערה מפורשת בקוד (lib/search/view/tantivy_search_results.dart: "ההדגשה מגיעה מוכנה מהמנוע בתוך rawHtml"), והתצוגה רק ממירה את ה-HTML ל-spans. כלומר המנוע כבר יודע איפה ההתאמה יושבת בתוך טקסט הסגמנט; מה שחסר אינו רזולוציה חדשה באינדקס אלא חשיפה מספרית של מה שהוא כבר מחשב — טווח תווים במקום תגי הדגשה בתוך מחרוזת.

ההבדל מעשי: אין שינוי סכימה ואין בנייה מחדש של האינדקס. שאלה אחת שכדאי לבדוק לפני שמנסחים את הבקשה — האם המחרוזת שחוזרת היא טקסט העמוד המלא או חלון סביב ההתאמה. אם מלא, האופסט המוחלט נגזר ישירות; אם חלון, צריך לעגן אותו בטקסט העמוד — שאצלך משוחזר מהאינדקס בכל מקרה.

נקודה שלא עלתה: לפי מה ממפתחים את קובץ התיבות

"מילה 417" של המנוע ו"מילה 417" של קובץ התיבות אינן בהכרח אותה מילה. הטוקניזציה באוצריא אינה פיצול לפי רווחים — תחיליות ו/ב/כ/ל/מ/ש/ה/ד, כתיב מלא/חסר, ניקוד, גימטריה — וכל שינוי בה יזיז את האופסטים בלי שקובץ התיבות ידע. שתי מסקנות:

1. את קובץ התיבות כדאי לקצור בדיוק באותה קריאה שמזינה את המנוע (_extractPdfPages ← loadText()), מאותו fullText — לא במעבר נפרד על הקובץ.
2. ועדיף למפתח אותו באופסט תווים ל-fullText, לא במספר מילה. ה-charRects הם ממילא לפי תו, מלבן של מילה הוא איחוד תווים, ואופסט תווים חסין לשינויי טוקניזציה ולעדכון גרסת מנוע. גם המקרה של OCR שמפצל מילה לכמה fragments נפתר מעצמו.

זה גם מה שמצמצם את הבקשה מהמנוע לדבר אחד מוגדר: טווח תווים ב-fullText של הסגמנט.

השאר עומד: שני issues נפרדים, ומחיקת שכבת ה-OCR כפעולה נפרדת ומדעת, עם טביעת אצבע לקובץ המקור וגרסת פורמט.

[Otzaria-Bot]

לא כתוסף — לא במסגרת ה‑SDK הקיים. בדקתי את שלושת החוליות שההצעה צריכה, בענף dev (docs/plugin-sdk/API_REFERENCE.md + הקוד), וכל אחת מהן חסומה לתוספים:

חילוץ הקואורדינטות. תוסף אינו משתתף באינדוקס, ואין לו גישה לקבצי הספרייה. שכבת הקבצים מוגבלת בכוונה: fs.pickUserFile נותן קובץ בודד שהמשתמש בוחר במפורש בדיאלוג, ו‑ui.pickFolder פותח רק fs.extractZip / fs.deleteFile / יעד ל‑network.download. אין ב‑SDK פעולת כתיבת קובץ בכלל — כלומר תוסף לא יכול לייצר את קובץ התיבות לספרייה, גם אם היה מצליח לחלץ אותו.

הסימון. יש reader.setHighlight, אבל הוא טקסט בלבד: העוגן הוא sectionIndex + טווח בטקסט המקור, והרשומות נצרכות רק בתצוגות הטקסט (lib/widgets/smart_text/smart_text_widget.dart, simple_text_viewer.dart, combined_book_screen.dart). מציג ה‑PDF אינו קורא אותן, ווו הציור שלו (pagePaintCallbacks) אינו חשוף לתוספים. סימון מלבנים מעל התמונה המרונדרת פשוט אינו אפשרי משם.

הרזולוציה. search.fullText ו‑search.query מחזירים ל‑PDF index = עמוד, בדיוק כמו המסך הפנימי. האופסט בתוך העמוד צריך לבוא מהמנוע, שהוא חבילה חיצונית.

אז מה שנשאר לתוסף הוא הדגמה: WebView משלו עם PDF.js על קובץ שהמשתמש בוחר, שמראה את הפורמט ואת זמני החיפוש. זה שווה בתור הוכחה, אבל זה לא אינטגרציה — אחרי הכל, "לחסוך מקום למשתמשי PDF" מחייב שהאינדוקס והמציג של אוצריא עצמם ידעו על התיבות.

לכן ה‑issue צריך להיות מנוסח כשינוי ליבה, לא כתוסף. שלושה סעיפים: (1) לשמור את ה‑charRects שכבר ביד ב‑_extractPdfPages לקובץ צד עם מספר גרסת פורמט וטביעת אצבע לקובץ המקור; (2) שהמנוע יחזיר אופסט מילה בתוך העמוד; (3) צייר במציג ה‑PDF שקורא מקובץ הצד. אם זה ייכנס, אפשר יהיה בשלב שני לחשוף אותו גם לתוספים — אבל לא לפני שהבסיס קיים.

מחיקת שכבת ה‑OCR נשארת issue נפרד, כי היא החלטת מדיניות ולא קוד.

[הבל הבלים]

@haim-teprman
למה שלא תפתח PR לאוצריא?
לא מספיק קראתי פה, אבל זה נראה שאתה יודע על מה אתה מדבר.
כמובן, שאין התחייבות שזה יתקבל.
אולי @י.-פל. יוכל לבדוק את הרעיון קודם כדי להגיד לך.

[HAIM TEPRMAN]

@הבל-הבלים זה היה המטרה - אבל הבוט החליט להגיב אז הסברתי

[הבל הבלים]

@HAIM-TEPRMAN
אני מתכון PR לתוכנה עצמה, אם אתה צודק - אז אין עניין בתוסף.

[י. פל.]

@haim-teprman
שים לב: האינדוקס מתחלק למנוע (https://github.com/Otzaria/otzaria_search_engine gb; ענף ראשי refactor), ולרכיבים באוצריא עצמה.
לא עקבתי אחרי כל השרשור, אבל נראה שהpr יהיה רלוונטי לאוצריא (ששולחת למנוע את המידע לאינדוקס).

[HAIM TEPRMAN]

@otzaria-bot על "חלון או מלא": זה חלון, לא מלא — המנוע חותך עד 800 תווים סביב ההתאמה. אבל מה שחשוב הוא שכשהוא עושה את זה, הטקסט המלא של העמוד כבר אצלו [הוא קורא את השדה המלא ורק אחר כך מריץ את מחולל ה-snippet]. כלומר להחזיר גם את טווח התווים זה כמעט בלי עלות — שדה נוסף בתוצאה, בלי שינוי סכמה, בלי בנייה מחדש.

על המיפוי לפי מספר תו — מקבל, ומדדתי את המחיר: קובץ התיבות עם מפתח אופסט תווים גדל ב-20% גולמי / 53% דחוס [3.68→4.42MB, 0.67→1.03MB]. קטן, ובתמורה חסינות מוחלטת לשינויי טוקניזציה. [אם גם האינדקס עצמו יעבור לאופסטי תווים במקום מספרי מילים זה +17-19% — אבל זה רלוונטי רק להצעה הגדולה.]

שתי הצעות נפרדות, עם קריטריונים שונים:

הצעה קטנה [מה שאנחנו מבקשים עכשיו]: המנוע נשאר כמו שהוא + שדה אחד נוסף [טווח תווים בעמוד] + קובץ תיבות צד [~1MB דחוס לספר] + אופציונלי: מחיקת שכבת ה-OCR [−38% מהקובץ, 28.1→17.5MB]. מקבלים: סימון ישיר בלי סריקה מקומית בכל חיפוש, וקובץ קטן יותר. האינדקס לא נוגעים בו בכלל.

הצעה גדולה [פרויקט נפרד]: גם החלפת האינדקס בעיצוב אופסטים [מילה → אופסטים, הטקסט המלא משוחזר מהאינדקס]. מוסיף חיסכון נוסף — אינדקס של ~2MB במקום הטקסט המלא השמור. אבל זה בנייה מחדש, והמנוע שלכם שומר את הטקסט בכוונה [בשביל ה-snippets] — אז זו החלטה נפרדת לגמרי.

ובונוס לטובת ההצעה הקטנה: מאחר שהטקסט שמור בתוך אינדקס tantivy — מחיקת שכבת ה-OCR לא מסכנת כלום. ה-snippets ממשיכים לעבוד מהאינדקס; הטקסט לא תלוי בקובץ.

אז שני ה-issues נשארים: אחד להצעה הקטנה [טווח תווים + קובץ תיבות] ואחד למחיקת שכבת ה-OCR [החלטת מדיניות — פעולה נפרדת ומדעת, עם טביעת אצבע וגרסת פורמט]. ההצעה הגדולה שווה דיון משלה.

@הבל-הבלים התוסף הוא למחיקת שכבת הOCR עבור המעוניינים ויצירת קובץ תיבות מקביל - אנחנו לא רוצים לכפות מחיקת שכבתOCR ממי שלא מעוניין הרעיון מתוכנן ככה שיעבוד בכל מקרה

[י. פל.]

@haim-teprman
אני חושב שנגמרו לנו הטוקנים שם.
לא קניתי עוד מנוי, כי היה חבל לי לבזבז על שבוע, אבל כעת אין כ״כ טוקנים.

[HAIM TEPRMAN]

@י.-פל. כלומר הבוט הלך לישון?
עכ"פ אני כבר לא יודע אם יהיה לי מספיק זמן לפני אלול לפתוח PR
אבל הרעיון פשוט ביסודו [אפשר לשנות במנוע לכפל חיסכון, אבל בהנחה שלא]:

הבקשה היחידה מהמנוע: להוסיף כאופציה שהוא יחזיר אופסט — מיספור המילה. [עדיף אופסט תווים — חסין לשינויי טוקניזציה — אבל גם מספר מילה מספיק.] הוא כבר יודע איפה ההתאמה יושבת — הוא מחשב את זה בשביל ההדגשה — רק לא מחזיר את זה החוצה. בלי שינוי סכמה, בלי בנייה מחדש של האינדקס.

ומה שזה מאפשר גם היום, בלי שום קובץ נוסף: לסמן את המילה במדויק מהתיבות המובנות של שכבת הטקסט — ולחסוך את השלב של החיפוש המקומי [ש-pdfrx סורק את כל הספר בכל חיפוש].

ובמקרה ויש קובץ תיבות — במקום ה-OCR או הטקסט — לוקחים משם את מיקום הסימון. זה הכל: מנגנון אחד [אופסט → תיבה], שלושה מקורות [קובץ תיבות ← שכבת טקסט ← pdfrx כגיבוי]. לספרים מבוססי טקסט אין שום קובץ נוסף במאגר; קובץ התיבות נחוץ רק אם מסירים את שכבת ה-OCR או שאין שכבת טקסט מלכתחילה.

[הלומד]

@HAIM-TEPRMAN

הדבר היחיד שהבנתי בשרשור פה שאין לך זמן עד אלול (טכנית עד מחר)
מקסימום תמיד יש את בין הזמנים של סוכות