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

Comece revisando o comportamento existente de carregamento de fontes em plotly-basic e plotly-cartesian, juntamente com o loader relacionado a FontFace já presente no bundle completo e no maplibre-gl. Decida quais formas de entrada devem ser suportadas primeiro e, em seguida, defina como as fontes são registradas antes da medição e incorporadas aos SVGs exportados. O trabalho estará concluído quando os bytes de fonte ou as URLs fornecidos afetarem a medição do layout e produzirem os dados de fonte SVG esperados sem travar quando o carregamento falhar.

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.