Repository navigation
PDFCLOUD-6572 Add ZUGFeRD PDF validation - #58
datalogics-tsmith wants to merge 13 commits into
Conversation
- Add typed rendering options for invoice appearance and localization. - Validate uploaded resources, color channels, fonts, and regeneration. - Serialize the public input shape into the pdfRest wire contract. Assisted-by: Codex
- Add synchronous and asynchronous helpers for uploaded invoice XML. - Support optional PDFs, logos, rendering controls, and request options. - Cover serialization, validation, response mapping, and both transports. Assisted-by: Codex
- Exercise every closed rendering option through both client transports. - Verify regenerated PDFs, response metadata, and server-side rejection. - Add a deterministic minimum-profile invoice fixture. Assisted-by: Codex
- Add a standalone typed example with a deterministic invoice fixture. - Verify the generated PDF and print useful response metadata. - Link the helper from the API guide and example inventories. Assisted-by: Codex
- Compose page ranges from typed ascending selections and reject invalid combinations before transport. - Add deterministic sync and async annotation assertions with a printable PDF fixture. Assisted-by: Codex
- Validate a single uploaded PDF resource before request serialization. - Model validation findings and response status fields returned by pdfRest. - Export the public response models for typed client consumers. Assisted-by: Codex
- Send uploaded PDF resource IDs to the validation endpoint. - Return typed results from synchronous and asynchronous clients. - Preserve request customization and timeout support. Assisted-by: Codex
- Verify payload serialization and local resource validation. - Exercise response literals, aliases, findings, and demo redactions. - Assert sync and async request customization and transport behavior. Assisted-by: Codex
- Exercise valid and invalid validation requests through both clients. - Confirm created and regenerated invoices pass validation and PDF/A checks. - Accept confirmed and demo-redacted content comparison results. Assisted-by: Codex
- Create a deterministic invoice before validating its conformance. - Display typed status, PDF/A, content-match, and finding details. - Add the workflow to the runnable example inventory. Assisted-by: Codex
- Link the validation helper from the electronic invoice API guide. - Describe package, content, and PDF/A conformance validation. Assisted-by: Codex
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
✅ Deploy Preview for pdfrest-python ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
datalogics-kam
left a comment
datalogics-kam
left a comment
There was a problem hiding this comment.
Reviewed only PR #58's incremental changes over PR #57 (7d951b6 to 02cb915), excluding the inherited creation implementation.
Requesting changes for the two inline test-coverage findings: add a real nonconforming-document validation case to the live suite, and make mocked response scenarios and assertions match across the synchronous and asynchronous clients. No runtime or CI regression was found.
Validation passed: 26 focused unit tests, 16 focused live tests, the Python 3.10–3.14 non-live Nox matrix (3,257 passed and 10 expected skips per interpreter), all class-coverage gates, Ruff formatting/lint, and basedpyright. Exploratory validation of the existing report.pdf fixture returned INVALID with pdfa=false through both clients; please preserve that behavior in regression tests.
datalogics-kam
left a comment
datalogics-kam
left a comment
There was a problem hiding this comment.
Follow-up to the existing review, scoped to the validation changes over PR #57 at the unchanged head 02cb915.
The existing findings remain recorded there. This review adds only the uncovered empty-resource-list boundary described inline; please add that regression coverage before merging.
No source files changed and no new runtime defect was found. Tests were not rerun for this posting step because the head is unchanged from the completed audit.
- Verify INVALID report.pdf responses live through both clients. - Match valid and demo-redacted response assertions across transports. - Cover empty resource-list rejection before request execution. Assisted-by: Codex
PDFCLOUD-6572
Why this change
The Python SDK does not expose pdfRest's ZUGFeRD validation operation, so callers cannot use the typed clients to verify an existing ZUGFeRD or Factur-X PDF. This adds a supported way to check package structure, embedded invoice XML, visible-content consistency, and PDF/A-3 conformance before accepting or distributing an electronic invoice.
What changed (high level)
New synchronous and asynchronous
validate_zugferd_pdfhelpers accept an uploaded PDF resource and return a typed validation response. A dedicated Pydantic payload model owns resource validation and wire serialization, while public response models preserve status, content-match results, findings, and free-tier notices with forward-compatible handling of additional response fields.The change also adds focused unit coverage, live endpoint coverage, creator-to-validator round-trip assertions, a runnable example, and API documentation.
Behavior changes
Callers can submit one uploaded PDF and receive its overall
VALIDorINVALIDstatus, independent PDF/A result, content-match status, input resource metadata, and detailed findings. Non-PDF inputs and multiple resources fail locally before transport. Free-tier responses with redacted comparison details remain parseable through the typed models.ZUGFeRD PDFs produced by
create_zugferd_pdfare now exercised through this validation route across all live render-option cases and the mismatched-PDF regeneration workflow. The API is additive and does not change existing helper behavior.Validation
The complete non-live suite passed with 3,257 tests and 10 expected skips. The Python 3.10-3.14 Nox matrix passed with the same results on each interpreter. The focused live creation and validation suites passed all 16 sync and async cases, including creator-to-validator round trips, invalid resource IDs, and server-side invalid-option rejection.
Ruff formatting and linting passed, basedpyright reported zero errors, the strict MkDocs build passed,
uv buildpassed, and the runnable validation example returnedVALIDwith PDF/A-3 conformance against the local service.Risks and follow-ups
Merge #57 first, then refresh this branch against
mainbefore merging so the final diff contains only the validation work. Demo-tier deployments can returnDEMO_REDACTEDfor content comparison details; callers still receive a parseable response and the overall validation status. CI on the main repository provides the final clean-environment verification.