入力できるPDFの作り方|作業確認票を作り、記入・保存・開き直しまで確かめる
PDFの枠に文字を書き込めたのに、相手が開くと空欄だった。長い資料名は途中までしか見えず、どの版を確認したかも分からない。作業確認票をPDFで渡すときは、見た目の表を作るだけでなく、入力する欄と保存される値を分けて点検する必要があります。本稿では、原稿の受渡しを想定した架空の八項目を使い、入力できるPDFを設計してから記入コピーを開き直すまでを整理します。
対象は、すでにLibreOffice Writerを利用できる方です。機能の説明はWriter Guide 26.2とLibreOffice Help、Adobeの公式案内を2026年10月15日に確認した内容に基づきます。本稿ではWriterやAcrobat Readerを実操作していません。別のローカル試験として、ReportLabとpypdfで英数字の八欄を持つPDFを作り、二つの記入例の保存値を読み戻しました。その結果は日本語入力やWriterからの書き出しが成功した証拠にはしません。
紙に書く表とPDF入力欄を分け、確認票の完成条件を決める

写真は工程を表す概念イメージです。実際のWriterやReaderの操作画面ではありません。
見た目の空白と入力フィールドは別のもの
紙の確認票なら、横線があればペンで記入できます。一方、PDFに表示される横線や四角形は、それだけでは入力する部品ではありません。ここでは文字を置くための枠を「見た目の枠」、入力した値を持つ部品を「入力フィールド」と呼びます。二つが同じ場所にあるように見えても、別々に確認する対象です。
例えば資料番号の右に白い長方形を描いた場合、そこを押しても文字が入力できないことがあります。文字追加の機能で上から番号を書けても、それは予定したフィールドへの入力とは限りません。この教材では、八欄それぞれが何を受け取り、何を保存するかを先に決めます。どこにでも文字を置けることを、フォームが完成した判定には使いません。
完成条件は、必要な八項目を区別して記入でき、保存した別ファイルを開き直したときに内容を確かめられることです。さらに、長い値が読み取れること、未確認を確認済みと見せないこと、配布用の空欄版に試験値を残さないことも含めます。書き出しボタンを押せた時点では、これらはまだ分かりません。
一件の受渡しに範囲を絞る
今回の架空確認票は、資料番号、資料名、版、受領点数、確認済チェック、確認方法、不足事項、次の確認事項の八項目です。実在の取引先名、氏名、住所、契約内容は使いません。作業内容の受渡しを整理する教材であり、署名欄や同意欄、支払いの承認欄を追加する設計ではありません。
八項目で足りないからといって、何でも一枚に集めないことも大切です。受領したファイルの一覧が数十件になる場合は、別の一覧資料を参照する方法を考えます。短い確認票にすべての履歴を詰め込むと、表示領域の不足と内容の見落としが重なります。確認票には対象を識別する情報と、今回の確認結果だけを残します。
自動集計、複数人の同時編集、提出先への送信処理はこの完成条件に含めません。PDFを保存しただけでは、誰かへ提出したことにもなりません。相手との受渡し方法は別途合意する必要があります。入力できるファイルを作る工程と、そのファイルを誰へ渡してよいかを決める工程を混ぜないようにします。
作成者と記入者の作業を分ける
作成者は、欄の意味、内部名、選択肢、見やすさを設計します。記入者は、その設計に従って値を入れ、別名で保存します。作成者が記入例を入れて動作を試すときも、役割としては記入者の操作を試している段階です。編集用の元ファイルをそのまま渡すかどうかは、入力用PDFの完成とは別の判断になります。
記入者に知らせる説明も短く用意します。「記入後は別名で保存し、そのファイルを開き直してください」といった作業の終点があると、画面を閉じるだけの終了を避けやすくなります。一方、「保存すれば必ず誰でも同じように表示される」といった保証はしません。実際に使うアプリで確認する範囲を残します。
この確認票の目的は、相手をフォームの使い方で迷わせないことです。凝ったボタンや色分けよりも、何を入れる欄か、入れていない状態をどう扱うかが読み取れるほうが役立ちます。まず八欄の意味を紙面で説明できる形にし、その後で入力部品を対応させます。
一枚の票で何を判断するかを、記入する前に短い質問へ置き換えると設計しやすくなります。「どの資料か」「何版か」「何点受け取ったか」「何を確認したか」「残っていることは何か」という質問です。回答が同じ欄に混ざるなら、欄の名前や説明が足りない可能性があります。例えば資料名の欄に「画像がない」と書く運用では、対象の識別と問題の報告が混ざっています。情報を増やす前に、八項目で答える場所を決めます。
今回の確認票には、担当者名や確認日時を独立欄として追加していません。これは、それらの情報が実務で不要だと主張するためではなく、八欄の教材へ範囲を絞るためです。実際の仕事で必要なら、誰がどの時点を記録するかを決め、項目仕様と試験ケースを増やします。教材の項目数をそのまま最適な業務設計と考えず、追加した欄も同じ保存確認の対象にします。
項目・フィールド名・記入例を設計する

写真は工程を表す概念イメージです。実際のWriterやReaderの操作画面ではありません。
表示ラベルと内部名を別列にする
人が読む「資料番号」という表示と、部品を識別する内部名は区別します。LibreOfficeの公式Helpでは、コントロールを識別するNameプロパティが説明されています。教材では資料番号をdocument_id、資料名をdocument_titleとするように、内容が推測できる内部名を一つずつ割り当てます。この英語名を読者に暗記してもらう必要はありませんが、修正するときの手掛かりになります。
参考:LibreOffice Help「Forms: General Tab」
項目仕様では、表示ラベル、内部名、部品の種類、初期状態、記入例を並べます。見た目が同じ文字欄でも、資料番号と次の確認事項では目的も入力長も違います。名前を順番の数字だけにすると、欄を移動したときに意味を追いにくくなります。配置順とは独立した名前を使い、順番は別の列で管理します。
| 表示ラベル | 内部名 | 種類 | 初期状態 | 通常記入例 |
|---|---|---|---|---|
| 資料番号 | document_id | 文字欄 | 空欄 | DOC-001 |
| 資料名 | document_title | 文字欄 | 空欄 | 案内原稿 |
| 版 | revision | 文字欄 | 空欄 | r1 |
| 受領点数 | item_count | 文字欄 | 空欄 | 03 |
| 確認済チェック | checked | チェック | 未選択 | 選択 |
| 確認方法 | method | 単一選択 | 未選択 | 画面 |
| 不足事項 | missing | 複数行文字欄 | 空欄 | なし |
| 次の確認事項 | next_action | 文字欄 | 空欄 | 説明文を確認 |
横に長い表はスクロールしてご確認ください。すべて架空教材で、実施範囲は結果欄に明記しています。
資料番号の例はDOC-001、版はr1、受領点数は文字列の03です。03を数字の三として計算する教材ではなく、入力された文字をそのまま受け渡す教材にしています。実務で数値として集計したい場合は別設計が必要です。今回の03が3に変わっていないかを見るのは、値の保持を確認するためです。
未記入と初期値を混同しない
初期値を入れると記入しやすくなりますが、試験用の値が回答に見えることがあります。資料名に「案内原稿」と入れたまま配布すると、記入者がその文字を自分の資料名だと思い込むかもしれません。教材の配布用原版では文字欄は空にし、記入例は説明文や別の試験票へ移します。
確認済チェックは初期状態を未選択にします。未選択のまま返ってきた場合には、未確認、確認したが問題があった、単なる記入漏れという複数の可能性が残ります。そのため、チェックだけで理由を推定せず、不足事項や次の確認事項と一緒に読みます。チェックがないことを自動的に不合格とする仕組みは今回作りません。
確認方法は「未選択」「画面」「紙」の三つから一つを選ぶ設計です。未選択は確認方法がまだ記録されていない状態であり、画面と紙のどちらでもよいという意味ではありません。選択肢を初めから画面にしておくと、触らずに保存しただけでも画面確認をしたように見えます。意味のない初期実績を作らないことが狙いです。
独立した欄に同じ名前を付けない
コピーで欄を増やしたときは、表示ラベルだけでなく内部名も確認します。不足事項と次の確認事項に同じmissingという名前を残すと、独立させたい二欄の区別が設計上なくなります。教材の第三ケースでは、この重複を設計表で発見し、next_actionへ直してから出力することを期待結果としています。
Writer Guide 26.2は、PDF書き出し時に同名フィールドを許可する設定と、同名欄へ値が反映される関係を説明しています。同じ資料番号を複数箇所へ表示したい場合など、名前を共有する意図がある設計もあります。しかし、今回の八欄はそれぞれ独立した意味です。同名の許可設定だけに頼って、元の命名ミスを放置しない方針にします。
第三ケースは、不正なPDFを作って実際の連動を再現した試験ではありません。八個の内部名を一覧化して数え、missingが二回出ることを確認した設計検査です。異常をわざと本番の配布物へ持ち込むのではなく、書き出す前に止める確認として使います。正常な設計では、八欄に八個の異なる内部名が対応します。
初期状態の設計では、空文字と「なし」の使い分けも決めておきます。不足事項の空欄はまだ書いていない可能性がある一方、「なし」は確認者が不足を認識していないという回答になります。今回の通常例では後者、長文例では不足内容を二行で記載します。プログラムで空欄を自動的に「なし」へ埋める処理は行いません。回答した事実を、フォーム側で勝手に作らないためです。
選択肢の意味は、見た目の並びだけでなく説明でも揃えます。「画面」は票に記載した対象を画面で確認した例、「紙」は紙で確認した例です。両方を行ったときの記録が必要なら、この三択では足りません。その場合は設計を見直し、複数選択か別の選択肢を検討します。現在の三択に無理に当てはめて、実際に行った確認を欠落させないようにします。
Writerで文字欄と選択欄を配置する

写真は工程を表す概念イメージです。実際のWriterやReaderの操作画面ではありません。
固定文を置いてから部品を対応させる
最初に、確認票のタイトル、対象範囲、八項目のラベル、記入後の保存案内を固定文として考えます。入力者が変えなくてよい文章と、入力する場所を混ぜないようにします。今回の表題は「原稿受渡し確認票」、説明は「架空教材。受領した資料の確認内容を記録」といった形です。実際の提出様式や公的書式には見せません。
公式ガイドでの基本操作は、フォーム関連のツールバーを表示し、デザインモードでコントロールを置き、プロパティを設定する流れです。試入力するときはデザインモードを切り替えます。利用中の版や表示言語によって画面の名称や位置が異なるため、本稿の写真は実際のWriter画面の案内図ではなく、工程を表した概念イメージです。
八項目のうち六つは文字を受け取る欄、残る二つは確認済チェックと確認方法の選択です。不足事項は複数行を想定し、他の短い欄と同じ高さにはしません。部品の数を増やすことよりも、ひとつの情報がひとつの欄へ入る対応を維持することを優先します。説明用ラベルは入力欄の数には数えません。
枠の幅は記入例から決める
資料番号はDOC-001が読めれば十分でも、資料名には長い日本語が入る可能性があります。例えば「秋の展示案内原稿と画像一覧の受渡し確認用資料」という名前を使い、短い例だけで幅を決めないようにします。見出しだけ広くして入力領域が狭いままでは、記入時の問題は解決しません。
不足事項には「画像二点が未着」と「説明文の確認が未了」を別の行に入れる例を用意します。この改行は見やすさのためであり、二件のデータへ分割する処理ではありません。複数行の文字をどこまで表示できるか、入力中と欄から離れた後で見え方が変わらないかを、PDFになった段階でも確認します。
公式ガイドは、PDFで入力した文字に合わせて周囲の文書が自動的に流れ直すわけではないと注意しています。そこで、長文に対応する方法は、文字を小さくすることだけにしません。欄を広げる、説明を短くする、記載量が多い場合の別紙参照を決めるなど、読み手が全文を確認できる設計を選びます。
編集できたことと記入できたことを分ける
デザインモードで欄を選べることは、入力者として文字を入れられることとは違います。作成中は部品の位置や大きさを変える操作と、欄の中身を入れる操作を行き来します。試すときは、いまどちらの操作をしているかを確認し、部品を動かせたことを入力成功の記録にしないようにします。
確認済チェックのラベルは、何を確認したかが分かる文にします。「確認済」だけで足りない場合は、「記載した資料の受領点数を確認した」といった限定が必要です。今回の八欄教材では、チェックは票に記載した対象を確認したという申告欄として扱います。著作権、品質、公開許可まで承認した意味には広げません。
配置の試験では、ラベルと欄の距離も見ます。資料名のラベルが次の版の欄に近すぎると、入力先を取り違える原因になります。隣り合う欄を同じ幅に揃える場合も、上下のまとまりが分かる余白を残します。ラベルを小さくして一枚へ押し込むより、何を記入しているかを見失わない配置を選びます。
欄を一つずつ配置した後に、ラベルを隠して入力部品だけを見てみると、同じ幅の箱が並んでいるだけに見えることがあります。逆に入力部品を意識せず固定文だけを読むと、何を答えればよいかが分かるでしょうか。この二つの読み方で点検すると、部品の配置は揃っているのに説明が不足している箇所を見つけやすくなります。これは実アプリの合格を保証する検査ではなく、作成者が行う紙面設計の見直しです。
修正時には、部品の大きさと文字の大きさを別に扱います。資料名の欄を広げても、固定ラベルの文字が変わる必要はありません。文字を小さくした場合は、印刷や小さな画面でも読めるかが新しい確認事項になります。一つの変更で解決した問題と、新しく確認すべき問題をメモに残すと、単に見た目が収まっただけの修正で終わりにくくなります。
入力順・長文・空欄・選択状態を確かめる

写真は工程を表す概念イメージです。実際のWriterやReaderの操作画面ではありません。
三つのケースに期待結果を書く
通常ケースでは、資料番号DOC-001、資料名「案内原稿」、版r1、受領点数03、確認済チェック選択、確認方法画面、不足事項「なし」、次の確認事項「説明文を確認」とします。八欄すべてに、意図した意味の値が対応することが期待結果です。入力例は実際の案件の記録ではなく、欄の役割を確認する架空データです。
長文・空欄ケースでは、資料番号DOC-002、長い資料名、版r2、受領点数03、確認済チェック未選択、確認方法未選択、不足事項の二行、次の確認事項は空欄にします。空欄を入れ忘れとして埋めるのではなく、空欄を保つ試験にします。保存後に前のケースの文章が残るなら、原版の使い回しや消去の工程を見直す必要があります。
重複名ケースでは、第三の回答内容を作るより先に、八欄の内部名を照合します。不足事項と次の確認事項が同名になっている設計だけを異常例にし、それ以外の六欄は正常ケースの設計と同じにします。どの条件を変えたかが一つに絞られるため、見つけた異常と修正の対応が明確になります。
| 項目 | 通常ケース | 長文・空欄ケース | 重複名ケースの設計 |
|---|---|---|---|
| 資料番号 | DOC-001 | DOC-002 | document_id(重複なし) |
| 資料名 | 案内原稿 | 秋の展示案内原稿と画像一覧の受渡し確認用資料 | document_title(重複なし) |
| 版 | r1 | r2 | revision(重複なし) |
| 受領点数 | 03 | 03 | item_count(重複なし) |
| 確認済チェック | 選択 | 未選択 | checked(重複なし) |
| 確認方法 | 画面 | 未選択 | method(重複なし) |
| 不足事項 | なし | 画像二点が未着 説明文の確認が未了 |
missing(重複) |
| 次の確認事項 | 説明文を確認 | 空欄を保持 | missing(誤り)→next_actionへ修正 |
横に長い表はスクロールしてご確認ください。すべて架空教材で、実施範囲は結果欄に明記しています。
入力順と視覚上の順番を対照する
画面の上から下へ欄が並んでいても、キーボードで移動する順番が同じとは限りません。公式ガイドにはコントロールの移動順を設定し、デザインモードを離れてTabで試す説明があります。本稿ではその操作を実施していないため、試験票の入力順の結果欄は未確認です。手順を説明できることと、対象ファイルで実際に通ったことを分けます。
実際に試すときは、最初にどの欄へ入ったか、その後どこへ移動したかを記録します。順序の例は資料番号、資料名、版、受領点数、確認済チェック、確認方法、不足事項、次の確認事項です。一度飛んだ欄があれば、マウスで補って完了にする前に、入力順の問題として残します。
移動順の試験では、選択部品の使いやすさも見ます。選択肢が開いた状態と閉じた状態で何が表示されるか、未選択が残るかを確認します。入力者がキーボードだけを使う可能性があるなら、その条件での試験が必要です。画面を眺めただけで、アクセシビリティ全般に問題がないと断定するものではありません。
値が残ることと全文が見えることを別にする
保存された文字列が正しいことと、その文字列を紙面ですべて読めることは別です。内部に長い資料名が残っていても、欄の右端で文字が切れていれば、受け取った人が資料を特定できないかもしれません。逆に見た目に文字があっても、予定したフィールドの値として入っていない可能性があります。試験票には値の照合と表示の照合を別の欄で記録します。
長文の表示を直した後は、その欄だけを見るのではなく、直下の版や受領点数の欄との間隔も再確認します。高さを増やしたことで別の部品に重なったり、ページの下へ押し出されたりする場合があるためです。修正対象と、その周囲に影響する範囲を一緒に確認すると、局所的な修正が別の問題を作ることを見つけやすくなります。
空欄は、空のままでよい欄と、確認を求める欄を分けて読みます。今回の長文ケースで次の確認事項を空にするのは保存試験のためですが、実務で次の作業が決まっているなら記入する必要があります。教材の試験値を、そのまま業務上の正しい回答と考えないようにします。フォームの正常動作と回答内容の妥当性は別の点検です。
試験中に見つけた問題は、「使えない」という一語ではなく再現できる形で残します。例えば「長文ケースの資料名で、欄から移動すると末尾の『資料』が見えない」「通常ケースを保存後、確認方法だけ未選択へ戻る」と書きます。どのケースのどの欄か、入力中か再読込後かを特定するだけでも、直す場所を探しやすくなります。内容そのものが機密情報の場合は、再現用の架空値へ置き換えて相談します。
試験の結果には期待値と観測値を並べます。期待値は作成前に決めた内容、観測値は実際に読み取った内容です。まだアプリで試していない箇所に期待値だけを転記して、観測済みの欄を埋めないようにします。今回の日本語の三ケース表も同じで、入力する値と確認したい結果は具体的に用意していますが、WriterとReaderでの観測欄は未実施のまま残します。
PDFフォームとして書き出し、元ファイルと分ける

写真は工程を表す概念イメージです。実際のWriterやReaderの操作画面ではありません。
ODTと配布用PDFの役割を決める
編集用のODTには、欄の配置やプロパティを直す役割を持たせます。配布用のPDFには、記入者が値を入れる役割を持たせます。試験で記入したPDFは、正常に保存できるかを確認する資料です。これらを同じファイル名で上書きしていくと、どれが空欄の原版かを見分けにくくなります。
教材のファイル名例は、編集用をworksheet-r1.odt、配布用をworksheet-r1-blank.pdf、通常試験をworksheet-r1-test-normal.pdf、長文試験をworksheet-r1-test-long.pdfとします。これらはWriter操作で実際に作成した成果物の名前ではなく、運用を整理する命名例です。拡張子を変えるだけで形式を変換できるという意味ではありません。
| 区分 | 名前・内容例 | 役割 | 本稿での扱い |
|---|---|---|---|
| 編集用元版 | worksheet-r1.odt | 欄の配置・意味を修正 | Writer作成例名。実作成なし |
| 配布用空欄PDF | worksheet-r1-blank.pdf | 記入する原版 | Writer書出し例名。実作成なし |
| 記入試験PDF | worksheet-r1-test-normal.pdf / test-long.pdf | 試験回答の保存コピー | Writer/Reader試験例名。実作成なし |
| 試験記録 | ケース・版・期待・観測・未確認 | 値と見た目と操作を分ける | 本稿では日本語試験未実施を保持 |
横に長い表はスクロールしてご確認ください。すべて架空教材で、実施範囲は結果欄に明記しています。
版を変える理由も残します。例えば資料名の欄を広げたなら、r2の変更理由を「長文の末尾を表示するため」とします。単に最新と名付けるより、何を直した版かが分かります。過去の記入済PDFを新しい原版と取り違えないよう、版と用途をファイル名の両方へ入れておきます。
フォーム書き出しの設定を確認する
Writer Guide 26.2では、PDFへの書き出し画面でCreate PDF Formを有効にして出力する流れが示されています。Writerの部品とPDFの部品は同一ではなく、すべての機能がそのまま移るわけではありません。本稿では文字欄と選択欄の小さな確認票に限定し、データベース接続やマクロ、Web送信の処理を含めません。
印刷してPDFにする方法と、入力フィールドを含めてPDFへ書き出す方法は、同じ完成物になると決め付けないようにします。見た目が似ていても、文字を入れるための情報が残っているかは別の確認です。出力後は、予定した八欄に入力できるかを確かめてから、配布用として扱います。
同名フィールドの扱いも、書き出し時の確認項目に残します。今回の設計では独立した八欄に異なる名前を付けているので、名前共有による連動を利用する必要はありません。設定の意味が不明なまま有効にするのではなく、設計表との整合を見ます。すでに異常がある設計を、書き出し設定だけで見えなくする方法は採りません。
出力先と原版の空欄を確認する
出力が終わったら、編集画面ではなく、実際に保存されたPDFを特定します。保存先、ファイル名、版が分かるようにして、そのファイルを開きます。以前の試験PDFが同じフォルダーにある場合、更新日時だけで選ばず、用途を含む名前を確認します。古いファイルを試して新しい出力が成功したと考えることを避けます。
配布用の空欄版に戻ったつもりでも、確認済チェックが入っていたり、確認方法が画面になっていたりすると、初期状態が変わっています。文字欄だけ空かを見るのではなく、チェックと選択欄も含めて八項目を確認します。未選択を表す表示がある場合は、その表示が意図した初期値かも照合します。
- 文字欄に試験値が残っていないか。
- 確認済チェックが未選択か。
- 確認方法が意図した初期状態か。
原版を点検するときは、試験に使った回答を手作業で消したファイルを無条件に原版へ昇格させないようにします。元の設計から空欄版を作り直し、初期状態を確認するほうが追跡しやすい場合があります。どちらの方法でも、採用した原版の版と保存先を試験記録へ残し、次の記入コピーと対応させます。
修正後の原版ができたら、以前の試験結果をそのまま付け替えません。例えばr1の資料名の表示が切れたためr2で欄を広げた場合、r1の値保存が成功した記録は履歴として残せますが、r2の表示確認を済ませた記録にはなりません。変更後の配布用PDFで少なくとも影響したケースを試し、対象の版を記録します。部品の移動が大きいときは、周囲の入力順や重なりも再確認の範囲へ入れます。
記入して保存し、開き直した内容と受渡し範囲を確認する

写真は工程を表す概念イメージです。実際のWriterやReaderの操作画面ではありません。
別名保存してから同じファイルを読み戻す
Adobeの公式案内では、入力できるフォームと静的なフォームが区別され、記入したフォームを別名で保存する方法が説明されています。無料のReaderでフォームを読む、記入することと、フォームを新しく設計することは分けて考えます。本稿はReader無料版で入力フィールドそのものを作れると説明するものではありません。
参考:Adobe「Fill in forms」、Adobe「Acrobat Reader FAQs」
保存試験は、配布用の空欄版を開くところから始めます。通常ケースを記入します。試験用の別名で保存します。いったん閉じます。保存先にある記入済ファイルを開き直します。八項目を試験票の期待値と照合します。この順番にすると、元の編集画面が残っていただけなのか、ファイルへ保存されたのかを切り分けやすくなります。
- 空欄原版の名前と版を確認する。
- ケースの八項目を記入し、別名保存する。
- 閉じて保存先のコピーを開き直し、値と表示を別々に点検する。
保存ボタンが押せない、保存後に内容が消える、警告が表示される場合は、その状態を結果として記録します。保護や権限を勝手に解除したり、別のサービスへアップロードして回避したりしません。対象のPDFと利用アプリの条件を確認し、作成者へ相談する範囲を整理します。保存できなかった状態を、画面上で入力できたという理由で完了にしません。
ローカルの構造試験で確認した範囲
本稿の補助試験では、すでに利用できるReportLab 4.4.9で八欄のPDFを生成し、pypdf 6.10.0で通常と長文・空欄の二種類の値を保存しました。これはWriterの出力ではありません。入力文字は英数字に限定し、通常例の資料名はDraft handover sheet、長文例は説明を長くした英文です。日本語資料名の表示試験を代わりに済ませたとは扱いません。
保存後は、二つのファイルを新しく読み込み、八個のフィールド名と値がそれぞれ期待どおりであることを照合しました。ページ上の入力部品に対応する値と、表示用の情報が存在することも確認しました。03は03のまま、空欄は空欄のまま、通常例のチェックは選択、長文例は未選択でした。空欄の原版にも試験回答は入りませんでした。
生成物の見た目はPyMuPDFで画像化して別途確認しました。英数字の文字、二行の不足事項、チェックの違いが読み取れる範囲を確認したもので、Readerでの操作やキーボードの移動順の検証ではありません。重複名の第三ケースはPDF生成前の設計チェックで止めました。三ケースすべてについてアプリ上の操作試験が済んだという表現はしません。
| 確認対象 | 期待する確認 | 実施状況 |
|---|---|---|
| 通常ケース | 八欄を期待値どおり記入・保存・再読込 | Writer/Readerでは未実施 |
| 長文・空欄ケース | 全文表示、二行、03、未選択、空欄を照合 | 日本語の実表示は未実施 |
| 重複名ケース | 内部名missingの重複を出力前に検出 | 設計表の検出のみ。PDF実連動は未試験 |
| 補助ASCII通常 | 8フィールド値・8Widget値の保存後一致 | ReportLab/pypdfで一致、PyMuPDF画像実見 |
| 補助ASCII長文・空欄 | 8フィールド値・8Widget値の保存後一致 | ReportLab/pypdfで一致、PyMuPDF画像実見 |
| Tab入力順 | 資料番号から次の確認事項までの移動 | 未実施 |
横に長い表はスクロールしてご確認ください。すべて架空教材で、実施範囲は結果欄に明記しています。
この補助試験が示すのは、PDF内部の値を保存し直して再読込する確認を、画面の見た目と分けられるということです。読者が作る日本語の確認票に同じ結果を保証するものではありません。実際のWriter書き出し、実際に使う閲覧アプリ、日本語の表示、入力順は、そのファイルについて改めて確認します。
渡すものを確定してから完成にする
受渡し前の一覧には、編集用元版、配布用空欄PDF、記入試験PDF、試験記録の四種類を並べます。相手に記入してもらうだけなら、編集用元版や試験回答まで同封する必要があるとは限りません。何を渡すかは依頼内容に合わせ、不要な作業資料を含めないようにします。本稿の教材も、実案件の情報を共有する許可を与えるものではありません。
確認記録では、作成に使った版、書き出したファイル、記入に使ったアプリ、保存後に開いたファイルを分けます。日本語表示が未確認なら未確認と残します。保存値が一致していても表示が切れていたら、その欄は表示修正が必要です。試験結果の欄を一つだけの合格印で埋めるのではなく、どの確認が終わったかを読めるようにします。
- 作成・書出し・記入に使った環境を記録する。
- 日本語表示や入力順の未確認を残す。
- 渡す版と用途を確定する。
フォントや再出力後の見た目を詳しく確認したい場合は、当サイトのPDFのフォント確認に関する記事も参照できます。また、入力機能ではなく紙面の比較表を整えたい場合は、Wordの比較表に関する記事が別の課題を扱っています。静的な表を整える工程と、PDFの入力値を保存する工程を使い分けると、必要のない機能を追加せずに済みます。
入力できるPDFの完成は、八個の枠を置くことではなく、八個の意味が保存後も読み取れる状態にすることです。通常例で基本を確認し、長文と空欄で境界を確かめ、名前の重複は出力前に止めます。最後に原版と記入済コピーを区別し、実際に確認できた範囲を添えて受け渡すところまでを、一つの作業として扱いましょう。