Unfortunately I wasn't able to come up with a *simple* way to just replace the synchronous `require`-call, since we need to ensure that the default preferences are available when bundling starts.
Hence this patch adds a new intermediate parsing-step in all the relevant gulp-tasks, but this shouldn't affect build-times noticeable since the amount of extra parsing is very small.
*Please note:* It's very possible that there's a better way to handle this, however I figured that unblocking further ESM-work is more important than a "perfect" solution.
createImageBitmap doesn't work with svg files (see bug 1841972), so we need to workaround
this in using an Image.
When printing/saving we must rasterize the image, hence we get the biggest bitmap as image
reference to avoid duplications or poor quality on rendering.
The existing code is unable to *correctly* extract the color from the appearance-stream when the ColorSpace-data is "complex". To reproduce this:
- Open `freetexts.pdf` in the viewer.
- Note the purple color of the "Hello World from Preview" annotation.
- Enable any of the Editors.
- Note how the relevant annotation is now black.
Note how we're accidentally using the wrong operator when trying to parse CMYK colors. I'm not aware of any bugs caused by this, since it seems uncommon in practice for annotations to specify text-colors in CMYK format.
When there was a rotation, the generated bbox was wrong because of an inversion
between width and height.
This patch aims to fix this issue in re-writing the FreeText code generation
to have something similar to what Acrobat does.
And fix the name of the font which wasn't the correct one when calling the
evaluator.
- Update the "Getting the Code" section to specifically mention Mozilla Firefox, since while the development viewer *works* it may look slightly "broken" in Chromium-based browsers. (This is caused by a lack of support for unprefixed CSS properties, e.g. `mask-image`, however this does *not* affect the built PDF.js viewer.)
- Remove the Twitter-link, since that account has not been updated since 2016 (i.e. over seven years ago).
Semantically, it is more correct to encode the fragment in the URL
instead of the URL-encoded `file` query parameter. This shouldn't matter
in practice, because `rewriteUrlClosure` in `chromecom.js` decodes the
`file` parameter and restores the fragment. However, as #16625 shows,
there was a case where this did not work as expected.
`PDFViewerApplication` reads from `location.hash` to initialize
`initialBookmark`. But when extensions/chromium/pdfHandler.js prepares
the redirect URL, the reference fragment is encoded instead of bare.
`rewriteUrlClosure` in `chromecom.js` is responsible for decoding the
URL, but that currently runs too late.
To fix this, update `initialBookmark` after rewriting the URL.
This was not a problem in the past because `rewriteUrlClosure` in
`chromecom.js` executed before the initialization of `initialBookmark`.
