[Text][Android][iOS?][RC] text decorations ignoring font position metrics
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 45/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- kotlin, objective-c
- 領域
- mobile-dev
研究方向
從必要的 rn-reproducer-font-rendering 應用程式開始,將 Android 和 iOS 上的裝飾位置與預期的螢幕擷取畫面進行比較。閱讀提交 87184c8fbac1,並追蹤原生文字裝飾路徑,包括 issue 中描述的 Android 和 CoreText 度量處理。完成的標準是:已驗證兩個平台上的底線和刪除線位置使用適當的字型度量或有文件記錄的 fallback,且 reproducer 能正確進行渲染。
由索引模型根據 Issue 內容生成。
描述
Description
https://github.com/react/react-native/commit/87184c8fbac1 implemented textDecorationStyle feature parity between iOS and Android (before RC missing in Android as noop). cc @quantizor
The position and sizing of the lines (underlines, strike through), though, are not based on the open type tables of the used font, instead different heuristics are used (mid of x size fo strike through, baseline + 1 for underline)
This leads to a wrong final result, where underlines is always touching the baseline, and strike-through may be oddly positioned.
The problem is more visible in custom fonts that intentionally define larger offsets for the underline (e.g. to avoid crossing descenders), or use a curated position for strike through (e.g. avoiding overlapping with currency symbol mid lines). Those are just some examples, but in general the expectation is to respect the values embedded in the font.
On iOS there is a similar issue: while "solid" and "double" underlines respect values that CoreText reads from the font, the position of "wavy", "dashed", "dotted", instead is using the same hardcoded heuristic now introduced on Android.
(I couldn't directly verify the issues on iOS, but inferred from similar code. Would be worth also verifying how the strike through position is determined there)
I'm not familiar with the native code, but I think both the current state as well as the one in the RC have issues, with underlines on Android now always touching the glyphs just being the most visible one.
LLM suggested possible fixes involving reading the correct metric when they are available, while falling back to heuristics when not available.
drawSpannedDecoration(start, end, canvas, layout, color, style) {
paint,
baseline,
thickness,
->
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
baseline + paint.underlinePosition + thickness / 2f
} else {
baseline + thickness + 1f
}
}
CTFontRef ctFont = (__bridge CTFontRef)font;
CGFloat fontThickness = CTFontGetUnderlineThickness(ctFont);
CGFloat thickness = fontThickness > 0
? fontThickness
: MAX(font.pointSize / 12.0f, 1.5f);
CGFloat topOffset = -CTFontGetUnderlinePosition(ctFont);
CGFloat y = baseline + topOffset + thickness / 2.0f;
I haven't directly verified these suggestions and I also think a wider assessment may be needed:
- are there other metrics being ignored and replaced with custom heuristics?
- Is any of those changes compatible with the recent introduction of variable fonts support? (https://github.com/react-native-community/discussions-and-proposals/issues/829#issuecomment-5246274271) cc @Abbondanzo
- when heuristics are used as fallback, are they in sync with web browsers implementation?
- should font metrics be respected by default, or via a style property like on web (e.g.
text-underline-position: from-font) - probably more things I'm missing needing some text rendering experts' eyes
Steps to reproduce
run the reproducer and check the actual and expected rendering (as in screenshot)
can also be compared with older RN version where underline was correctly rendered with a large offset: https://snack.expo.dev/@axyzxp/underline-rendering?platform=android
React Native Version
0.87.0-rc.4
Affected Platforms
Runtime - Android, Runtime - iOS
Output of npx @react-native-community/cli info
❯ npx @react-native-community/cli info
info Fetching system and libraries information...
System:
OS: Linux 7.0 Ubuntu 26.04 LTS 26.04 LTS (Resolute Raccoon)
CPU: (16) x64 AMD Ryzen 7 PRO 4750U with Radeon Graphics
Memory: 13.25 GB / 30.57 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 26.7.0
path: /home/axyz/.local/share/mise/installs/node/latest/bin/node
Yarn: Not Found
npm:
version: 11.19.0
path: /home/axyz/.local/share/mise/installs/node/latest/bin/npm
Watchman: Not Found
SDKs:
Android SDK: Not Found
IDEs:
Android Studio: Not Found
Languages:
Java:
version: 21.0.7
path: /home/axyz/app/android-studio/jbr/bin/javac
Ruby:
version: 3.3.8
path: /usr/bin/ruby
npmPackages:
"@react-native-community/cli":
installed: 20.2.0
wanted: 20.2.0
react:
installed: 19.2.3
wanted: 19.2.3
react-native:
installed: 0.87.0-rc.4
wanted: 0.87.0-rc.4
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: Not found
newArchEnabled: false
Stacktrace or Logs
there is no crash, it is a visual defect.
MANDATORY Reproducer
https://github.com/axyz/rn-reproducer-font-rendering
Screenshots and Videos
- 主要語言
- C++
- 星號
- 127k
- 分支
- 25.3k
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
react/react-native 的其他 Issue
-
Needs: Author Feedback Needs: Repro
難度 2/5 1-3 小時 新手友好度 76/100
react/react-native#58952 · 1 則留言 ·
維護者通常 1 天內回覆
-
Needs: Attention Needs: Repro
難度 2/5 1-3 小時 新手友好度 78/100
react/react-native#58904 · 2 則留言 ·
維護者通常 1 天內回覆
-
Needs: Author Feedback Needs: Repro
難度 2/5 1-3 小時 新手友好度 75/100
react/react-native#58659 · 2 則留言 ·
維護者通常 1 天內回覆
-
Needs: Author Feedback Needs: Repro
難度 1/5 1 小時以內 新手友好度 92/100
react/react-native#58621 · 1 則留言 ·
維護者通常 1 天內回覆
-
Add TypeScript declaration for the performance global可能已有人在做 @Cedric921 於 7 天前認領。 未關閉Needs: Attention Needs: Repro
難度 2/5 1-3 小時 新手友好度 85/100
react/react-native#58610 · 4 則留言 ·
維護者通常 1 天內回覆
查看 react/react-native 的全部 Issue
相似的 Issue
-
Incorrect Link in README.md可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 1/5 1 小時以內 新手友好度 95/100
flameshot-org/flameshot#4996 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 64/100
utopia-rise/godot-jvm#1004 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 70/100
維護者通常 3 天內回覆
-
難度 2/5 1-3 小時 新手友好度 70/100
維護者通常 1 天內回覆
-
chore(build): TxCoordinator.cpp uses the deprecated shared_ptr atomic free functions可能已有人在做 @w5jwp 今天認領。 未關閉
難度 1/5 1 小時以內 新手友好度 84/100
aethersdr/AetherSDR#6368 · 1 則留言 ·
維護者通常 1 天內回覆