Base R png() hangs when pango is loaded from a package

[jeroen]

I thought that we used this before but I see the same problem with older versions of webR:

install.packages("magick")
library(magick)
png('test.png')
plot(rnorm(100), main = 'bla')
dev.off()

The R console shows a warning

(process:42): Pango-WARNING **: 13:17:04.095: shaping failure, expect ugly output. shape-engine='PangoFcShapeEngine', font='Noto Sans 9', text='m'

And browser dev console shows a "remainer by zero" error:

---

For some reason it does not happen when using alternative png devices:

install.packages("magick")
install.packages("ragg")
library(magick)
library(ragg)
ragg::agg_png('test.png')
plot(rnorm(100), main = 'bla')
dev.off()

[jeroen]

What claude says: (TLDR: let's start by updating the pango stack)

Root cause: duplicate copies of the GNOME text stack across side modules

webR's architecture makes this almost inevitable. R itself is built as an Emscripten MAIN_MODULE=1, but two relevant pieces are separate dlopen'd SIDE_MODULEs:

• cairo.so — base R's png(type="cairo") device. Because R is configured --with-static-cairo=yes, this module statically embeds its own copies of cairo, pixman, pango 1.40.14, harfbuzz, glib, fribidi and fontconfig.
• magick.so — the magick package, linked against the static libMagick++ recipe, which in turn statically embeds pango, fontconfig, freetype, harfbuzz and glib (the imagemagick recipe is configured --with-pango --with-fontconfig).

So pango/glib/harfbuzz/fontconfig exist as two independent static copies, one inside each side module. (FreeType is the one exception — everything routes through Emscripten's --use-port=freetype, so there's a single copy; that was the fix for #504/#531.)

When two side modules export the same symbol, Emscripten's dynamic linker doesn't keep them separate — it merges them into one global table on a first-definition-wins basis. In your reproducer library(magick) runs before png(), so magick.so loads first and wins most of the pango/glib symbols. Then cairo.so loads and binds to magick's copies for everything magick happened to pull in, but falls back to its own copies for any pango/glib symbol magick didn't reference. The result is a split-brain: pango's GObject type registry and its shape-engine module map end up partially initialized in one module and read from the other. The legacy modular shaper (PangoFcShapeEngine) gets selected against a font/face whose harfbuzz state lives in the other copy, so it returns zero glyphs even for trivial text — hence "shaping failure … text='m'" on a font that obviously contains an m.

This explains every symptom: it works with cairo alone (self-consistent), breaks once magick is loaded first (split symbols), and ragg is immune because ragg's text stack (systemfonts + textshaping, with its own bundled freetype/harfbuzz) is fully self-contained and shares none of these symbol names.

One aggravating factor worth flagging: pango is pinned at 1.40.14 (2017), which still uses the old modular shape-engine subsystem with lots of static GType/module-map state — exactly the machinery that fragments under symbol merging. Pango ≥ 1.44 deleted shape engines entirely and shapes inline via harfbuzz, which has far less static global state to split.

How to confirm

Load order is the tell. Try forcing cairo.so to load before magick:

png(tempfile()); dev.off()      # forces cairo.so to load and win the symbols first
library(magick)
png('test.png'); plot(rnorm(100), main='bla'); dev.off()

If that renders cleanly while the original order fails, it confirms the duplicate-symbol/load-order diagnosis. You can also check whether both cairo.so and magick.so define e.g. pango_shape, g_type_register_static, FcConfigGetCurrent (emnm/wasm-objdump -x on each .so); they will.

Fixes, roughly in order of effort vs. thoroughness

The cleanest fix is to guarantee a single canonical copy of the shared text stack rather than one per side module:

1. Pull glib/fontconfig/fribidi/pixman/cairo/pango/harfbuzz into the MAIN_MODULE (e.g. force-link the archives into libR with --whole-archive, the way freetype is already centralized via the port). Since MAIN_MODULE=1 already exports everything it links, both cairo.so and magick.so would then resolve all of these to one authoritative copy with one set of global state. This is the most targeted fix and matches the precedent set by the FreeType centralization. Cost: a larger base R.wasm even when plotting isn't used.

2. Build the text stack as proper shared wasm side modules (--enable-shared) loaded once, instead of --enable-static=yes embedded into each consumer. This is the "correct" long-term design but a meaningful build-system change.

3. Upgrade pango past 1.44 (ideally ≥1.50). This removes the PangoFcShapeEngine path that's actually failing and shrinks the fragile static-state surface — but it requires meson and a newer glib (2.56.4 → ≥2.66), so it's a bigger lift and best paired with (1).

A combination of (1) now and (3) later is probably what lands.

Workaround for the reporter

The simplest user-facing answer is what jeroen already found: use ragg::agg_png() (or svg()), which sidestep the pango device entirely. The load-order trick above may also work as a stopgap if forcing the cairo device to initialize first proves reliable.

If it's useful, I can draft a concise comment for the issue summarizing the diagnosis, or sketch the actual Makefile change for option (1) so you can test it.