react-native: Width measures of Text components using a custom font are wrong

I discovered a “trick” to avoid this kind of issue: don’t rely on fontWeight on Android alone! Instead use fontFamily. Android Roboto have only 6 variants, same for OnePlus Slate. I have spend a few hours trying to find an acceptable combo on stock Android (using a Pixel 3), ColorsOS (Oppo) and OxygenOS (OnePlus)

You can safely (on Android) use the following name instead of weight

• sans-serif-thin (= 100/200 depending on android custom font)
• sans-serif-light (=300)
• sans-serif / sans-serif-regular (400) (note that OnePlus Slate doesn’t handle sans-serif like sans-serif-regular, when used with a weight)
• sans-serif-medium (500)
• sans-serif-bold (600/700)
• sans-serif-black (800/900)

Note that fontWeight coupled with a fontFamily give better result on Android, if you want to rely on OS font.

Here is a stylesheet you can use safely to think about “weight” and forget about the trick

  // iOS: no comment, weight are perfect
  // Android: only has 100/300/400/500/700/900
  // it's a total mess depanding on brands...
  // more details here https://github.com/MoOx/LifeTime/blob/5ce54e13096642da02e46bf54b48548f7b5b1890/src/components/shareable/Theme.res#L120-L168
  // ios | st. and. | oppo | 1+
  // 100 | 100 | 100 | 200
  // 200 | 300 | 300 | 300
  // 300 | 300 | 300 | 300
  // 400 | 400 | 400 | 400
  // 500 | 500 | 500 | 500
  // 600 | 500 | 500 | 500
  // 700 | 700 | 700 | 700
  // 800 | 700 | 700 | 900
  // 900 | 800 | 800 | 900
const weightStyles = StyleSheet.create({
  "weight100": Platform.OS === "android"
    ? {fontFamily: "sans-serif-thin", fontWeight: "100"}
    : {fontWeight: "100"},
  "weight200": Platform.OS === "android"
    ? {fontFamily: "sans-serif-light", fontWeight: "200"}
    : {fontWeight: "200"},
  "weight300": Platform.OS === "android"
    ? {fontFamily: "sans-serif-light", fontWeight: "300"}
    : {fontWeight: "300"},
  "weight400": Platform.OS === "android"
    ? {fontFamily: "sans-serif", fontWeight: "400"}
    : {fontWeight: "400"},
  "weight500": Platform.OS === "android"
    ? {fontFamily: "sans-serif-medium", fontWeight: "500"}
    : {fontWeight: "500"},
  "weight600": Platform.OS === "android"
    ? {fontFamily: "sans-serif-medium", fontWeight: "600"}
    : {fontWeight: "600"},
  // reminder: oneplus handle sans-serif-regular / 700 != sans-serif / 700 !!
  "weight700": Platform.OS === "android"
    ? {fontFamily: "sans-serif-regular", fontWeight: "700"}
    : {fontWeight: "700"},
  "weight800": Platform.OS === "android"
    ? {fontFamily: "sans-serif-bold", fontWeight: "700"}
    : {fontWeight: "800"},
  "weight900": Platform.OS === "android"
    ? {fontFamily: "sans-serif-black", fontWeight: "900"}
    : {fontWeight: "900"},
})

Just to tag issues so people would find the workaround: #15114 #25258 #29259 #18258 #17629 #21729

Related, but I’ve noticed that because the wrapping calculation is wrong on custom fonts, sometimes you will get an extra line where the text renderer thinks the text will wrap but doesn’t. There is no way to get rid of it.

Example:

No reason to think this isn’t still an issue.

If someone can label this as “Backlog”, that seems like it’d be appropriate.

Not fixed AFAIK

Thanks @charpeni for the detailed report and debugging!

This issue has been around for a couple of years, as #15114. Some information that gradually accumulated there:

• The issue goes back to RN v0.34.
• It’s not only users who change the default font who are affected – on some models, the default font that comes with the device triggers this issue. This includes a number of Oppo and OnePlus models.
• One workaround that seems 100% effective is to avoid setting fontWeight or using bold. This seems like a clue.
• Some fascinating debugging in this comment finds that:

  • the font weight (and maybe other things) isn’t taken into account to determine correct size for the text box.

  • In particular the box gets laid out with what looks to be exactly the right width for the non-bold, default-weight, version of the font. Then the actual text gets placed into it… and it’s wider than that, so it doesn’t fit.
  • In particular it gets line-wrapped based on the font’s actual dimensions (but inside the box sized for its non-bold dimensions), so typically the last word of the line gets moved to the next line… which if it was a single-line box, means it just doesn’t appear.

To influence the layout measures of the text component, we can set a border of at least 2 on it. By doing this, the layout will be properly measured

This is an interesting workaround! It would be especially interesting to know whether this workaround keeps working even when the text is long and the border is still small.

That is, does it somehow cause the layout code to go down the right path to use the correct font metrics to make the box as wide as it needs to be? Or does it just add the border itself to the width, and then the text is able to eat into that when it turns out to be wider?

… Looking closely at your screenshots, actually, I have a new observation.

The last three green boxes – that is, each of the variations on a text box with bold text – have exactly the same width in the OnePlus Slate case as the Roboto case.

OTOH the first box, with unstyled text, has less width for OnePlus Slate than for Roboto. And in the OnePlus Slate case, it has less width than the (first) bold box.

So it looks as if in the bold case, the size isn’t getting based on the non-bold version of the same font… instead it seems to have the right dimensions for bold Roboto.

That would be interesting to confirm or disconfirm with more examples. If true, it may be a strong clue for whoever wants to go into the code to try to track down the actual cause.

For anyone running into this, I can reproduce this issue on any recent android emulator by enabling “Bold text” under Accessibility > Text and display, which seems like this is not just an issue for some brands, but an accessibility issue in general…

The theory of the box around the text being incorrectly calculated seems pretty accurate to me.

@MoOx Not working for #29259

this is duplicate of https://github.com/facebook/react-native/issues/15114 please reopen that issue

Hello,

Thanks for the issue. I have been contributing to facebook/react-native for 4 years and specialize in the Text/TextInput components. I currently have 58 facebook/react-native PRs:

https://github.com/facebook/react-native/pulls?q=is%3Apr+author%3Afabriziobertoglio1987+

This is the suggested approach from the react-native core team (see this discussion):

I’m publishing several fixes for Text and TextInput component in a separate library react-native-improved.

• The Component is based on ReactTextView, it is the same implementation from react-native.
• It will include several bug fixes.
• You can use the library until the PR is merged and released with react-native.
• You can use side by side both components from react-native and react-native-improved, depending on where you need the fix.
• I will also publish the PR to facebook/react-native (daily fixes and releases).

The advantages would be:

• Increased engagement with the community, issues are quickly fixed.
• No limitations when merging PRs (react-native main branch is used on facebook marketplace).
• Only Meta employees can merge and review facebook/react-native PRs.
• Allows us to further experiment and develop react-native.

What do you think about this? Should I keep working on this? Thanks

This issue has been reproduced and verified to be fixed in the pr #37271.

Hi @dumathane, it looks like this issue is clearly important to you. You could think about sponsoring / paying someone to fix it for you as nobody else is going to fix it apparently (this issue is already more than 2 years old).

New solution https://github.com/facebook/react-native/issues/15114#issuecomment-576313266 Just change textBreakStrategy to simple fix it