Taggart

הנגשת טפסי PDF: המסמך היקר ביותר להנגשה

לכל שדה בטופס דרושים שלושה אובייקטים שמסכימים ביניהם. למה טופס עולה פי כמה ממסמך רגיל, ומה עושים עם טופס בעברית.

שלושה אובייקטים לכל תיבה

פקד טופס ב‑PDF הוא שלושה אובייקטים שחייבים להסכים ביניהם.

השדה, במערך /Fields של /AcroForm. מחזיק את השם, הערך, הסוג, ואת /TU — התיאור שקורא מסך באמת מכריז.

הערת ה‑widget, ב‑/Annots של העמוד. מחזיקה את המלבן, את זרמי המראה, את המסגרת והרקע.

אלמנט Form בעץ המבנה, שמכיל OBJR שמצביע על ה‑widget:

/Document
├── /P     "שם המבקש"
├── /Form
│   └── /OBJR → 31 0 R
├── /P     "תאריך לידה"
└── /Form
    └── /OBJR → 32 0 R

כשהשלישי חסר — תנאי כשל 28-010 — הפקד עדיין נגיש ב‑Tab, אבל איבד את מקומו. הקורא לא פוגש אותו אחרי התווית שמתארת אותו; הוא פוגש אותו בסוף המסמך, או בסדר שבו מעצב הטופס צייר את התיבות, או בכלל לא.

למה זה יקר

מסמך רגיל מתוקן ברמת המסמך: סדר קריאה אחד, קבוצת כותרות אחת, מטא‑דאטה אחת. טופס מתוקן ברמת השדה.

שלושים שדות פירושם שלושים פעמים: לאתר את ה‑widget, ליצור אלמנט Form, למקם אותו במקום הנכון בעץ, ולכתוב תיאור. ב‑Acrobat זה תהליך בן חמישה צעדים לכל אחד, ואין לו מסלול אצווה בממשק.

לכך מתווספים שני דברים שקל לשכוח:

סדר ה‑Tab חייב לעקוב אחר המבנה. לוח התמונות הממוזערות ← בחירת כל העמודים ← מאפייני עמוד ← סדר Tab ← «השתמש במבנה המסמך». בלי הצעד הזה המבנה נכון וסדר ה‑Tab עדיין מתעלם ממנו — תנאי כשל 28-009.

התיאור צריך להיות תווית, לא הוראה. /TU שאומר «הקלד כאן» אינו מתאר דבר. הוא צריך לומר מה השדה מבקש: «שם משפחה», «מספר תעודת זהות», «תאריך לידה — יום/חודש/שנה».

מאיפה זה מגיע

שדות שנוספו אחרי התיוג. סדר הייצור הרגיל — לפרוס את המסמך, לייצא PDF, לתייג, ואז להוסיף שדות ב‑Acrobat — מייצר את התקלה בכל פעם. ‏Prepare Form יוצר widgets ואינו יוצר אלמנטי מבנה.

זיהוי שדות אוטומטי. הוא מוצא תיבות וקווים ומייצר מהם widgets. הוא לא נוגע בעץ המבנה.

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

הטופס בעברית

כאן יש בעיה שאין לה מקבילה באנגלית, והיא שקטה.

בטופס בעברית התווית נמצאת מימין לשדה. כלי שמחפש «את הטקסט שלפני ה‑widget» ומודד «לפני» לפי הסדר הוויזואלי משמאל לימין — ימצא בעברית את התווית של השדה הבא.

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

זו הסיבה שסדר קריאה בעברית אינו פרט טכני אלא שאלה של נכונות — והסבר מלא נמצא כאן.

איך בודקים בחינם

לוח הסדר ב‑Acrobat. ‏תצוגה ← הצג/הסתר ← חלוניות ניווט ← סדר. שדות שמובנים כראוי מופיעים ברשימה. widgets בלי מבנה אינם מופיעים כלל — וזו הבדיקה החזותית המהירה ביותר בטופס ארוך.

veraPDF מדווח על סעיף 7.18.4 ומונה כל widget.

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

מה טאגארט עושה אחרת

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

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

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

בדקו טופס בחינם ← · סדר קריאה בעברית ← · המדריך המלא ←

תנאי כשל קשורים

העמודים הטכניים המלאים באנגלית, עם קטעי קוד ופתרונות ב‑Acrobat.

• 28-010 A widget annotation is not nested within a Form tag
• 28-009 A page containing an annotation has a Tabs entry with a value other than S
• 28-004 An annotation has neither a Contents entry nor an alternative description
• 09-001 Tags are not in logical reading order
• 11-001 Natural language for text in page content cannot be determined

עודכן לאחרונה 2026-09-13 . אין באמור ייעוץ משפטי.