
For PDF thumbnails, PDFiumEngine::RequestThumbnail() should be drawing the original thumbnail, without any Ink strokes. PdfInkModule::DrawThumbnail() separately draws the Ink strokes as another layer on top of the original thumbnail. With the work in https://crbug.com/335517469, now the PDF loaded in PDFiumEngine contains Ink strokes, so refreshing PDF thumbnails will end up rendering the Ink strokes twice. Fix this by temporarily deactivating the page objects associated with Ink strokes for a given page when generating the thumbnail for that page. Bug: 395766076 Change-Id: I565df2f21b3fae8cf6ebe4df44149f3709fe149a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6271523 Commit-Queue: Lei Zhang <thestig@chromium.org> Reviewed-by: Alan Screen <awscreen@chromium.org> Cr-Commit-Position: refs/heads/main@{#1422737}
//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.