Here's a tricky one: I've got a request to style text which appears in a running footer with outlined text. This text must contain, among other things, a CSS counter indicating the current page number, and a CSS string indicating the name of the current chapter.

As far as I can tell, these requirements are mutually exclusive in Prince as it stands.

I can get the CSS counters and strings into the running footer by using the "content" properly on an HTML element. However, Prince doesn't support the text-stroke CSS property, and none of the usual browser workarounds (e.g., multiple offset text-shadows) work in Prince because they rely on pixel-perfect positioning which cannot be achieved in a PDF.

Conversely, I can get outlined text into the running footer using an inline SVG containing a <text> element with a stroke colour, but no fill colour. However, the SVG <text> element does not support the "content" CSS property, so there's no obvious way to get CSS counters or strings into an inline SVG.

Is there possibly some workaround I'm overlooking?

I did try overlaying multiple elements containing the desired text on top of each other with the lower element having a heavier font-weight than the upper element, which sort of works. However, Prince doesn't appear to respect the specified weight when creating artificial bolds (i.e., it always artificially boldens the base font by the same amount), so unless you're using a variable font with a weight axis this method offers no control over the thickness of the resulting "outline".

Edited 27 Dec 2025 by David J Prokopetz

I wonder if you could find a font that is already outlined perhaps?

Unfortunately no; if we had the freedom to use any font we want, we would have switched to a variable font with a weight axis to use the workaround described in my previous post (and in any case, an outline font would share the issue of being unable to control the line weight).

Edited 29 Dec 2025 by David J Prokopetz

Okay, so barring support for the text-stroke property perhaps a solution might be some ghastly post-typesetting JavaScript that generates a custom SVG footer on a per-page basis? Can't say I'm thrilled with that idea but it should at least be possible.

I thought about that, but there's the immediate issue that margin boxes are not exposed by the box-tracking API, so there's no obvious mechanism for a post-layout Javascript to interrogate them to find out what their content should be.

Edited 29 Dec 2025 by David J Prokopetz

I was thinking as long as you can determine which page should have which number and chapter title, you could generate one @page:nth() { ... } rule per page and one SVG per page.