CI: catch tofu and wrong-glyph regressions — check that emitted fonts survive OTS and that the pdf output paints the right glyphs
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 35/100
研究方向
Start with the test job in .github/workflows/build_test.yml, alongside the existing html-tidy and compare-html steps, and inspect test/scripts/ for how checks are run locally. The proposal calls for OTS validation of emitted font blobs and an allow-listed PDF text comparison; first decide which checks and oracle approach to implement. Done means deterministic CI checks fail on the described regressions and can also be run locally.
由索引模型根據 Issue 內容生成。
描述
Embedded-font regressions in the pdf output have shipped repeatedly and were
always found by eye, never by CI:
- #613 — TrueType subsets without a
nametable: OTS rejects the font, the
@font-faceis dropped, every PUA glyph renders as tofu. - #660 — three at once: a
CFFName INDEX holding a space makes OTS discard
the table; passing OpenType Layout / device-metric tables through verbatim
makes one malformed table reject the whole font; and a leaked PUA cmap made
the second output of a document paint whole runs with the wrong glyphs. - #702 — subset producers name glyphs
gidNNNNN, which no glyph list
translates, so those runs fell through to code-as-GID and painted unrelated
glyphs. - #749, #752, #753 — the same family of "the text is there, it just isn't the
right shapes / isn't where it should be".
Two distinct failure modes, both invisible to the current pipeline:
- The browser refuses the font.
font_is_usable
(src/odr/internal/html/pdf_file.cpp:2773) only probes that our own encode
path does not throw. Whether OTS — the sanitizer in every browser, far
stricter than FreeType or fontTools — accepts the bytes we then emit is
never checked anywhere. - The font loads but paints the wrong glyphs. Nothing compares the shapes
actually painted against what the page says the text is.
build-test does render the corpus, but the comparison is against
test/data/reference-output, which is regenerated wholesale from our own
output — a bug that is already in the reference is invisible, and #660 in fact
sat there. The pdf views also screenshot nondeterministically (a control run
flaps ~1/60 files), so a genuine small regression is easy to wave off as noise.
Proposal
Two cheap, deterministic checks. Neither needs the reference output, so neither
can be papered over by regenerating it.
1. Every emitted font must survive OTS
After odr_test writes build/test/output/**, extract every
data:font/...;base64 blob from the generated html and run ots-sanitize over
it (pip install opentype-sanitizer ships the binary; it is what I reach for
by hand every time one of these lands). Any ERROR fails the job, and the
message names the exact rejection reason.
This is seconds of runtime, no browser, no flakiness, and it catches #613 and
two thirds of #660 directly.
Worth considering as the stronger version: pull ots in as a test-only conan
dependency and assert it inside odr_test, over the corpus in
test/src/internal/font/. That turns it into a unit-level guard on
SfntFont::write / cff::wrap_to_otf rather than a post-pass over html, and
it fails on the developer's machine before the push.
2. The glyphs painted must be the glyphs meant
For the pdf corpus, take the text an oracle extracts from the source pdf
(gs -sDEVICE=txtwrite, or pdftotext) and compare it against the text of the
generated html, normalised for whitespace. That is the check that would have
caught the PUA-cmap leak in #660 and the gidNNNNN fallthrough in #702: the
page still renders, the layout is unchanged, only the shapes are wrong — and
because we re-encode to the PUA, the html's text is the thing that stays
correct while the glyphs drift, so a text-level oracle sees the divergence the
screenshot comparison shrugs at.
Start with a small allow-listed set of pdf files with a stable expected text,
rather than the whole corpus, so the check is meaningful before it is complete.
A cheaper complement, if the browser is already up: assert in-page that
document.fonts reports every declared face loaded and that no run measures
at the fallback's advance — that catches "the font was dropped" from the other
side, without an oracle.
Where it goes
test job in .github/workflows/build_test.yml, next to the existing
html-tidy / compare-html steps, and mirrored in a script under
test/scripts/ so it is runnable locally the same way.
- 主要語言
- C++
- 星號
- 41
- 分支
- 10
- 平均合併
- 12 小時 4 分鐘
- 30 天內合併 PR
- 297
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南,環境需要你自己搭建:先看它的 README,通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
opendocument-app/OpenDocument.core 的其他 Issue
-
bug
難度 4/5 3-5 天 新手友好度 35/100
opendocument-app/OpenDocument.core#1211 ·
維護者通常 1 天內回覆
-
bug
難度 3/5 1-2 天 新手友好度 42/100
opendocument-app/OpenDocument.core#1210 ·
維護者通常 1 天內回覆
-
bug
難度 3/5 1-2 天 新手友好度 45/100
opendocument-app/OpenDocument.core#1209 ·
維護者通常 1 天內回覆
-
bug
難度 4/5 3-5 天 新手友好度 38/100
opendocument-app/OpenDocument.core#1208 ·
維護者通常 1 天內回覆
-
bug
難度 3/5 1-2 天 新手友好度 35/100
opendocument-app/OpenDocument.core#1207 ·
維護者通常 1 天內回覆
查看 opendocument-app/OpenDocument.core 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 85/100
OpenSpace/OpenSpace#4353 · 1 則留言 ·
維護者通常 5 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
-
macOS: a double-click on a notarized altairsim is refused, and the docs give only the offline case可能已有人在做 @anhaoXie 今天認領。 未關閉documentation
難度 2/5 1-3 小時 新手友好度 88/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 68/100
mutationpp/Mutationpp#337 ·
-
難度 2/5 1-3 小時 新手友好度 76/100
bulletphysics/bullet3#4819 ·