[FEATURE]: accept font data (a URL or the bytes) for export and text measurement

Description

We want charts to render with a font that isn't installed on the machine doing the rendering - Kaleido in a container, in our case. This all started in https://github.com/plotly/Kaleido/issues/464 but @camdecoster has pointed me here and I found a similar issue - #4885, but we then concluded it would make sense to create a narrower one, so here it is.

The request is a way to hand plotly.js a font, as either a URL or the raw bytes, and have it do two things with whichever it gets: register the face
before it measures text, and inline @font-face with base64 into the exported SVG.

Why should this feature be added?

Well, people are still hitting #4885 that has been open since 2020. I just tried with plotly.py 7.1.0 (plotly.js 4.1.1) and a font that isn't installed on my machine:

fig.update_layout(font=dict(family="Fira Sans Condensed"))
fig.write_image("out.svg")

and the resulting SVG names that family 7 times but carries no @font-face and no base64anywhere. The name travels, but the bytes don't.

It's two bugs though, not one. The other is WilliamMayor's 2023 comment in the same thread - the font also isn't loaded when plotly.js measures text, so ticks, margins and legends get sized on some kind of "fallback" and the layout is wrong before anything is exported. Taking the font as input could fix both, I believe, because both come from it not being in the page.

I saw @alexcjohnson proposing a cheaper alternative in #4885 - to read the @font-face rules already active in the document instead of having users declare fonts. I tested that: with a plain <link> to fonts.googleapis.com, cssRules throws SecurityError, and it's only readable when the link carries crossorigin="anonymous" (at least in the one browser and the one Google family we've checked).

Mocks/Designs

Rough, and I'm not attached to the naming:

Plotly.newPlot(gd, data, layout, {
  fonts: [
    // a google fonts css url - the same string that's already in the <link>
    {family: 'Open Sans', url: 'https://fonts.googleapis.com/css2?family=Open+Sans'},

    // a direct font file, nothing to parse
    {family: 'Open Sans', weight: 700, url: '/static/OpenSans-Bold.woff2'},

    // or the bytes, for offline and headless
    {family: 'Open Sans', weight: 700, data: arrayBufferOrBase64}
  ]
})

The first form is the convenient one and it's the only one that needs extra work: a Google Fonts URL returns CSS rather than a font, so something has to read the src out of that CSS and fetch the file it points at. The other two skip that step - the second is already a font file, the third is already bytes. So the CSS reading could come later, or never, and the feature still works.

Notes

My motivation is Kaleido, which has no user CSS and no network, so it would pass bytes. The same option would cover a browser user passing the Google Fonts URL they already have in their <link>.

In case it comes up: I've grep'ed the latest plotly.js bundle and maplibre-gl does this already, and it's in the tree, but I don't think chart text can borrow it. Its loader is wired into maplibre's own style system, and plotly-basic and plotly-cartesian contain 0 FontFace - only the full bundle has it - so depending on it would put a map renderer in every build.

One case I'd leave out on purpose: pulling the bytes of a font that's only installed on the system. No browser API exposes them, so those users would have to supply the file.

One question we would need to agree on: how much of the URL side is needed? The bytes form needs no network at all, so it could land on its own. A direct .woff2 URL adds a fetch, which would need a timeout and a warn-and-continue fallback so it can never hang a render. A Google Fonts CSS URL (which would add reading the src out of that CSS) looks a bit more complicated - from what I saw, google splits one family across several @font-face blocks, one per script, each pointing at a different file, so taking just the first gets you Latin and drops Cyrillic or Greek without saying anything.

Commencez par examiner le comportement existant de chargement des polices dans plotly-basic et plotly-cartesian, ainsi que le loader lié à FontFace déjà présent dans le bundle complet et dans maplibre-gl. Décidez quelles formes d’entrée prendre en charge en premier, puis définissez comment les polices sont enregistrées avant la mesure et intégrées aux SVG exportés. La tâche est terminée lorsque les octets de police ou les URL fournis influencent la mesure de la mise en page et produisent les données de police SVG attendues, sans rester bloquée lorsque le chargement échoue.