Make it clear that it is always dealing with a dictionary, and not some
other type of base::Value. Then recursively convert its callers and
callees to use base::Value::Dict as well. Switching to using
base::Value::Dict APIs removes a bunch of deprecated base::Value API
usage.
Bug: 1303949
Change-Id: I63cfdfd09a2ac2c5f24c2257c93ba41622abc69f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3580051
Reviewed-by: K. Moon <kmoon@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#991252}
Attempts to fix RefreshCurrentDocumentLayout() crash by handling "no
pages" identically to other cases. Without this change, the number of
pages in the layout may differ from the number of pages in the engine.
This fix is speculative because we currently don't understand how the
page count is dropping to 0, although we have some theories about Print
Preview that we're investigating.
Bug: 1264542
Change-Id: I7192589d8f2f3c8855275809ec35689217766201
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255868
Commit-Queue: K. Moon <kmoon@chromium.org>
Auto-Submit: K. Moon <kmoon@chromium.org>
Reviewed-by: Hui Yingst <nigi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#937112}
Extends chrome_pdf::DocumentLayout::Options with a field for the UI
direction (left-to-right or right-to-left). This allows the viewer UI to
communicate the UI direction to the plugin. (This information is
available from base::i18n::IsRTL() in unseasoned mode, but is not
available to the Pepper plugin. In any case, it could be useful to make
it togglable in the PDF viewer.)
The UI direction field could have been added to the viewport message
directly, but it likely will be useful to support RTL page layouts in
the future.
Also adds some serialization and deserialization tests, now that Options
serializes to and from base::Value. Also had to fix a bug with dirty
layout options triggering layout before document loading finished.
Bug: 1158670
Change-Id: Iaa7cfccacfe54858a53d6e28b07f786332d7e9e8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3202535
Reviewed-by: Daniel Hosseinian <dhoss@chromium.org>
Commit-Queue: K. Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#927933}
There are currently two public methods for layout computation, one for
each page spread. The page spread is already stored in the layout
options, which is a member of the DocumentLayout class. A unified method
should be able to deduce the page spread from its options.
Bug: 1144505
Change-Id: I0a73d0e2282f7feb55aa1896144ab17180e6ca18
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2842688
Commit-Queue: Daniel Hosseinian <dhoss@chromium.org>
Reviewed-by: K. Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/master@{#875787}
The enum tracks the page spread of a document layout (e.g., one-up view
or two-up view).
Currently, the two supported page spreads are one-up view and two-up
view with odd pages to the left. This is the first step towards making
the PDF document layout code scalable to another page spread.
The ultimate goal is to also support two-up view with even pages to the
left.
Bug: 1144505
Change-Id: Icbe320fad69d69e47cb049c4bd132d97be86810c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2842278
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Daniel Hosseinian <dhoss@chromium.org>
Cr-Commit-Position: refs/heads/master@{#874965}
Update draw_utils/coordinates.*, document_layout.* to use gfx::Size
instead of pp::Size. Also updated OutOfProcessInstance and PDFiumEngine
that use these files.
Bug: 1101101
Change-Id: I5d8db1d2528100035511edfb479a8e401cc33b2e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2323481
Commit-Queue: Ankit Kumar 🌪️ <ankk@microsoft.com>
Reviewed-by: K. Moon <kmoon@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#793091}
1. Add a two-up view flag inside DocumentLayout::Options. Modify
layout_test.js accordingly and add matching unit tests.
2. Add backend support for handling message type "setTwoUpView",
which will update viewport's layout options and apply the changes.
3. Add unit tests for PDFiumEngine::SetTwoUpView().
Bug: 51472
Change-Id: I212418b439e860feb9e6ed8761a5f722f2a14a9d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1976156
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Hui Yingst <nigi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#732517}
DocumentLayout now sets a "dirty" bit if (and only if) the layout
changed. The current behavior only looks at changes to the overall
document size, which is inaccurate in cases such as orientation changes
that may change the layout of individual pages, but not the overall
document size (for certain combinations of page sizes).
This doesn't matter in the current code (the DocumentSizeUpdated event
might not fire, which is mostly harmless), but the fix for bug 885110
requires accurately detecting and reporting layout changes to the
viewer's JavaScript code, so DocumentLayout has been instrumented to
detect all current triggers for layout changes:
* Default page orientation changes
* Overall page count changes
* Overall document size changes (possibly redundant)
* Individual page layout rectangle changes
Bug: 885110
Change-Id: I0edfe2ad7af73abd1f176477826901b767c28b2e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1810032
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: K Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/master@{#698235}
The set_size() method is used externally only for testing at this point,
and provides a dangerous API for violating layout invariants.
Remove this API now to avoid having to modify it in a later change to
add dirty tracking to DocumentLayout.
Bug: 885110
Change-Id: Idb03aaad86131b625589ac07c48c9284caaf0919
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1810237
Commit-Queue: K Moon <kmoon@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#697761}
Refactors PDFiumEngine::AppendBlankPages() to leverage the layout code
in LoadPageInfo(), instead of using a separate copy. AppendBlankPages()
now ensures |PDFiumEngine::pages_| is in the right state for a later
layout pass, rather than trying to compute all the layout up front when
the new PDFiumPage instances are created.
This duplication is particularly harmful because AppendBlankPages() is
only called from print preview code paths, and so may be overlooked if
not testing print previewing specifically.
Also inlined PDFiumEngine::LoadPagesInCurrentLayout(), since this method
is only used in one place (and we're trying to centralize layout), has
simple logic, and will become much shorter once the two "compute layout"
methods are merged together.
Bug: 885110
Change-Id: Ic0ae2410ca930794beeb28983b9d0cc5e89284f4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1769708
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: K Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/master@{#691858}
This change splits DocumentLayout::page_rect() into two methods,
page_rect() and page_bounds_rect(), to better mirror the corresponding
APIs in PDFEngine, GetPageRect() (page rectangle before insets) and
GetPageBoundsRect() (page rectangle after insets).
The existing page_rect() method is equivalent to PDFEngine's
GetPageBoundsRect(), which is confusing, so it has been renamed to
page_bounds_rect(). The new page_rect() method is equivalent to
PDFEngine's GetPageRect(). (This will be useful in a future change.)
DocumentLayout is now responsible for adding insets to the page
rectangles returned by draw_utils::GetRectForSingleView(), etc.,
eliminating the need to pass the insets to these functions.
Bug: 885110
Change-Id: I4ef345333abbb5b75892c32ffff8dee24e20ef05
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1762601
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: K Moon <kmoon@chromium.org>
Cr-Commit-Position: refs/heads/master@{#689735}
This change moves primary ownership of a page's "layout rectangle" from
individual PDFiumPage objects to the DocumentLayout as a whole.
Conceptually, a page's rectangle in the layout really is a property of
the layout, and not of the PDFium-specific page data structure: A
PDFiumPage should be a client of the layout, not vice versa.
This change also allows multiple layouts to exist simultaneously: The
shared, per engine PDFiumPage-based layout rectangles currently prevent
calculating different layouts independently.
To minimize the size of this refactoring, for now the PDFiumPage retains
a secondary copy of the layout rectangle for use during painting and
coordinate transformations. This copy should only be updated when
PDFiumEngine::ApplyCurrentLayoutToPages() is called, after a layout
change.
Bug: 885110
Change-Id: I8aac622e80f0779c556b8873ab085c6106f92c6e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1746084
Commit-Queue: K Moon <kmoon@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#686933}
After formatting the given pages to two-up view,
DocumentLayout::GetTwoUpViewLayout() should double the current width
of the layout.
Bug: 51472
Change-Id: I3a0c984f576ad571045adffefbc30865459dd62e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1742395
Commit-Queue: Jeremy Chinsen <chinsenj@google.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#684965}
Currently the DocumentLayout::Get*ViewLayout() functions rely on the
current width of DocumentLayout to generate their respective layouts.
This creates a dependency between Get*ViewLayout() functions and its
caller.
This CL refactors the Get*ViewLayout() functions to derive the width
of the document based on the given vectors of pp::Size objects,
removing the coupling described above.
Change-Id: I898c267ddc95e2873909c750766333c3d053a555
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1742393
Commit-Queue: Jeremy Chinsen <chinsenj@google.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#684961}
Changes the type of the default page orientation from an int to an enum
class, chrome_pdf::PageOrientation. The RotateClockwise() and
RotateCounterclockwise() operations step through the orientations.
Also adds a chrome_pdf::ToPDFiumRotation(PageOrientation) helper to
convert PageOrientation enums to the equivalent integer expected by
PDFium APIs like FDPF_RenderPage().
Bug: 885110
Change-Id: I05d69a8548bf5b72666e6d58136440815ba8d15c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1740649
Commit-Queue: K Moon <kmoon@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#684900}
Currently the generation of the single-view layout in PDFiumEngine is
untested. To make the generation of these layouts testable the following
helper functions are being added:
draw_utils::GetRectForSingleView(), given the current document size
and a page's size, returns a page rect formatted for single-view.
Document::GetSingleViewLayout(), given a vector of page sizes,
returns a vector of page rects formatted for single-view and updates
the size of the document.
Bug: 51472
Change-Id: Ie9e746cc4fedda551ccfb22aab4b3b64822c6b89
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1739666
Commit-Queue: Jeremy Chinsen <chinsenj@google.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#684616}
Currently the PDFiumEngine::LoadPageIn*View() functions take vectors of
pp::Rect objects. However, prior to calling these functions the
position of the rectangles don't matter, just the size and ordering.
This CL refactors LoadPageIn*View() to take a vector of pp::Size
objects instead of pp::Rect objects. This makes the LoadPageIn*View()
functions fully responsible for the positioning of the pages, making
it possible to test the single-view layout logic.
Bug: 51472
Change-Id: I35c9ce30152be567c1034218d68f7284b57fc0dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1739587
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Jeremy Chinsen <chinsenj@google.com>
Cr-Commit-Position: refs/heads/master@{#684578}
Due to the loose, asynchronous coupling between the C++ and JavaScript
portions of the layout code, we need to pass certain layout "options"
(such as the default page orientation) back and forth by value.
As a result, it makes sense to have a separate Options class to hold
these settings, which then can be used to recalculate the layout.
The expected layout lifecycle eventually should look like this:
1. Update desired layout options one or more times.
2. Estimate layout size with new layout options.
3. Send options and estimated size to JavaScript.
4. Receive updated options from JavaScript.
5. Apply final options to current layout.
6. Repaint using updated layout.
As a side effect of this change, I added the desired_layout_options_
field to PDFiumEngine. This new field holds the mutable state about
page orientation that was split off into DocumentLayout::Options.
Miscellaneous changes:
* Revised some of the API comments for DocumentLayout
* Eliminated need for unsigned math by replacing -1 with +3 (mod 4)
* DocumentLayout no longer needs to be copyable, so it isn't
Bug: 885110
Change-Id: I89714c4c2cba6c0ab354c0696ec3943327c979d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1733795
Commit-Queue: K Moon <kmoon@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#684441}
Currently PDFiumEngine can only generate a single-view layout for
documents.
This CL adds DocumentLayout::GetTwoUpViewLayout() which takes a vector
of pages and returns the pages formatted for two-up view, as well as
updates the size of the layout. This helper function makes the two-up
view layout testable.
This CL also adds PDFiumEngine::LoadPagesInTwoUpView() which calls
DocumentLayout::GetTwoUpViewLayout() to format pages in two-up view
and appends them to |pages_|. This allows PDFiumEngine to render
documents in two-up view.
Bug: 51472
Change-Id: I6b65210f32efc205376d53abaeaa0c6eab84ac2d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1733737
Commit-Queue: Jeremy Chinsen <chinsenj@google.com>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#684197}
Refactors layout-specific state (document size, rotation) from
PDFiumEngine into a separate DocumentLayout class. This will allow new
layouts to be computed without disturbing the current layout.
As a side benefit, this should be another step towards simplifying
PDFiumEngine to be less of a grab bag of concerns.
Bug: 885110
Change-Id: Ieabde78d8acdcb2f83aac980d03f6fd8f28295a4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1716158
Commit-Queue: K Moon <kmoon@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681422}
