Skip to content

content: **bold text** should be formatted with weightVariableTextStyle #499

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chrisbobbe opened this issue Feb 1, 2024 · 1 comment · Fixed by #501
Closed

content: **bold text** should be formatted with weightVariableTextStyle #499

chrisbobbe opened this issue Feb 1, 2024 · 1 comment · Fixed by #501
Assignees
Labels
a-content Parsing and rendering Zulip HTML content, notably message contents

Comments

@chrisbobbe
Copy link
Collaborator

Like other text that we want to present in Source Sans 3 (a variable-weight font), we should style **bold text** in content with weightVariableTextStyle. Currently, it is styled with just fontWeight:

  InlineSpan _buildStrong(StrongNode node) => _buildNodes(node.nodes,
    style: const TextStyle(fontWeight: FontWeight.w600));
@chrisbobbe chrisbobbe added the a-content Parsing and rendering Zulip HTML content, notably message contents label Feb 1, 2024
@chrisbobbe chrisbobbe self-assigned this Feb 1, 2024
chrisbobbe added a commit to chrisbobbe/zulip-flutter that referenced this issue Feb 1, 2024
chrisbobbe added a commit to chrisbobbe/zulip-flutter that referenced this issue Feb 2, 2024
@gnprice
Copy link
Member

gnprice commented Feb 2, 2024

Writing down a discussion we had in the office: it looks like the symptoms of this bug are currently subtle, but only because of the upstream Flutter issue discussed at #500.

The TextStyle that ultimately applies to the text inside one of these spans inherits a fontVariations from an ancestor, which in a paragraph is going to be the one weightVariableTextStyle gives for normal weight. In the absence of that upstream issue, the wght variation from there would control (probably, depending on how the issue gets resolved), and the text would have normal weight (on default system settings) despite being from a StrongNode.

But with that issue, the fontWeight combines with the wght variation and we get a bold effective weight. Effectively this bug roughly cancels out with #500 (… at least on Android, where #500 applies). I say "roughly" because even in the scenario where they both trigger, the effect of #500 seems to make the glyphs heavier but leave their spacing unchanged, so it's not quite the same effect as getting the actual bolder version of the font.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-content Parsing and rendering Zulip HTML content, notably message contents
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants