PDFium's path segment readout exposes only the destination point
of each segment via FPDFPathSegment_GetPoint, even for
FPDF_SEGMENT_BEZIERTO. The two control points stored internally on
CFX_Path::Point are not retrievable through any public C API, so
embedders cannot reconstruct cubic Bezier curves read from existing
PDFs.
The constructor side already exposes all six floats via
FPDFPath_BezierTo, so the asymmetry is purely on the readout side.
Proposed addition, mirroring the existing shape:
FPDF_EXPORT FPDF_BOOL FPDF_CALLCONV
FPDFPathSegment_GetBezierControlPoints(FPDF_PATHSEGMENT segment,
float* cp1_x, float* cp1_y,
float* cp2_x, float* cp2_y);
Behavior:
- Returns TRUE on success.
- Returns FALSE without modifying out-params when segment type is
not FPDF_SEGMENT_BEZIERTO.
Use case: every cross-language PDFium wrapper hits this limitation
when reading existing PDFs. pdfium-render's maintainer documented
the issue at
https://github.com/ajrcarey/pdfium-render/issues/55and the dedicated upstream-handoff issue
https://github.com/ajrcarey/pdfium-render/issues/99 was closed
2023-08-03 specifically asking for the upstream change. pypdfium2,
pdfium-rs, and an R binding (pdfium /
github.com/humanpred/rpdfium)
all currently document the limitation and lose curve geometry on
the read path.
Alternatives considered:
- Exposing the raw page content stream (e.g.
`FPDFPage_GetRawContents`) would also unblock this, but is a
much larger surface change with broader downstream impact.
- Embedders cannot recover control points geometrically - many
distinct curves share the same pair of endpoints.
Happy to draft the patch via Gerrit if there's interest.