content: **bold code** renders in regular font weight, but should be bold
#498
Assignees
Labels
a-content
Parsing and rendering Zulip HTML content, notably message contents
Milestone
Comments
chrisbobbe
added
the
a-content
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this issue
Feb 1, 2024
Our experience with variable-weight fonts is that, whenever we use
such a font, we need to specify a "wght" value, even if we want the
text to appear in the boring, regular weight. If we don't specify a
"wght", the text will appear in an extremely light weight.
We use a variable-weight font (Source Code Pro) for rendering inline
code spans, so that's why we were using weightVariableTextStyle
here. As an unfortunate result, when a code span appears inside a
bold ("strong") span, the outer span's bold-weight style has been
getting clobbered, and the code span appears in regular weight.
Fortunately, removing the `weightVariableTextStyle` from the inline
code style doesn't actually cause any inline spans to appear at
minimum weight. This is a relief, and it follows from the presence
of a `weightVariableTextStyle` applied at the paragraph-content
level. We use `weightVariableTextStyle` there because the paragraph
font, Source Sans 3, is also a variable-weight font. Moreover,
Source Code Pro and Source Sans 3 seem closely related (and were
designed by the same person), so it's likely that their "wght" axes
are identical.
Fixes: zulip#498
chrisbobbe
added a commit
to chrisbobbe/zulip-flutter
that referenced
this issue
Feb 2, 2024
Our experience with variable-weight fonts is that, whenever we use
such a font, we need to specify a "wght" value, even if we want the
text to appear in the boring, regular weight. If we don't specify a
"wght", the text will appear in an extremely light weight.
We use a variable-weight font (Source Code Pro) for rendering inline
code spans, so that's why we were using weightVariableTextStyle
here. As an unfortunate result, when a code span appears inside a
bold ("strong") span, the outer span's bold-weight style has been
getting clobbered, and the code span appears in regular weight.
Fortunately, removing the `weightVariableTextStyle` from the inline
code style doesn't actually cause any inline spans to appear at
minimum weight. This is a relief, and it follows from the presence
of a `weightVariableTextStyle` applied at the paragraph-content
level. We use `weightVariableTextStyle` there because the paragraph
font, Source Sans 3, is also a variable-weight font. Moreover,
Source Code Pro and Source Sans 3 seem closely related (and were
designed by the same person), so it's likely that their "wght" axes
are identical.
Fixes: zulip#498
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: