de5bfed5be
Give PdfInkModule the ability to call its client to load Ink data from PDFs. PdfViewWebPlugin, the production client, asks PDFiumEngine to do this. PDFiumEngine, in turn, uses code from pdfium_ink_reader.h to fulfill the request. The Ink data from PDFs load as ink::ModeledShape objects. Each object gets a unique ID. PDFiumEngine stores an ID to FPDF_PAGEOBJECT mapping, while PdfInkModule gets back an ID to ink::ModeledShape mapping, bucketed by page index. For now, just do the plumbing and store the data in PdfInkModule using LoadedV2ShapeState, which is essentially the same as FinishedStrokeState, but for shapes. In the near future, PdfInkModule will use its data structure to perform hit tests to determine if the paths in the PDF should be erased. It will coordinate with PDFiumEngine to erase the objects in the PDF. Bug: 353942910 Change-Id: I2fe6fb19d1e0fba9147eca1688d8a30e3695e9c4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5997152 Reviewed-by: Andy Phan <andyphan@chromium.org> Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/main@{#1380769}
//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.