Auto paging now uses last element offset for specific page #3718
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.
Auto paging now remembers last element offset for all pages and uses correct one depending on page to prevent weird text offset. This happened because html2canvas doesn't send elements in order so it is possible that element from page 4 will arrive before element from page 1. Specifically in added test
<em>basic></em>
and<strong>tiptap</strong>
will be processed as last elements for this pdf.Note that this also means that it should be probably possible to create element which will not correctly increase offset (example: if above tiptap would need to be moved to next page it will cause that offset for pages 2-4 will be wrong).
Note also that based on how pages are retrieved it should be also possible that these elements might be positioned on wrong page (example: if we would have 100 pages that would increase offset by more than a page getPagesByPath would return +1 page for tiptap even if it should be on first page)