This patch updates the minimum supported environments as follows:
- Node.js 22, which was initially released on 2024-04-24 and has now entered the "Maintenance"-phase; see https://github.com/nodejs/release#release-schedule
Furthermore, note also that Node.js 20 will reach end-of-life on 2026-04-30 which coincides (approximately) with the next PDF.js release.
While `Readable.toWeb` wasn't marked as stable until more recently, the functionality itself has existed since Node.js version `17.0.0`; note https://nodejs.org/api/stream.html#streamreadabletowebstreamreadable-options
Hence the polyfill shouldn't actually be necessary, which is confirmed by the unit-tests passing in Node.js version `20` in GitHub Actions.
This code already isn't used (or even bundled) in the Firefox PDF Viewer, and it also slightly reduces the number of import maps that need to be maintained.
Currently we have no less than three different, but very similar, factories for reading built-in CMap files, standard font files, and wasm files on the main-thread.[1]
These factories were added at different points in time, since I cannot imagine that we'd add essentially three copies of the same code otherwise.
Nowadays these factories are often not even used[2], since worker-thread fetching is used whenever possible to improve performance. In particular, they will *only* be used when either:
- The PDF.js library runs in Node.js environments.
- The user manually sets `useWorkerFetch = false` when calling `getDocument`.
- The user provides custom `CMapReaderFactory`, `StandardFontDataFactory`, and/or `WasmFactory` instances when calling `getDocument`.
By replacing these factories with *a single* new `BinaryDataFactory` factory/option the number of `getDocument` options are thus reduced, which cannot hurt.
This also reduces the total bundle-size of the Firefox PDF Viewer a little bit, and it slightly reduces the number of import maps that need to be maintained.
*Please note:* For users that provide custom `CMapReaderFactory`, `StandardFontDataFactory`, and `WasmFactory` instances when calling `getDocument` this will be a breaking change, however it's unlikely that (many) such users exist.
(The *internal* format data-format of `CMapReaderFactory` was changed in PR 18951, and there hasn't been a single question/complaint about it in well over a year.)
---
[1] Any new functionality could easily lead to more such factories being added in the future, which wouldn't be great.
[2] Note that the Firefox PDF Viewer no longer use these factories, since it "forcibly" sets `useWorkerFetch = true` during building.
Instead of having all the code for the new debugger in a single file,
split it into multiple files.
This makes it easier to navigate and maintain the codebase.
It'll be make hacking and fixing bugs in the debugger easier.
- Mention the internal viewer in the README, such that it's easier to find.
- Implement a new `INTERNAL_VIEWER` define, such that it's easier to limit code to only the "internal-viewer" gulp target.
- Only include the "GetRawData" message-handler when needed. Note that the `MessageHandler` [already throws](eb159abd6a/src/shared/message_handler.js (L121-L123)) for any missing handler.
- Move the various new helper functions from `src/core/document.js` and into their own file. The reasons for doing this are:
- That file is already quite large and complex as-is, and these helper functions are slightly orthogonal to its main functionality.
- Babel isn't able to remove all of the new code, and by moving this into a separate file we can guarantee that no extra code ends up in e.g. Firefox.
The one from pdf.js.utils is a bit too old: a lot of bugs have been fixed
in the code that parses PDF files since then.
It's just an internal development tool, so it doesn't need to be perfect,
but it should be good enough to be useful.
Using `0.0.0.0` instead of `localhost` allows connecting from other
devices, significantly simplifying testing on mobile devices.
This is controlled by the `--host` CLI flag and not enabled by
default, since allowing external connections comes with security
implications (e.g. when on a public network without a properly
configured firewall).
There might be reasons to want to listen on custom hostnames, but as
the most common usage will probably be `--host 0.0.0.0`, there is a
shorter alias `--host 0` for it.
When checking the code coverage report, it was noticed that the line numbers were off.
It was due to the fact that the files used for coverage were the transpiled ones,
when the ones used by Codecov were the original ones.
So this patches adds the source maps to the transpiled files, and also updates
the license header in the original files in using a babel plugin in order
to make sure the line numbers are correct.
As a side effect of this work, it's now possible to have the correct line
numbers in the stack traces when running tests with the transpiled files.
It's a first step to add code coverage.
In order to get the code coverage report locally, you can run the following command:
```bash
npx gulp unittestcli --coverage
```
The code coverage report will be generated in the `./build/coverage` directory.
And the report can be consulted by opening:
http://localhost:8888/build/coverage/index.html
A GitHub workflow has also been added to run the unit tests with code coverage
on each push and pull request. The report will be uploaded to Codecov.
This patch updates the minimum supported browsers as follows:
- Google Chrome 118, which was released on 2023-10-10; see https://chromereleases.googleblog.com/2023/10/stable-channel-update-for-desktop_10.html
We haven't made any changes to the supported Google Chrome version for a year, and this change allows us to remove "hacks" needed to support `float: inline-start/inline-end` in old browsers; see https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/float#browser_compatibility.
Note that nowadays we usually try, where feasible and possible, to support browsers that are about two years old. By limiting support to only "recent" browsers we reduce the risk of holding back improvements of the *built-in* Firefox PDF Viewer, and also (significantly) reduce the maintenance/support burden for the PDF.js contributors.
*Please note:* As always, the minimum supported browser version assumes that a `legacy`-build of the PDF.js library is being used; see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support
This should help reduce the maintenance burden of the code, since you no longer need to remember to update separate code when touching the different `DownloadManager` classes.
For now, `BrotliDecode` hasn't been specified but it should be in a
close future.
So when it's possible we use the native `DecompressionStream` API
with "brotli" as argument.
If that fails or if we've to decompress in a sync context, we fallback
to `BrotliStream` which a pure js implementation (see README in external/brotli).
This avoids the hassle of having to manually update that file when adding/modifying preferences in the viewer.
Updating the preferences-metadata should now only be something that the Chromium addon maintainer has to do.
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.
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)
