The `requirements.txt` files of the two Python-based builds only listed
the top-level dependency, and thus not the full dependency tree, and
only limited it via a version range. This means that the actual versions
we use for the builds are determined at runtime, and can thus easily
change if a new version gets published. This causes the builds to not be
deterministic, and it's in contrast to the JavaScript-based builds where
`package-lock.json` pins the full dependency tree with fixed versions.
This commit changes the `requirements.txt` files to follow the same
approach as `package-lock.json` and thus pin the full dependency tree to
fixed versions. This ensures deterministic builds, improves consistency
and provides better protection against e.g. supply chain attacks by not
automatically pulling in new versions as they are published (but rather
make updating versions a conscious and verifiable/auditable action). To
simplify the update process, and make it repeatable, we document the
full one-line generation commands inline.
The `requirements.txt` files of the two Python-based workflows were not
included in the file-based allowlist, which prevented the font/Fluent
linter tests from running if their contents changed. This commit fixes
that oversight from the original introduction of the workflows.
If one of our dependencies changes it can have an effect on all tests we
have, for instance via the test runner, bundler or coverage collector.
This commit therefore updates all workflows that work with a file-based
allowlist to also trigger on `package-lock.json` changes so that we have
more certainty that any unintended effects of dependency updates can't
go by unnoticed, and thus improve stability.
In these cases there's no need for a temporary variable, since the result of the asynchronous operation is returned as-is without any additional parsing.
On some OSes, the current approach of using `Highlight`/`HighlightText`
colors to draw selected text doesn't work when the OS is set to dark
mode, as we revert the `color-scheme` to `light` to compute them
(because PDFs are normally in light mode) but that does not affect the
`HighlightText` color (which depends not on the `color-scheme` but on
the `currentColor`).
Other than forcing the `color-scheme` to `light`, set the `color` to
`black` and use the `backgroud-color` to compute the `HighlightText`
color instead.
In OSes where `HighlightText` is theme-dependent this will result in the
OS-provided text color, while in OSes where it is `currentColor`-dependent
it will be based on the default color for light themes (i.e. black).
A lot of these (often old) handlers don't need any parameters, hence their `data` parameters needlessly increase code-size.
Also, for the functions that do need parameters, use parameter destructuring consistently throughout the message-handler functions.
Any errors are already propagated via the stream-sinks, since these handlers use `ReadableStream`, and as mentioned in the TODO-comments re-throwing errors will lead to "spam" in the console; hence let's just remove them.
This function is mostly covered indirectly by higher-level tests, but
unlike the other core utility functions it lacked dedicated unit tests.
This commit implements unit tests for it that also cover the previously
uncovered exception case, which brings coverage of the function to 100%
and ever so slighly increases coverage of the overarching file.
When the marked content `id` is defined it'll always be a string, hence wrapping it in a string when setting the attribute is pointless; note e148b154cd/src/core/evaluator.js (L3529-L3531)
Using an intermediate variable seems completely unnecessary here.
Also, while unrelated, move a `HINTING_ENABLED` check to avoid pointless Array-length checks.
`getCharacterType` was a port of the old `WordBreaker::GetClass`,
which has been removed and replaced with ICU4X word segmentation.
Use `Intl.Segmenter` instead, testing each match boundary on the two
adjacent grapheme clusters in isolation like Firefox's find.
It fixes#21520.
Despite the `enableSignatureVerification` option/preference being enabled in development mode and TESTING builds, the lack of any `SignatureVerifier` implementation still renders the UI disabled.
This seems unfortunate, since it makes it more difficult to check that the digital signature UI works correctly:
- That the button is visible when it's supposed to be, and that the panel can be opened/closed.
- That the UI looks correct, w.r.t. the HTML elements and their CSS rules.
- Currently the viewer JS code is effectively uncovered, with overall test-coverage dropping from `90` to `89` percent when PR 21247 landed.
To improve the current situation this patch adds a `FakeSignatureVerifier` class, limited to only development mode and TESTING builds, that treats every digital signature as invalid.
This allows easier manual testing, and also the addition of a few *very rudimentary* integration-tests.
*Note:* It probably wouldn't be all that difficult to add additional integration-tests for *valid* certificates, by having the test-cases instruct (during setup) the `FakeSignatureVerifier` how to respond to simulate verified certificates.
Note that PR 21247 did include "local" unit-tests, however they don't cover all of the relevant API/Worker code-paths (which is noticeable in the coverage data).
The new unit-test added here uses a PDF document already present in the test-suite, and generally speaking testing a real-world PDF shouldn't hurt.
Note that the `prettier` update introduces a handful of formatting
changes (see https://prettier.io/blog/2026/06/27/3.9.0).
Moreover, the `tsc-alias` update requires explicitly defining the root
URL in the compiler options now, otherwise it errors with `tsc-alias
error: compilerOptions.rootDir is required with implicit baseUrl` (see
https://github.com/justkey007/tsc-alias/pull/259/changes).
encodeString has the same surrogate-pair guard that encodeToXmlString had
before #21526: `unicode > 0xd7ff && (unicode < 0xe000 || unicode > 0xfffd)`.
That predicate is also true for U+FFFE and U+FFFF, which are single UTF-16
code units, not surrogate pairs. The extra `i++` then steps over the
character that follows them, so it is silently dropped from the
font-encoded output used when saving or printing a PDF.
For example, encoding a string that is U+FFFF followed by "A", with a font
that has a glyph for both, returns an encoded result ending in "A" on this
branch but drops the "A" on master.
Same fix as #21526: the correct test for a real surrogate pair is
`unicode > 0xffff`, since codePointAt only returns a value at or above
0x10000 for an actual pair. This keeps existing behavior for real surrogate
pairs (e.g. emoji) and the U+FFFD boundary, and only stops the character
after U+FFFE/U+FFFF from being dropped.
Added test/unit/fonts_spec.js, since Font.prototype.encodeString had no
direct unit test. It calls the method on a minimal fake `this` (only
toUnicode/cMap are read), since building a full Font requires a complete
properties/font-file setup that this bug doesn't depend on.
