Start with the edit you actually need. For this walkthrough, “editable” means changing values in named, fillable PDF fields. The task is to update an attendee and room, save a separate PDF, close it, and find those values when you reopen that file. Editing an arbitrary paragraph and making surrounding content reflow is a different requirement.
The example below is an original, fictional workshop booking specification. Its conversions and reader checks have not been performed. Expected values are acceptance targets; actual field dictionaries, file hashes, and reader observations remain blank until tested.
Keep one source and three conversion contracts
Use revision R1 of a small form with this content:
| Source element | Field name | Initial content | Intended role |
|---|---|---|---|
| Plain booking identifier | None | WK-01 | Static text |
| Text input | attendee-name | Guest A | Attendee value |
| Select with two options | room | Studio selected; Workshop available | Room value |
| Textarea | notes | Bring notebook | Notes value |
Give the controls visible labels and distinct names. For the room options, use matching labels and values: Studio and Workshop. This avoids introducing a separate display-label versus stored-value question into the first test.
WK-01 is a paragraph or similar plain text element. It is not a disabled input, hidden input, or fourth field. The fixture has no submission action, submit button, JavaScript, signatures, availability lookup, or real booking data.
Record the source revision and its SHA-256 hash before conversion. Keep the source unchanged throughout the comparison. Converter settings and a separate conversion stylesheet can differ by mode; preserve those alongside the source identity.
WeasyPrint's PDF forms documentation describes a static default, an all-fields option, and selective field conversion using CSS. Reader support varies. The reference read for this article is labeled WeasyPrint 70.0; the installed converter and reader versions still need to be recorded.
Use three independently generated outputs:
| Mode | Conversion contract | Expected named fields |
|---|---|---|
| Static | No all-fields option and no selective form styles | None |
| All fields | Python option pdf_forms=True, or the documented CLI equivalent |
attendee-name, room, notes |
| Selective | No global all-fields switch; apply appearance: auto to attendee-name and room only |
attendee-name, room |
These counts are specific to this three-control fixture. A larger source could contain other controls, so “three fields” is not a general converter rule. Inspect the output rather than copying a count from the settings.
Make the selective case genuinely selective
A request to make just the attendee and room editable needs its own output. Turning on the global all-fields option and then calling the result “selective” would not establish that notes stayed static.
In the selective conversion stylesheet, target the text input named attendee-name and the select named room. Leave the notes textarea outside those selectors. For this mode, do not enable the global all-fields switch.
The official guidance also calls for overriding relevant user-agent styling when selecting fields with appearance: auto. Treat the precise styling and resulting appearance as implementation work to verify against the installed version. A control that looks correct in the source browser is not proof of the PDF's field structure. WeasyPrint PDF forms
The selective acceptance target has two parts: exactly the intended named fields are available, and notes still displays Bring notebook as static content. Inspect both. Do not count three visible rectangles and infer three fields, or assume that being unable to click notes proves the field is absent.
Keep the static booking identifier visible in every mode. It should remain WK-01 after edits to the fillable fields. That gives the comparison an explicit piece of content that should never become a form value.
Inspect field identity before editing
For each generated PDF, record its output path, hash, conversion mode, installed converter version, and actual options. Use a PDF inspection method that can report named fields and their current values. Identify the inspection tool and version rather than assuming the reader's visual interface exposes that information.
The initial targets are:
- Static output: no named form fields; the original content remains visible.
- All-fields output: attendee-name is Guest A, room is Studio, and notes is Bring notebook.
- Selective output: attendee-name is Guest A and room is Studio; notes is not a named field and remains visible as static text.
Compare field names as well as counts. Two unexpected fields do not satisfy the selective contract. Record unexpected names, missing fields, or different initial values as findings to resolve.
If field structure cannot be inspected with the available tools, mark that check pending. Successful clicking alone does not complete the dictionary check. Conversely, finding a field in the dictionary does not establish that the selected reader can edit and persist it.
Save, close, and reopen the edited output
Choose an identified PDF reader and record its version and environment. Run the all-fields and selective cases separately, each from its own untouched generated output.
Change attendee-name from Guest A to Guest B. Change room from Studio to Workshop. In the all-fields case only, change notes to Bring sketchbook. In the selective case, keep notes at its static Bring notebook content.
Save a distinct edited file for each case. Record the actual save operation used, the resulting path, and the saved file's hash. Do not overwrite the source HTML or the untouched generated PDF.
Close the document, then open the saved edited file by its recorded path. Inspect the current values again and compare them with the visible page:
| Reopened file | attendee-name target | room target | Notes target | Static identifier |
|---|---|---|---|---|
| All-fields edited copy | Guest B | Workshop | Field value Bring sketchbook | WK-01 |
| Selective edited copy | Guest B | Workshop | Static text Bring notebook; no notes field | WK-01 |
This table specifies what a successful test would show. It does not report a completed test.
Keep the initial generated PDF and saved edited PDF distinct in the ledger. If Guest A appears after reopening, first confirm that you opened the edited path. If the dictionary reports Guest B while the page displays Guest A, record both observations; persistence and appearance have not agreed. If the reader offers no workable save operation, record the limitation and leave the persistence result unresolved.
A result belongs to the tested converter, source revision, options, and reader. A second reader needs its own observation row. Do not turn one successful save into an all-reader guarantee.
Preserve the evidence without rewriting the source
Use one ledger row per mode and reader combination. Separate expected values from actual observations. Suggested columns include source revision, source hash, converter version, conversion options, generated output path and hash, inspector version, initial field names and values, reader version, edit values, save operation, saved path and hash, reopened field values, reopened visible content, and disposition.
The disposition can be pending, accepted for the recorded combination, or held with a specific discrepancy. A missing tool version or unavailable dictionary inspection should remain visible in that row.
After the reader test, check that the original HTML source hash is unchanged. Guest B belongs in the edited PDF for this experiment; changing the source to Guest B and generating a fresh PDF would answer a different question. Source edits require a new revision and a new comparison.
Before accepting the example, also review label placement, field boundaries, keyboard access in the intended reader, and the actual page layout. An optional HTML review page needs checks at the production article width and a narrow screen. These visual and accessibility checks are pending alongside native conversion and persistence testing.
Copy this prompt to prepare the example
The prompt asks for a specification and test plan. Its expected rows must stay separate from evidence collected later.
Create one complete, self-contained US-English HTML companion for “Workshop Form · Fillable PDF Preparation”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for Static; All fields; Selective; Rehearse Guest B / Workshop edits; Reset rehearsal; Compare entered evidence; Select source text; Select preparation notes. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Prepare an original HTML-to-fillable-PDF example specification and a native PDF acceptance ledger. Do not create files, run a converter, open a reader, or invent test observations.
Scope:
“Editable” means named fillable PDF fields. Do not promise arbitrary paragraph editing or reflow. This is a fictional internal workshop fixture, not a real reservation service.
Source revision R1:
- Plain static text: Booking ID WK-01. Do not implement it as a control.
- Labeled text input: name attendee-name, initial value Guest A.
- Labeled select: name room, options Studio and Workshop. Use matching option labels and values, initially Studio.
- Labeled textarea: name notes, initial content Bring notebook.
- No submit button, action URL, JavaScript, signatures, network requests, or real personal data.
Compare three conversion contracts using the same unchanged source:
1. Static: no global PDF forms option and no selective form styling. Expected named field count: zero.
2. All fields: use WeasyPrint's documented pdf_forms=True option or its CLI equivalent. Expected fields: attendee-name, room, notes.
3. Selective: do not enable the global all-fields switch. In a separate conversion stylesheet, set appearance: auto on attendee-name and room only. Leave notes static. Document relevant user-agent style overrides and require verification against the installed converter. Expected fields: attendee-name and room.
Keep the source and conversion styles separately identified. Record actual source SHA-256, converter version, options, generated output paths and hashes when those artifacts exist. Leave them blank now.
For every output, require an identified inspection method to report named fields and current values. Check names, counts, initial values, and visible static content. Unknown inspection results remain pending.
For the all-fields and selective outputs, plan these reader tests separately:
- Record the actual PDF reader version and environment.
- Change attendee-name to Guest B and room to Workshop.
- Change notes to Bring sketchbook only in the all-fields case.
- Save a distinct edited PDF without overwriting the source or initial output.
- Record the actual save operation, path, and saved hash.
- Close the document and reopen that saved path.
- Inspect current field values and visible content again.
- Expected all-fields result: Guest B, Workshop, notes field Bring sketchbook.
- Expected selective result: Guest B, Workshop, static Bring notebook with no notes field.
- WK-01 remains static and unchanged in both cases.
- Verify that the original HTML source hash is unchanged.
Produce:
A. A concise source-element specification. B. A mode/options/expected-fields comparison. C. A ledger with separate expected and actual columns. D. A save-close-reopen checklist. E. Discrepancy handling for missing or unexpected fields, unavailable inspection, unsupported reader operations, wrong reopened path, and disagreement between visible content and current field values.
All actual observations start blank or pending. A result applies only to the recorded source, converter, options, and reader. No all-reader guarantee, completed booking, or executed conversion claim.
The native generated and saved PDFs plus inspection records remain authoritative. An optional NOS HTML review may present the prepared specification and ledger; do not claim NOS PDF export, PDF editing, script execution, or reader persistence.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# HTML to Editable PDF: Choose the Fields, Then Check the Saved File
You export a workshop form to PDF, open it, and click the attendee name. Nothing happens. The name looks like an input, but its appearance does not tell you whether the PDF contains an editable field.
Start with the edit you actually need. For this walkthrough, “editable” means changing values in named, fillable PDF fields. The task is to update an attendee and room, save a separate PDF, close it, and find those values when you reopen that file. Editing an arbitrary paragraph and making surrounding content reflow is a different requirement.
The example below is an original, fictional workshop booking specification. Its conversions and reader checks have not been performed. Expected values are acceptance targets; actual field dictionaries, file hashes, and reader observations remain blank until tested.
## Keep one source and three conversion contracts
Use revision R1 of a small form with this content:
| Source element | Field name | Initial content | Intended role |
| --- | --- | --- | --- |
| Plain booking identifier | None | WK-01 | Static text |
| Text input | attendee-name | Guest A | Attendee value |
| Select with two options | room | Studio selected; Workshop available | Room value |
| Textarea | notes | Bring notebook | Notes value |
Give the controls visible labels and distinct names. For the room options, use matching labels and values: Studio and Workshop. This avoids introducing a separate display-label versus stored-value question into the first test.
WK-01 is a paragraph or similar plain text element. It is not a disabled input, hidden input, or fourth field. The fixture has no submission action, submit button, JavaScript, signatures, availability lookup, or real booking data.
Record the source revision and its SHA-256 hash before conversion. Keep the source unchanged throughout the comparison. Converter settings and a separate conversion stylesheet can differ by mode; preserve those alongside the source identity.
WeasyPrint's [PDF forms documentation](https://doc.courtbouillon.org/weasyprint/stable/common_use_cases.html#pdf-forms) describes a static default, an all-fields option, and selective field conversion using CSS. Reader support varies. The reference read for this article is labeled WeasyPrint 70.0; the installed converter and reader versions still need to be recorded.
Use three independently generated outputs:
| Mode | Conversion contract | Expected named fields |
| --- | --- | --- |
| Static | No all-fields option and no selective form styles | None |
| All fields | Python option `pdf_forms=True`, or the documented CLI equivalent | attendee-name, room, notes |
| Selective | No global all-fields switch; apply `appearance: auto` to attendee-name and room only | attendee-name, room |
These counts are specific to this three-control fixture. A larger source could contain other controls, so “three fields” is not a general converter rule. Inspect the output rather than copying a count from the settings.
## Make the selective case genuinely selective
A request to make just the attendee and room editable needs its own output. Turning on the global all-fields option and then calling the result “selective” would not establish that notes stayed static.
In the selective conversion stylesheet, target the text input named attendee-name and the select named room. Leave the notes textarea outside those selectors. For this mode, do not enable the global all-fields switch.
The official guidance also calls for overriding relevant user-agent styling when selecting fields with `appearance: auto`. Treat the precise styling and resulting appearance as implementation work to verify against the installed version. A control that looks correct in the source browser is not proof of the PDF's field structure. [WeasyPrint PDF forms](https://doc.courtbouillon.org/weasyprint/stable/common_use_cases.html#pdf-forms)
The selective acceptance target has two parts: exactly the intended named fields are available, and notes still displays Bring notebook as static content. Inspect both. Do not count three visible rectangles and infer three fields, or assume that being unable to click notes proves the field is absent.
Keep the static booking identifier visible in every mode. It should remain WK-01 after edits to the fillable fields. That gives the comparison an explicit piece of content that should never become a form value.
## Inspect field identity before editing
For each generated PDF, record its output path, hash, conversion mode, installed converter version, and actual options. Use a PDF inspection method that can report named fields and their current values. Identify the inspection tool and version rather than assuming the reader's visual interface exposes that information.
The initial targets are:
- Static output: no named form fields; the original content remains visible.
- All-fields output: attendee-name is Guest A, room is Studio, and notes is Bring notebook.
- Selective output: attendee-name is Guest A and room is Studio; notes is not a named field and remains visible as static text.
Compare field names as well as counts. Two unexpected fields do not satisfy the selective contract. Record unexpected names, missing fields, or different initial values as findings to resolve.
If field structure cannot be inspected with the available tools, mark that check pending. Successful clicking alone does not complete the dictionary check. Conversely, finding a field in the dictionary does not establish that the selected reader can edit and persist it.
## Save, close, and reopen the edited output
Choose an identified PDF reader and record its version and environment. Run the all-fields and selective cases separately, each from its own untouched generated output.
Change attendee-name from Guest A to Guest B. Change room from Studio to Workshop. In the all-fields case only, change notes to Bring sketchbook. In the selective case, keep notes at its static Bring notebook content.
Save a distinct edited file for each case. Record the actual save operation used, the resulting path, and the saved file's hash. Do not overwrite the source HTML or the untouched generated PDF.
Close the document, then open the saved edited file by its recorded path. Inspect the current values again and compare them with the visible page:
| Reopened file | attendee-name target | room target | Notes target | Static identifier |
| --- | --- | --- | --- | --- |
| All-fields edited copy | Guest B | Workshop | Field value Bring sketchbook | WK-01 |
| Selective edited copy | Guest B | Workshop | Static text Bring notebook; no notes field | WK-01 |
This table specifies what a successful test would show. It does not report a completed test.
Keep the initial generated PDF and saved edited PDF distinct in the ledger. If Guest A appears after reopening, first confirm that you opened the edited path. If the dictionary reports Guest B while the page displays Guest A, record both observations; persistence and appearance have not agreed. If the reader offers no workable save operation, record the limitation and leave the persistence result unresolved.
A result belongs to the tested converter, source revision, options, and reader. A second reader needs its own observation row. Do not turn one successful save into an all-reader guarantee.
## Preserve the evidence without rewriting the source
Use one ledger row per mode and reader combination. Separate expected values from actual observations. Suggested columns include source revision, source hash, converter version, conversion options, generated output path and hash, inspector version, initial field names and values, reader version, edit values, save operation, saved path and hash, reopened field values, reopened visible content, and disposition.
The disposition can be pending, accepted for the recorded combination, or held with a specific discrepancy. A missing tool version or unavailable dictionary inspection should remain visible in that row.
After the reader test, check that the original HTML source hash is unchanged. Guest B belongs in the edited PDF for this experiment; changing the source to Guest B and generating a fresh PDF would answer a different question. Source edits require a new revision and a new comparison.
Before accepting the example, also review label placement, field boundaries, keyboard access in the intended reader, and the actual page layout. An optional HTML review page needs checks at the production article width and a narrow screen. These visual and accessibility checks are pending alongside native conversion and persistence testing.
The prompt asks for a specification and test plan. Its expected rows must stay separate from evidence collected later.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Keep an optional HTML review beside the native evidence
Once the specification is settled, a prepared HTML review can put the three mode contracts and pending ledger in one readable place. Keep the actual generated PDFs, saved edited copies, and reader-specific observations as the evidence for this task.
The useful result is a clearly identified saved PDF whose intended fields retain the checked values in the reader you actually tested.