Some gradients are represented as patterns in PDF.js, because they
mustn't be affected by the current transform. But in most of the cases,
the gradient is attached to the origin and the current transform is very
basic (dilatation + orthogonal + translation). In those cases, we can
avoid creating the pattern because the gradient is transformed into
another gradient when the inverse transform is applied.
This commit extracts the logic to draw a line from one coordinate to
another to both remove code duplication (8% of the total number of lines
in the file are removed) and clarify the intent of the individual tests.
Update the styles and HTML to reflect the new views manager concept.
For now, nothing about split/merge functionality is implemented or visible.
The new styles for the outline, attachments, and layers will be added later.
The thumbnail view is now accessible with the keyboard.
Fixes https://github.com/mozilla/pdf.js/issues/11595, where cancelling loading with `loadingTask.destroy()` before it finishes throws a `Worker was terminated` error that CANNOT be caught.
When worker is terminated, an error is thrown here:
6c746260a9/src/core/worker.js (L374)
Then `onFailure` runs, in which we throw again via `ensureNotTerminated()`. However, this second error is never caught (and cannot be), resulting in console spam.
There is no need to throw any additional errors since the termination is already reported [here](6c746260a9/src/core/worker.js (L371-L373)), and `onFailure` is supposed to handle errors, not throw them.
By setting `display: contents` on `.markedContent` containers, they stop
affecting the layout of their children. This means that we can always
position text layer `<span>` elements using percentages relative to the
page dimensions, rather than having two separate code paths.
For some reason this breaks the workaround for text selection flickering
in Chrome/Safari, which can be fixed by setting `user-select: text` on
the `.endOfContent` div (only in Chrome/Safari, as it would break
selection in Firefox).
This commit moves all the logic to scale up&down `<span>`s in the text
layer, introduced in #18283, to CSS.
The motivation for this change is that #18283 is still not enough for
all cases. That PR fixed the problem in Chrome&Firefox desktop, which
allow users to set an actual minimum font size in the browser settings.
However, other browsers (e.g. the Chrome-based WebView on Android) have
more complex logic and they scale up small text rather than simply
applying a minimum.
A workaround for that behavior is probably out of scope for PDF.js
itself as it only affects not officially supported platforms. However,
having access to the actual expected font height (through
`--font-height`) allows embedders of PDF.js to implement a workaround by
themselves.
The goal is to be able to catch the errors before making a release.
And fix some css issues (especially the missing css code for the newly added menu.css)
