Compared to regular Objects there's a number of advantages to using Maps:
- They support proper iteration.
- They have a simple way to check for the existence of data.
- They have a simple/efficient way to check the number of elements.
If this functionality was added today, I cannot imagine that we'd choose an Object for this data.
We support having hours/minutes numbers with one or two digits for strings like "1:30:31" but
if the format is for example Hm, then "12" is really ambiguous.
So the idea is to match the longest string as possible.
The Type-4 PostScript -> Wasm compiler emitted i32.const immediates with the
unsigned LEB128 encoder (_emitULEB128). Wasm decodes i32.const as a *signed*
LEB128, so any immediate whose final 7-bit group has bit 0x40 set is
mis-decoded (e.g. 64 -> single byte 0x40 -> read back as -64).
The output-store address for the i-th result is emitted as i32.const (i*8).
For a function with >= 9 outputs the 9th offset is 64, which decodes as -64, so
f64.store targets 0xFFFFFFC0 and traps (memory access out of bounds). The module
still validates and instantiates, so the JS fallback in function.js is not
engaged; the trap only surfaces at render time (the affected shading / tint
transform silently fails to render). The same mis-encoding affects the constant
bitshift amount.
Add a signed-LEB128 emitter (_emitSLEB128) and use it for the three i32.const
immediate sites; local/import/type indices remain unsigned (correct). Add a unit
test covering functions with 9+ outputs, and a reference test rendering a shading
whose colour function has 9 outputs.
Some Annotations, e.g. `SignatureWidgetAnnotation`, set `fieldValue = null` which may causing saving to fail during `writeXFADataForAcroform`, hence we simply ignore any such Annotation-data during saving.
PR #21455 drew non-isolated blend-mode groups against their backdrop via a
direct path on the parent canvas, but a soft mask forces the group onto an
intermediate canvas instead. There the inner blend modes composited against
transparency, so e.g. a /Multiply highlight was painted opaquely over the
text behind it, hiding it.
Copy the backdrop into that intermediate canvas so the blends see the real
background. The copy is limited to groups that would otherwise have taken
the direct path (source-over, alpha 1, not knockout/gray) but were displaced
onto the intermediate canvas by the soft mask.
It fixes#21593.
Several extensions (`.coffee`, `.jade`, `.inc` and others) became
obsolete in e.g. the conversion to Wintersmith/Fluent/other tools, while
other new extensions (`.mjs`, `.njk`, `.py` and others) were missing.
This commit removes all obsolete file format entries, adds all missing
ones and orders the list alphatically (so it can more easily be matched
against tooling that lists all in-use file extensions in the repository).
This avoids duplicating the charCode/glyphId lookup, and (slightly) shortens the code. In particular:
- Given that the path-data is returned as a TypedArray, it's easy enough to instead return `null` to indicate that the glyph was previously compiled.
- The charCode-cache can be changed into a Set, since we only need to track the "seen" charCodes and not their relation to the glyphIds.
- The `compileFontPathInfo` call is moved into `CompiledFont` class, since that simplifies the `src/core/evaluator.js` code a tiny bit.
Move the `fs.existsSync(indexPath)` check below the `--no-download`
early return: in that mode the check is unused (the read after
refreshIndex already validates existence), so it's wasted disk I/O.
Address two CodeQL findings on the per-test index downloader:
- "File data in outbound network request": validate the cached ETag
against the RFC 7232 grammar before sending it as If-None-Match, so
the cache file's contents can't be injected into the request header.
- "Network data written to file": cache the re-serialized JSON
(JSON.stringify(JSON.parse(...))) instead of the raw response body,
so only well-formed JSON produced by our own serializer is written.
`coverage_search` now fetches `per-test-index.json` from the pdf.js.refs
gh-pages branch, caches it locally, and only re-downloads it (via ETag)
when it changed, so querying which ref tests cover a line/function no
longer needs a local `--coverage-per-test` build. `--no-download` reuses
the cached index offline and `--index` points at a local one.
`browsertest` and `makeref` accept the same `--code` filter to run (or
regenerate refs for) only the covering tests, dropping any covered IDs
that aren't in this branch's manifest so the run isn't rejected.
Compared to regular Objects there's a number of advantages to using Maps:
- They support proper iteration.
- They have a simple way to check for the existence of data.
- They have a simple/efficient way to check the number of elements.
If this functionality was added today, I cannot imagine that we'd choose an Object for this data.
- Initialize the `bCache` lazily, since many/most PDF documents don't need it.
- Change the `bCache` to a `Map`, rather than an Object, which thanks to `getOrInsertComputed` allows the `buildB` function to be inlined.
Also, while unrelated here, move the `this.matrix = null;` definition to the `BaseShadingPattern` class to reduce (a tiny bit of) unnecessary duplication.
