mdpdf drives a headless Chromium, and a browser installed as a flatpak --
which is what the Pop!_Shop installs, and so the ordinary case on a Pop!_OS
or System76 machine -- was unusable in two ways, the second of them silent.
It was not found at all. A flatpak puts nothing on PATH and nothing in
/opt, and its wrapper is named com.brave.Browser rather than brave-browser,
so adding the export directory to PATH would not have helped either. The
application ids are now looked for in the flatpak export directories, after
every native browser, so a native one still wins where there is one.
Found, it then rendered in the wrong fonts and reported success. The
@font-face URLs pointed into the font store, which the sandbox cannot read,
and a browser does not report a font it cannot fetch -- it substitutes. The
PDF came out in a default serif and nothing said so. Granting the path
would not have travelled either: sandbox filesystem permissions differ from
one application to the next, so a scheme resting on a path works with one
browser and fails with another on the same machine.
So the document, its fonts and its images are now served to the browser
over the loopback interface instead of being passed as file:// paths. Every
sandbox shares the network namespace -- the DevTools connection already
depends on it -- so this needs no filesystem permission from any sandbox,
present or future. A --keep-html copy is still written with file:// URLs,
so it works when nothing is serving it.
A font that fails to load is now an error rather than a substitution: the
page is asked whether each requested family arrived, and no PDF is written
if one did not. A finished-looking document in the wrong typeface is the
worst failure this program can have.
Separately, a table-of-contents entry no longer carries a bullet. An entry
is a section title, and a marker in front of it reads as a list of things
rather than as a contents; ordinary bulleted lists are unaffected.
(from dev 12929fdff53b)
Andy Kopra
61987c8b1f