
Sometimes the Ink strokes applied to a PDF page can be slightly shifted in position compared to when the stroke was in the process of being drawn by the user. This is particularly noticeable for PDF pages whose size in points has a non-zero fractional component. To ensure consistent positioning between in-progress and applied strokes, update the GetInkRenderTransform() logic to match the approach that PDFium's CPDF_Page::GetDisplayMatrix() uses when drawing PDF pages. This includes omitting some instances of doing minus one for 90, 180, and 270 degree rotations. Bug: 380038343, 399133248 Change-Id: Ie9b8ca573420d558b5e17f0c67e732743f37455f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6311352 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Alan Screen <awscreen@chromium.org> Cr-Commit-Position: refs/heads/main@{#1426629}
//pdf
contains the PDF plugin, its Blink-based replacement, as well as PDF
utility functions that leverage PDFium. It can use low-level components that
live below the content layer, as well as other foundational code like
//printing
. It should not use //content
or anything in //components
that
lives above the content layer. Code that lives above the content layer should
live in //components/pdf
, or in the embedder. All the code here should run in
sandboxed child processes.
TODO(crbug.com/40186598): Remove existing //content
dependencies.