Repository navigation
PDF: batch native path evidence - #24
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: be0b1a1db2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 732152ffb0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let rounded = subpath | ||
| .points | ||
| .iter() | ||
| .map(|&(x, y)| ((x * 1000.0).round() / 1000.0, (y * 1000.0).round() / 1000.0)) |
There was a problem hiding this comment.
Use Python-compatible rounding for open-path corners
When a transformed coordinate is exactly halfway at the third decimal, Rust's round() uses ties-away-from-zero while Python's round(value, 3) uses ties-to-even. For example, the open filled path (0,0) → (10,0) → (10,0.062) → (0,0.0625) passes the Python corner-set and axis-alignment checks but is rejected here because 0.0625 becomes 0.063 instead of 0.062, so the native backend omits a drawing line emitted by the reference backend. Apply Python's rounding semantics to both the actual and expected corner sets.
Useful? React with 👍 / 👎.
| unsafe fn color(raw: *mut c_void, getter: ColorFn) -> Rgba { | ||
| let (mut red, mut green, mut blue, mut alpha) = (0, 0, 0, 255); | ||
| if getter(raw, &mut red, &mut green, &mut blue, &mut alpha) == 0 { | ||
| return (0, 0, 0, 255); |
There was a problem hiding this comment.
Preserve unknown fill colors instead of fabricating black
When FPDFPageObj_GetFillColor returns failure for a filled path, the Python reference treats the alpha as opaque only for visibility but stores fill_rgba=None; this fallback instead publishes (0, 0, 0, 255). On malformed or unsupported color states, consumers such as _path_has_visible_nonwhite_fill() consequently treat an unknown fill as a confirmed black background and can create spurious code-block evidence. Keep the visibility fallback separate from the optional RGBA value.
Useful? React with 👍 / 👎.
Summary
634aabe; private protocol advances 25 → 26.PDFPathInfo.math.hypotkeeps stroke-width floating-point results bit-for-bit equivalent.Correctness
dev@ee87e8e: 31 eligible Flash text outputs and 32 medium shared-chain outputs all matched Stage 18.-D warnings, rustfmt, Ruff check, and changed-file format checks passed.f6dcdb5654cd30c3617aecbc22fd57ec3c1a49b8aa6d1e13ef2e3df062ec0ab2.Performance
Formal measurements use one warmup plus five hot runs per document, paired baseline/candidate execution, and isolated process-tree RSS sampling.
Gates:
Diagnostics show
_extract_page_paths_and_lines()fell from 0.940791 s to 0.129739 s (86.2%) in the matched cProfile run. The original 2× performance target remains incomplete.Evidence:
docs/rust-pdf-stage19-evidence.mdandoutput/pdf/native-kernel-20260929-stage19/locally.Not done
PDFPageTextGeometry.charsmaterialization (about 80.5% of the profiled visual-evidence time), followed by native text-snapshot page/textpage ownership.