Merging pages with conflicting AcroForm /DR must inline the resources
each field's appearance relies on, since only one /DR survives in the
output. That fixup:
- resolved the appearance /Resources ref against the source document's
xref instead of the merged one, so the lookup failed and merging threw
(null.has(...));
- skipped checkbox/radio widgets, whose /AP /N is a sub-dictionary of
appearance states rather than a single stream;
- threw on a non-dictionary /Resources (e.g. a stray name) instead of
falling back to the default resources.
The PDF document in question is corrupt, and note that even Adobe Reader (i.e. the PDF reference implementation) cannot render it correctly.
Also, guard all other set fill/stroke color operators similarly.
Name-tree keys are PDF text strings, so encode named destinations with
stringToAsciiOrUTF16BE when writing the /Dests tree; otherwise a non-ASCII
name (e.g. "名") is truncated to a single byte and lost on round-trip. Sort
the name/number tree by byte value rather than localeCompare, matching the
order used when the tree is read back.
Apply the same encoding to deduplicated /EmbeddedFiles names: those are
rebuilt from a decoded display string, so a non-ASCII attachment name would
otherwise be corrupted when its duplicate is written.
When saving or downloading a document, an annotation that was still
being edited (e.g. an in-progress ink drawing) wasn't committed first,
so its content was missing from the saved file.
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.
