SingleFile CLI 2.14.0

New features

--filename-replaced-character accepts a JSON array, for example '[" ", "_"]' to replace spaces with underscores. It is the way to ask for a replacement the space-separated form cannot express, a space as the replaced character being the one that was wanted

Resources fetched outside the browser now carry a Referer. That lane runs when the browser could not get a resource itself, and it sent no referrer at all, so a host that varies its answer on one — a font service answering 404, an image host serving a placeholder — gave the saved page something the reader never saw. The value follows the referrer policy the document declares, the way the browser computes it
Runs of control characters in a filename collapse into a single replacement character, as they already did in the extensions and in single-file-core
--filename-replaced-character keeps the order it is given. An entry written without a replacement used to be moved to the end of the table
--help prints default values in the form the option reads back. The list of replaced characters was printed as a JSON array, so its control-character entry appeared with the backslashes doubled, and passing that back selected digits and uppercase letters instead of control characters
--load-deferred-content-dispatch-scroll-event also defaults to on when the CLI is used as a library, as it has on the command line since 2.13.0. The two now share one set of defaults and can no longer disagree

--filename-replaced-character no longer drops a replacement containing a space. The value was split on every space and only the first two parts were kept, so "> _G T_" replaced > with _G
--filename-replaced-character no longer accepts a value with nothing before the space. It matched no character at all, so the option did nothing without saying so; it is now reported as an invalid value
An entry given without a replacement no longer shifts the entries after it, which gave the following character someone else's replacement
--max-appended-data-length shows the real default in --help instead of a copy of it

Fonts declared with font-style: oblique and an angle are no longer removed as unused when the page uses them as italic. The face was kept only when the style text matched exactly, so oblique 14deg never matched the italic the page asked for and the text lost its font. Font styles are now compared as angle ranges, the way the CSS specification defines the match
A filename replacement left empty in the middle of the table no longer writes undefined into the name

Co-authored by Claude (Claude Code)