Sync from Fork repo - #8
Open
venkatareddyboya-highspot wants to merge 898 commits into
Open
Conversation
Mouli-Namburu
approved these changes
Mar 7, 2025
espresso3389
force-pushed
the
master
branch
2 times, most recently
from
May 29, 2025 17:06
a4af6b3 to
80f4c96
Compare
espresso3389
force-pushed
the
master
branch
2 times, most recently
from
June 12, 2025 17:17
5748e8d to
6964170
Compare
espresso3389
force-pushed
the
master
branch
6 times, most recently
from
June 24, 2025 05:47
93e3826 to
e809415
Compare
espresso3389
force-pushed
the
master
branch
11 times, most recently
from
July 5, 2025 08:49
2e34c97 to
6bd3d1a
Compare
espresso3389
force-pushed
the
master
branch
2 times, most recently
from
July 16, 2025 19:57
e70f7b0 to
09a9ff3
Compare
`_requestRealSizePartialImage` was called with `pageScale`, which is `scale * (pageRect.size / page.size)`. Inside `_createRealSizePartialImage` that value is used as a document-to-pixel factor again (`fullWidth: pageRect.width * scale`), so the layout ratio is counted twice. With the default layouts the ratio is 1 and the two are identical, so nothing changes. With a custom `layoutPages` that lays pages out at a size other than their natural one, the high-resolution partial image is rendered at `ratio` times the resolution the viewer actually needs, and the page stays blurry no matter how far the user zooms in. Pass `scale` instead: it is the document-to-physical-pixel factor the partial renderer expects. The `pageScale > previewScaleLimit` threshold keeps using `pageScale`, which is correct there -- it compares a page-points-to-pixels density against the preview render scale.
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 5.7.0 to 6.0.0. - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@b6effb0...dd06d9c) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: 6.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…ctions/setup-java-6.0.0 Bump actions/setup-java from 5.7.0 to 6.0.0
…-layout fix: render real-size partial images at the document-to-pixel scale
feat(pdfium_dart): load PDFium on HarmonyOS (OHOS) via bare-name dlopen
… polling _notifyDocumentLoadFinished used to poll _imageCache every 100 ms until the initial page's preview image appeared before firing onDocumentLoadFinished. Replace the loop with a Completer that _cachePagePreviewImage completes as soon as it stores a preview image for the currently resolved initial page. The observable behaviour is unchanged apart from latency: the callback still waits for the initial page image, still re-resolves the initial page each time an image lands (calculateInitialPageNumber runs at the first layout, which can be after a replayed PdfDocumentLoadCompleteEvent), still returns immediately when the image is already cached, still gives up silently when the viewer is disposed or the document is replaced, and still keeps waiting if that page never renders. _documentLoadFinishedNotified semantics are untouched. _onDocumentChanged and dispose release any pending waiter so the awaiting future can observe the exit condition and nothing leaks.
…loading Progressive loading always walked the document from page 1, so a viewer opened at page 300 had to wait for pages 1..299 to be measured before its own neighbours got real dimensions. PdfDocument.loadPagesProgressively now takes an optional startPageNumber and measures pages in order of distance from it (start, start+1, start-1, start+2, ...), skipping pages that are already loaded. PdfViewer passes its clamped initial page. The end state is unchanged: every page ends up loaded and PdfDocumentLoadCompleteEvent is emitted exactly once. The progress callback now reports the number of loaded pages rather than the first unloaded index, since pages are no longer measured in page order. The PDFium and WASM backends honour the order; the WASM worker keeps accepting the previous parameters so older workers keep working. CoreGraphics loads all pages up front, so the parameter is a no-op there.
…prompting for passwords FPDF_LoadDocument/FPDF_LoadMemDocument/FPDF_LoadCustomDocument run on the BackgroundWorker isolate, but _openByFunc called FPDF_GetLastError on the caller isolate. PDFium keeps the last error in thread-local storage (Win32 GetLastError on Windows), so the caller read an unrelated value. The old workaround treated every failed open on Windows as a password error, which made a corrupt or non-PDF file call the PdfPasswordProvider over and over until it returned null and then surface as a PdfPasswordException. The worker callbacks now return both the document address and the error code captured right after the failed load, and _openByFunc only retries with the password provider on FPDF_ERR_PASSWORD; any other code raises a PdfException carrying that code. Even on the worker thread the value can be reset to 0 by an unrelated OS call between the two FFI calls (observed reliably for the first failing open after initialization on Windows, and sporadically at Dart VM safepoints). A failed load never legitimately reports FPDF_ERR_SUCCESS, so the load is retried a bounded number of times until a meaningful code is read; this is what keeps password prompting working for the first encrypted document an application opens. Adds tests for non-PDF input via openFile/openData/openCustom (expects FPDF_ERR_FORMAT and no password prompt) and a tiny AES-256 encrypted fixture (user password "user") covering prompting, wrong-password retry, PdfPasswordException and firstAttemptByEmptyPassword.
Track in-flight preview renders, repaint after transient cancellation, and defer native bitmap allocation until rendering begins. Add regression coverage for a page returning to the visible extent. Related to #691; the reproduced failure may not be identical to the original report.
Replace initial-page image polling with a completion signal while preserving canceled-preview retry handling.
…ionRegion for double-tap zoom
Synchronize custom PDF reads with a completion predicate and expose the in-memory loading threshold for data-backed documents.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.