text: Bold text is sometimes way bolder than intended

[chrisbobbe]

See how bold the sender names and topic headers are in this screenshot on the office Android device, compared to a better alternative:

Current	Better alternative

The "better alternative" can be reached in this case by commenting out a line in weightVariableTextStyle:

diff --git lib/widgets/text.dart lib/widgets/text.dart
index 1a80cee4b..04d001bbd 100644
--- lib/widgets/text.dart
+++ lib/widgets/text.dart
@@ -69,7 +69,7 @@ TextStyle weightVariableTextStyle(BuildContext? context, {
     // This use of `fontWeight` shouldn't affect glyphs in the preferred,
     // "wght"-axis font. If it does, see for debugging:
     //   https://github.com/zulip/zulip-flutter/issues/65#issuecomment-1550666764
-    fontWeight: clampVariableFontWeight(value),
+    // fontWeight: clampVariableFontWeight(value),
 
     inherit: true);
 }

It seems that the comment about "This use of fontWeight shouldn't [etc.]" has proven helpful: the use of fontWeight is indeed affecting glyphs in Source Sans 3. The "see for debugging" link is relevant, but I plan to replace it with a link to an upstream Flutter issue with the triaged-engine label: that's flutter/flutter#136779 .

Removing that fontWeight line would be sad; it exists for the sake of glyphs that can't be rendered in the primary font family (like Source Sans 3) and might need to be rendered in a fallback font that doesn't have a "wght" axis.

[chrisbobbe]

We've seen this on Greg's Android device, and (as screenshotted above) on the office Android device. I don't think we've yet had reports from iOS.

[gnprice]

Thanks for spotting this. I'd actually noticed that the recipient headers and sender names seemed bolder than I'd expect; but our source code seemed to clearly call for the same weights that Vlad specified in the design, so I figured that was just his design choice. Apparently not!

I don't think we've yet had reports from iOS.

(And in particular it doesn't seem to reproduce on your iPhone.)

On that upstream issue flutter/flutter#136779, it looks like the next step is to work out what the desired behavior should be when both a fontWeight and a wght variation are specified. So probably the next step for this issue is for me to try to move that upstream issue forward, by writing a comment that tries to answer that question.

[chrisbobbe]

Sounds good. Thank you!!

[gnprice]

This came up in a chat thread: https://chat.zulip.org/#narrow/stream/48-mobile/topic/density.20in.20message.20list/near/1735059

[gnprice]

OK, I've posted a proposed solution on that upstream thread, starting at flutter/flutter#136779 (comment) . I'll follow up with whatever discussion that leads to.

[gnprice]

No reply yet on that thread. I've now filed my proposed upstream solution as its own issue:

• FontWeight should subsume wght in FontVariation flutter/flutter#148026

Partly that's prompted by seeing there was another report of the same underlying problem. (In that report, the issue was that Flutter's own Material implementation doesn't work right on variable fonts, because it sets fontWeight but not a wght variation.)

Perhaps the new writeup will make it easier to see what my actual proposal is, as opposed to the reasoning leading up to it, and perhaps it'll help spur someone to pick it up and implement it. We'll see.

[chrisbobbe]

Thank you for filing that!!

[gnprice]

I'm not reproducing this when I look now (on Android). Did we fix this along the way at some point?

[chrisbobbe]

I haven't made any code changes to fix this, no. Maybe something upstream?