הצעת ייעול | ייעול האינדקס עבור PDF
-
שלוש מההסתייגויות שלי נשענו על הנחה אחת שגויה — שהתיבות נשמרות בתוך ה-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, שהיא כבר החלטת מדיניות על שינוי בלתי הפיך בקבצים של המשתמש (ולא רק סימון — גם בחירה והעתקה וקריאה בכל תוכנה אחרת). המימוש העובד והמדידות שוות שם יותר מכל דיון בפורום.
-
שלוש מההסתייגויות שלי נשענו על הנחה אחת שגויה — שהתיבות נשמרות בתוך ה-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, שהיא כבר החלטת מדיניות על שינוי בלתי הפיך בקבצים של המשתמש (ולא רק סימון — גם בחירה והעתקה וקריאה בכל תוכנה אחרת). המימוש העובד והמדידות שוות שם יותר מכל דיון בפורום.
@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 במציג] - אז זה בעצם השינוי היחיד שחייבים לעשות.
-
שלוש מההסתייגויות שלי נשענו על הנחה אחת שגויה — שהתיבות נשמרות בתוך ה-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, שהיא כבר החלטת מדיניות על שינוי בלתי הפיך בקבצים של המשתמש (ולא רק סימון — גם בחירה והעתקה וקריאה בכל תוכנה אחרת). המימוש העובד והמדידות שוות שם יותר מכל דיון בפורום.
@Otzaria-Bot אז יש פתח לפתח תוסף שיחסוך למשתמשי PDF המון מקום
-
@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 במציג] - אז זה בעצם השינוי היחיד שחייבים לעשות.
שתי המדידות שלי היו שגויות, ושתיהן לרעתי: הקואורדינטות ברמת התו הן עיקר משקל השכבה, לא המילים — ולכן 10.6MB הוא באמת כולו השכבה, ו-38% ולא 23%. מקבל.
מה שכיניתי "שינוי במנוע" קטן ממה שכתבתי — ואולי לא חוסם בכלל
בדקתי שוב ב-dev: המנוע לא מחזיר רק מספר עמוד.
result.textחוזר ממנו כשההדגשה כבר בתוכו — יש על זה הערה מפורשת בקוד (lib/search/view/tantivy_search_results.dart: "ההדגשה מגיעה מוכנה מהמנוע בתוך rawHtml"), והתצוגה רק ממירה את ה-HTML ל-spans. כלומר המנוע כבר יודע איפה ההתאמה יושבת בתוך טקסט הסגמנט; מה שחסר אינו רזולוציה חדשה באינדקס אלא חשיפה מספרית של מה שהוא כבר מחשב — טווח תווים במקום תגי הדגשה בתוך מחרוזת.ההבדל מעשי: אין שינוי סכימה ואין בנייה מחדש של האינדקס. שאלה אחת שכדאי לבדוק לפני שמנסחים את הבקשה — האם המחרוזת שחוזרת היא טקסט העמוד המלא או חלון סביב ההתאמה. אם מלא, האופסט המוחלט נגזר ישירות; אם חלון, צריך לעגן אותו בטקסט העמוד — שאצלך משוחזר מהאינדקס בכל מקרה.
נקודה שלא עלתה: לפי מה ממפתחים את קובץ התיבות
"מילה 417" של המנוע ו"מילה 417" של קובץ התיבות אינן בהכרח אותה מילה. הטוקניזציה באוצריא אינה פיצול לפי רווחים — תחיליות ו/ב/כ/ל/מ/ש/ה/ד, כתיב מלא/חסר, ניקוד, גימטריה — וכל שינוי בה יזיז את האופסטים בלי שקובץ התיבות ידע. שתי מסקנות:
- את קובץ התיבות כדאי לקצור בדיוק באותה קריאה שמזינה את המנוע (
_extractPdfPages←loadText()), מאותוfullText— לא במעבר נפרד על הקובץ. - ועדיף למפתח אותו באופסט תווים ל-
fullText, לא במספר מילה. ה-charRects הם ממילא לפי תו, מלבן של מילה הוא איחוד תווים, ואופסט תווים חסין לשינויי טוקניזציה ולעדכון גרסת מנוע. גם המקרה של OCR שמפצל מילה לכמה fragments נפתר מעצמו.
זה גם מה שמצמצם את הבקשה מהמנוע לדבר אחד מוגדר: טווח תווים ב-
fullTextשל הסגמנט.השאר עומד: שני issues נפרדים, ומחיקת שכבת ה-OCR כפעולה נפרדת ומדעת, עם טביעת אצבע לקובץ המקור וגרסת פורמט.
- את קובץ התיבות כדאי לקצור בדיוק באותה קריאה שמזינה את המנוע (
-
@Otzaria-Bot אז יש פתח לפתח תוסף שיחסוך למשתמשי PDF המון מקום
לא כתוסף — לא במסגרת ה‑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מחזירים ל‑PDFindex= עמוד, בדיוק כמו המסך הפנימי. האופסט בתוך העמוד צריך לבוא מהמנוע, שהוא חבילה חיצונית.אז מה שנשאר לתוסף הוא הדגמה: WebView משלו עם PDF.js על קובץ שהמשתמש בוחר, שמראה את הפורמט ואת זמני החיפוש. זה שווה בתור הוכחה, אבל זה לא אינטגרציה — אחרי הכל, "לחסוך מקום למשתמשי PDF" מחייב שהאינדוקס והמציג של אוצריא עצמם ידעו על התיבות.
לכן ה‑issue צריך להיות מנוסח כשינוי ליבה, לא כתוסף. שלושה סעיפים: (1) לשמור את ה‑charRects שכבר ביד ב‑
_extractPdfPagesלקובץ צד עם מספר גרסת פורמט וטביעת אצבע לקובץ המקור; (2) שהמנוע יחזיר אופסט מילה בתוך העמוד; (3) צייר במציג ה‑PDF שקורא מקובץ הצד. אם זה ייכנס, אפשר יהיה בשלב שני לחשוף אותו גם לתוספים — אבל לא לפני שהבסיס קיים.מחיקת שכבת ה‑OCR נשארת issue נפרד, כי היא החלטת מדיניות ולא קוד.
-
@haim-teprman
למה שלא תפתח PR לאוצריא?
לא מספיק קראתי פה, אבל זה נראה שאתה יודע על מה אתה מדבר.
כמובן, שאין התחייבות שזה יתקבל.
אולי @י.-פל. יוכל לבדוק את הרעיון קודם כדי להגיד לך. -
@haim-teprman
למה שלא תפתח PR לאוצריא?
לא מספיק קראתי פה, אבל זה נראה שאתה יודע על מה אתה מדבר.
כמובן, שאין התחייבות שזה יתקבל.
אולי @י.-פל. יוכל לבדוק את הרעיון קודם כדי להגיד לך.@הבל-הבלים זה היה המטרה - אבל הבוט החליט להגיב אז הסברתי
-
@הבל-הבלים זה היה המטרה - אבל הבוט החליט להגיב אז הסברתי
@HAIM-TEPRMAN
אני מתכון PR לתוכנה עצמה, אם אתה צודק - אז אין עניין בתוסף. -
@haim-teprman
שים לב: האינדוקס מתחלק למנוע (https://github.com/Otzaria/otzaria_search_engine gb; ענף ראשי refactor), ולרכיבים באוצריא עצמה.
לא עקבתי אחרי כל השרשור, אבל נראה שהpr יהיה רלוונטי לאוצריא (ששולחת למנוע את המידע לאינדוקס). -
@HAIM-TEPRMAN
אני מתכון PR לתוכנה עצמה, אם אתה צודק - אז אין עניין בתוסף.@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
אני חושב שנגמרו לנו הטוקנים שם.
לא קניתי עוד מנוי, כי היה חבל לי לבזבז על שבוע, אבל כעת אין כ״כ טוקנים.@י.-פל. כלומר הבוט הלך לישון?
עכ"פ אני כבר לא יודע אם יהיה לי מספיק זמן לפני אלול לפתוח PR
אבל הרעיון פשוט ביסודו [אפשר לשנות במנוע לכפל חיסכון, אבל בהנחה שלא]:הבקשה היחידה מהמנוע: להוסיף כאופציה שהוא יחזיר אופסט — מיספור המילה. [עדיף אופסט תווים — חסין לשינויי טוקניזציה — אבל גם מספר מילה מספיק.] הוא כבר יודע איפה ההתאמה יושבת — הוא מחשב את זה בשביל ההדגשה — רק לא מחזיר את זה החוצה. בלי שינוי סכמה, בלי בנייה מחדש של האינדקס.
ומה שזה מאפשר גם היום, בלי שום קובץ נוסף: לסמן את המילה במדויק מהתיבות המובנות של שכבת הטקסט — ולחסוך את השלב של החיפוש המקומי [ש-pdfrx סורק את כל הספר בכל חיפוש].
ובמקרה ויש קובץ תיבות — במקום ה-OCR או הטקסט — לוקחים משם את מיקום הסימון. זה הכל: מנגנון אחד [אופסט → תיבה], שלושה מקורות [קובץ תיבות ← שכבת טקסט ← pdfrx כגיבוי]. לספרים מבוססי טקסט אין שום קובץ נוסף במאגר; קובץ התיבות נחוץ רק אם מסירים את שכבת ה-OCR או שאין שכבת טקסט מלכתחילה.
-
@י.-פל. כלומר הבוט הלך לישון?
עכ"פ אני כבר לא יודע אם יהיה לי מספיק זמן לפני אלול לפתוח PR
אבל הרעיון פשוט ביסודו [אפשר לשנות במנוע לכפל חיסכון, אבל בהנחה שלא]:הבקשה היחידה מהמנוע: להוסיף כאופציה שהוא יחזיר אופסט — מיספור המילה. [עדיף אופסט תווים — חסין לשינויי טוקניזציה — אבל גם מספר מילה מספיק.] הוא כבר יודע איפה ההתאמה יושבת — הוא מחשב את זה בשביל ההדגשה — רק לא מחזיר את זה החוצה. בלי שינוי סכמה, בלי בנייה מחדש של האינדקס.
ומה שזה מאפשר גם היום, בלי שום קובץ נוסף: לסמן את המילה במדויק מהתיבות המובנות של שכבת הטקסט — ולחסוך את השלב של החיפוש המקומי [ש-pdfrx סורק את כל הספר בכל חיפוש].
ובמקרה ויש קובץ תיבות — במקום ה-OCR או הטקסט — לוקחים משם את מיקום הסימון. זה הכל: מנגנון אחד [אופסט → תיבה], שלושה מקורות [קובץ תיבות ← שכבת טקסט ← pdfrx כגיבוי]. לספרים מבוססי טקסט אין שום קובץ נוסף במאגר; קובץ התיבות נחוץ רק אם מסירים את שכבת ה-OCR או שאין שכבת טקסט מלכתחילה.
הדבר היחיד שהבנתי בשרשור פה שאין לך זמן עד אלול (טכנית עד מחר)
מקסימום תמיד יש את בין הזמנים של סוכות
שלום! נראה שהשיחה הזו מעניינת אותך, אבל עדיין אין לך חשבון.
נמאס לכם לגלול בין אותם הפוסטים בכל ביקור? כשנרשמים לחשבון, תמיד תחזרו בדיוק למקום שבו הייתם קודם, ותוכלו לבחור לקבל התראות על תגובות חדשות (בין אם במייל, ובין אם בהתראת פוש). תוכלו גם לשמור סימניות ולפרגן ב-upvote לפוסטים כדי להביע הערכה לחברי קהילה אחרים.
בעזרת התרומה שלך, הפוסט הזה יכול להיות אפילו טוב יותר 💗
הרשמה התחברות