react / react/react-native

[Text][Android][iOS?][RC] text decorations ignoring font position metrics

オープン
#57,900 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

Bug Component: Text Impact: Bug Needs: Triage :mag: Platform: Android Platform: iOS
主要言語
C++
スター
127k
フォーク
25.3k
平均マージ
1日 23時間
マージ済み PR(30日)
4

説明

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
Image

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

必須の rn-reproducer-font-rendering アプリから始め、Android と iOS の装飾の配置を期待されるスクリーンショットと比較します。コミット 87184c8fbac1 を読み、issue に記載されている Android と CoreText のメトリクス処理を含め、ネイティブのテキスト装飾パスを追跡します。完了とは、両プラットフォームで下線と取り消し線の配置が適切なフォントメトリクスまたは文書化されたフォールバックを使用していること、および reproducer が正しくレンダリングされることを検証済みであることを意味します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
kotlin, objective-c
領域
mobile-dev
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
45/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。