Test Form Workflows Across HTML, PDF, JSON, CSV, FDF, and XFDF

An HTML form and a PDF form have layout, labels, controls, focus order, and validation cues. JSON, CSV, FDF, and XFDF usually carry values. Treating all six as page-design formats produces fake previews; treating all six as bare key-value files throws away the interaction and geometry that matter in HTML and PDF.

The useful shared layer is a canonical field contract. A field has a stable name, label, type, value, required state, options where relevant, and protection rules for sample or legal text. A layout editor can place those fields on a page. A values editor can expose the same field names and values without inventing a page that the source format never contained.

Form Studio keeps that distinction visible. HTML and PDF templates use layout mode. JSON, CSV, TXT, FDF, and XFDF templates use values mode. Both can participate in one round-trip test because they agree on field identity.

Start from the forms catalog, not from a blank file. Choose a family with at least one property your system must preserve:

• contact data with Unicode and multi-line notes;
• repeated checkbox or radio values;
• a tax, KYC, consent, or payment sample with protected SAMPLE markings;
• a fillable PDF with documented AcroForm field names;
• an HTML form and FDF/XFDF companions that share those names;
• a CSV row containing commas, quotes, or embedded newlines.

Write the assertion before editing. “The export opens” is too weak. A better assertion is: “Every field name survives export and re-import; the Unicode surname and multi-line note are unchanged; protected SAMPLE text remains; the PDF widgets receive the expected values.”

That statement tells you which formats can be compared directly and which need a field mapping.

In layout mode, test the visible form and the submitted field contract together. Change a label, add help text, reorder two editable fields, and set one field required. Keep any locked legal or SAMPLE notice in place. Export HTML and inspect both the rendered page and the source:

• each visible label points to the intended control;
• names and IDs stay stable where the contract requires them;
• special characters are escaped as content rather than interpreted as markup;
• required state and option values match the editor;
• the sample notice cannot be removed or pushed outside the safe area;
• importing the export reconstructs the same editable definition.

For a PDF, visible text is only half the test. Inspect the AcroForm dictionary or use a PDF form API to list field names and types. Fill values, save, reopen, and read them back. A PDF that paints a value onto the page but leaves the actual widget empty is not a successful form export.

FDF and XFDF companions provide context for this step. They describe values keyed to PDF fields; they do not describe the page geometry. Form Studio therefore shows the companion PDF relationship instead of inventing positions for a values-only file.

Values mode should feel like a field editor, not a raw-text guessing game. Each row shows the canonical name, current value, and any locked status. The original format still controls how those values are serialized.

For JSON, preserve JSON types where the definition declares them. A boolean should not become the string "true", and a number should not gain locale commas. Test quotes, backslashes, tabs, emoji, combining characters, and a multi-line string. Export, parse with an independent JSON parser, import again, and compare the canonical values.

For CSV, define the column order and newline convention. Test a value containing a comma, a quote, and an embedded newline. A conforming writer doubles inner quotes and encloses the entire field. Do not validate CSV by splitting on commas or lines; that recreates the bug the fixture is meant to catch. Parse the export with a real CSV parser, then compare headers and rows.

For TXT, the template definition must state its convention: key/value lines, fixed labels, or another explicit structure. A .txt extension alone does not define a form format. Verify the exact separator, newline style, encoding, and escaping rules declared by the fixture.

FDF uses PDF object syntax; XFDF expresses similar field data in XML. Both can carry names and values for a companion PDF, but their escaping rules differ.

For FDF, include values with parentheses and backslashes. Confirm the writer escapes them correctly and that an independent reader returns the original text. For XFDF, include XML-sensitive characters such as ampersands and angle brackets, then verify they are entity-escaped in the document and decoded on import. Multi-line values should remain multi-line rather than acquiring literal escape sequences.

Next, map the exchange file into its companion PDF. Compare the canonical definition, the FDF or XFDF field list, and the PDF AcroForm field list. Report missing and unknown fields explicitly. Silently dropping an unfamiliar field makes the result look complete while hiding a contract mismatch.

The safest comparison is directional:

1. canonical definition to exchange export;
2. exchange export through an independent parser back to values;
3. parsed values to companion PDF field names;
4. filled PDF reopened and read back to canonical values.

Each arrow catches a different defect. Collapsing them into one “export succeeded” check makes the failing layer impossible to locate.

Realistic tax, identity, medical, consent, loan, and payment forms need obvious fictional-data markings. Those markings are part of the fixture’s safety contract, not decoration.

Try to delete a locked SAMPLE notice. Try to resize a page so the notice falls outside the safe area. Try to import a values file that supplies a field with the same name as a protected label. The editor should preserve the protected node or field and explain why it cannot be replaced.

Then inspect every export family. HTML and PDF should visibly retain the notice. Values-only formats should retain any protected marker defined as data, and they should retain companion context explaining that the content is fictional. A conversion path must never turn a clearly marked sample into something that resembles a completed real-world form.

You do not need all 243 form fixtures in every CI run. Select representative rows:

• one accessible HTML form with required and grouped controls;
• one fillable PDF with text, checkbox, radio, and choice fields;
• one JSON object with typed and Unicode values;
• one CSV row with quoting and embedded newlines;
• one TXT convention with a documented separator;
• one FDF and one XFDF file sharing a companion PDF;
• one protected legal or SAMPLE template.

For each row, record the fixture URL, canonical field count, protected fields, export format, independent parser, and expected round-trip values. Keep the original file beside the exported result so byte or structure differences can be reviewed against a known control.

Use live form examples separately for focus, validation, keyboard, autocomplete, and browser submission behaviour. A downloadable HTML fixture can test structure, but a live page is the better target for timing and interaction assertions.

Cross-format form testing works when every format is allowed to be what it really is. HTML and PDF can preserve layout and interaction. JSON and CSV preserve structured values. FDF and XFDF exchange values with PDF fields. TXT preserves only the convention its fixture declares.

Anchor all of them to stable field identities, use independent parsers on re-import, test hostile escaping cases, and protect fictional-data notices. You will get a precise answer to the question that matters: not “do these files look similar?” but “did the workflow preserve the same form contract?”