Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
  • 哪裡不對？
#8,056 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
45/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
javascript
領域
data-visualization

研究方向

先檢視 plotly-basic 和 plotly-cartesian 中現有的字型載入行為，以及 full bundle 和 maplibre-gl 中已存在的 FontFace 相關 loader。決定優先支援哪些輸入形式，接著定義如何在測量前註冊字型，以及如何將字型嵌入匯出的 SVG。完成的標準是：提供的字型位元組或 URL 會影響版面配置測量，並產生預期的 SVG 字型資料；載入失敗時不會卡住。

由索引模型根據 Issue 內容生成。

描述

enhancement feature P2 size: 5
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.

主要語言
JavaScript
星號
18.3k
分支
2k
平均合併
1 天 14 小時
30 天內合併 PR
21

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

plotly/plotly.js 的其他 Issue

查看 plotly/plotly.js 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。