Repository navigation
PDFCLOUD-6570 Add PDF-to-PostScript conversion - #55
Conversation
- Export the supported PostScript language levels for client callers. - Validate uploaded PDFs, page ranges, scale values, and output names. - Serialize the payload into the fields expected by the service. Assisted-by: Codex
- Expose sync and async helpers with typed conversion options. - Cover request serialization, validation, responses, and timeouts. - Bump the feature release version to 1.4.0. Assisted-by: Codex
- Exercise both language levels through sync and async clients. - Assert output metadata, page count, and language-level markers. - Confirm the service rejects invalid levels, ranges, and scales. Assisted-by: Codex
- Add runnable sync and async examples for PostScript levels 3 and 2. - Verify generated headers, language levels, page counts, and metadata. - Link the route and examples from the public documentation indexes. Assisted-by: Codex
- Verify default output serialization through both client transports. - Isolate live options and assert observable PostScript markers. - Derive live scale boundary cases from the payload schema. 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.
Focused review by Codex using the repository's pr-review-auditor guidance. Scope: the new PostScript page-range validation and opportunities to reuse existing Pydantic compositions.
Please replace the duplicated page-range parser/checks with a composition of the existing constrained range types and the smallest endpoint-specific adaptations. This follows AGENTS.md's requirement to favor declarative Pydantic validation and keep custom validators shape-focused.
Validation at 1efad81: the focused PostScript and shared graphic-payload suites passed (146 tests, Python 3.11); the committed diff passed git diff --check. A separate composition probe accepted and serialized the documented selections all, 1, 1,3-5, last, and 14-last. Live tests and the full interpreter matrix were not run for this focused validation-design review.
datalogics-kam
left a comment
datalogics-kam
left a comment
There was a problem hiding this comment.
Follow-up review by Codex using the repository's pr-review-auditor guidance, against 1efad816aab02cd62f5936cabbb3ac56c1013253.
Please address the two inline findings: the unsupported all,1 success case and missing assertions for the effects of rotation, shrink-to-fit, and annotation controls. The page-range finding is an acceptance criterion for the declarative composition already requested in the existing review; it does not prescribe retaining or modifying the separate regex/parser.
Validation on this unchanged head: the earlier review run passed 46 focused unit tests and 24 live tests on Python 3.11, plus Ruff, basedpyright, and diff checks. A live probe nevertheless showed that all,1 passes local validation and receives HTTP 400. The additional composition probe confirms that AscendingPageRange excludes all, while a standalone all alternative outside the collection can preserve that keyword and reject a mixed all selection. No source files were changed. The full local interpreter/example matrices were not rerun; current-head CI passed those checks.
|
I had Codex update the skill, see #56 |
- Compose PostScript page ranges from shared ascending selection types and reject combinations that mix all with explicit selections. - Replace annotation option smoke coverage with sync and async assertions against a deterministic printable annotation fixture. Assisted-by: Codex
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
datalogics-kam
left a comment
datalogics-kam
left a comment
There was a problem hiding this comment.
Human review of interface.
Codex reviews pass.
PDFCLOUD-6570
Why this change
The Python SDK did not expose pdfRest's PDF-to-PostScript operation, requiring callers to assemble requests outside the typed client. This adds a supported sync and async workflow for converting uploaded PDFs into print-oriented PostScript.
What changed (high level)
The new
convert_pdf_to_postscripthelpers accept uploadedPdfRestFileresources and delegate request validation and serialization to a dedicated Pydantic payload model. A publicPostScriptLeveltype makes the supported language levels discoverable, while the existing file-operation machinery resolves the generated resource into a typed response.Page selections compose the existing constrained page-range types with a standalone
allalternative. Small endpoint-specific adapters handle comma-separated input and wire serialization.Documentation and runnable sync and async examples demonstrate the upload, conversion, download, and verification flow. The package version moves to 1.4.0 for the additive public API.
Behavior changes
Callers can request PostScript level 2 or 3, page ranges, binary or text-safe output, scaling, rotation, shrink-to-fit behavior, printable annotations, and an optional output prefix. Omitting the output prefix leaves server-generated naming intact. The current service limitation affecting rotation and shrink-to-fit is described below.
Invalid MIME types, multiple input resources, unsupported language levels, malformed page ranges (including mixed selections such as
all,1), non-positive or non-finite scales, and invalid output prefixes fail locally before transport. There are no breaking changes to existing APIs.Validation
At
b92ea91, the focused PostScript unit suite and shared graphic-payload validation suite passed together with 146 tests on Python 3.11.17. The PostScript live suite passed with 20 sync/async tests. Live assertions verify language level, page selection, text-safe output, the legal scale boundary, custom output naming, and printable annotation behavior. Distinct sync and async annotation tests convert a deterministic annotated PDF with the option enabled and disabled, then compare PostScript output after removing creation timestamps. Unit tests verify request customization, timeout propagation, and serialization of rotation and shrink-to-fit options.Changed-file Ruff formatting and lint checks and the configured basedpyright check passed. The new annotation fixture passed
qpdf --check. Additional live checks confirmed stable normalized output for repeated annotation settings and changed drawing commands when annotations were disabled.Exact-head hosted checks passed: pre-commit, non-live tests and examples on Python 3.10–3.14, live tests on Python 3.11, and the strict documentation build. The local full Nox and example matrices were not repeated during the follow-up review because those checks passed in CI at the same head.
Risks and follow-ups
The public API is additive and uses the existing request and response infrastructure, so migration risk is low.
Live effect assertions for
rotateandshrink_to_fitare deferred. Production-service investigation using five varied PDFs found that the service accepted both options, but toggling them produced identical bounding boxes and rasterized output in the tested cases. The previous success-only smoke cases were removed because they did not establish that either option affected the result. This SDK change exposes and serializes the options; it does not resolve that service behavior.After the service demonstrates the documented rotation and fitting effects, restore distinct sync and async live tests using deterministic page geometry and overflowing content/scaling that exercise each effect. Assert the resulting orientation or fitted content and retain unit coverage for request serialization in the meantime.