Skip to content

Add Style::strong_font and Style::emphasis_font for real bold/italic rendering#7946

Open
w4nderlust wants to merge 2 commits intoemilk:mainfrom
atelico:feature/strong-emphasis-fonts
Open

Add Style::strong_font and Style::emphasis_font for real bold/italic rendering#7946
w4nderlust wants to merge 2 commits intoemilk:mainfrom
atelico:feature/strong-emphasis-fonts

Conversation

@w4nderlust
Copy link
Copy Markdown

Summary

This adds two optional fields to Style that let users swap in real bold and italic font families for RichText::strong() and RichText::italics(), instead of relying on the default approximations (color change for bold, vertex skew for italic).

Currently, RichText::strong() only changes the text color (via Visuals::strong_text_color()), which does not produce visually bold text. And RichText::italics() applies a 25-degree horizontal vertex skew, which is a rough approximation that looks noticeably different from a real italic typeface. These defaults are fine when no custom fonts are available, but when users have access to proper Bold/Italic font files, there is no way to tell egui to use them for strong/italic markup.

Changes

Two new Option<FontFamily> fields on Style:

  • strong_font: When set, RichText::strong() renders with this font family instead of applying the strong text color. The color override is skipped because the heavier strokes of a real bold typeface provide visual distinction on their own.

  • emphasis_font: When set, RichText::italics() renders with this font family instead of applying the vertex skew. The skew is skipped because the real italic letterforms are used instead.

Both default to None, so existing behavior is completely unchanged.

Implementation details

The logic lives in RichText::into_text_and_format() and RichText::get_text_color() in widget_text.rs:

  • into_text_and_format() resolves the bold/italic font family overrides before building the FontId. If both strong_font and emphasis_font are set and the text is both strong and italic, emphasis_font wins (since a FontId can only reference one family). Users who need combined bold-italic can register a dedicated BoldItalic family and apply it via RichText::family().

  • get_text_color() skips the strong color override when strong_font is set, falling through to the default text color instead.

Usage

// 1. Register bold/italic fonts
let mut fonts = egui::FontDefinitions::default();
fonts.font_data.insert(
    "MyFont-Bold".to_owned(),
    egui::FontData::from_static(include_bytes!("MyFont-Bold.ttf")).into(),
);
fonts.families.insert(
    egui::FontFamily::Name("Bold".into()),
    vec!["MyFont-Bold".to_owned()],
);
ctx.set_fonts(fonts);

// 2. Configure style
ctx.global_style_mut(|style| {
    style.strong_font = Some(egui::FontFamily::Name("Bold".into()));
    // style.emphasis_font = Some(egui::FontFamily::Name("Italic".into()));
});

After this, any RichText::new("hello").strong() will render using the Bold font family.

Motivation

This came up while building a markdown renderer on top of egui. Markdown has **bold** and *italic* syntax, and users expect these to render with proper bold/italic typefaces when available. Libraries like egui_commonmark use RichText::strong() and RichText::italics() internally, so configuring the style once is enough to get real bold/italic rendering throughout the whole UI without patching downstream libraries.

Checklist

  • I have followed the instructions in the PR template
  • cargo fmt passes
  • cargo clippy passes
  • All 175 egui tests pass (including the new doc tests)
  • No changes to default behavior (both fields default to None)
  • Doc comments with working examples on both new fields

@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 2, 2026

Preview is being built...

Preview will be available at https://egui-pr-preview.github.io/pr/7946-feature/strong-emphasis-fonts

View snapshot changes at kitdiff

@w4nderlust w4nderlust force-pushed the feature/strong-emphasis-fonts branch from 1d47a57 to a25d046 Compare March 2, 2026 13:57
…rendering

Currently, `RichText::strong()` fakes bold by changing the text color,
and `RichText::italics()` fakes italic by applying a vertex skew.
This works as a zero-configuration default, but produces noticeably
different results from real bold/italic typefaces.

This commit adds two optional fields to `Style`:

- `strong_font: Option<FontFamily>` — when set, strong text uses this
  font family instead of applying a color change.
- `emphasis_font: Option<FontFamily>` — when set, italic text uses this
  font family instead of applying a vertex skew.

Both default to `None`, preserving full backwards compatibility.

Usage:
  1. Register bold/italic font data via `Context::set_fonts()`
  2. Set `style.strong_font` / `style.emphasis_font` to the family names

When a bold font is configured, `get_text_color()` skips the strong
color so the typeface weight alone provides emphasis. When an italic
font is configured, the vertex skew is disabled in `TextFormat`.

When text is both strong and italic and both overrides are set,
`emphasis_font` takes precedence since a single `FontId` can only
reference one font family. Users needing combined bold-italic can
register a dedicated BoldItalic family via `RichText::family()`.
Use fully qualified `crate::Visuals::override_text_color` since Visuals
is not imported in widget_text.rs. Fixes cargo doc with -D warnings.
@w4nderlust w4nderlust force-pushed the feature/strong-emphasis-fonts branch from a25d046 to 213b03a Compare March 2, 2026 14:00
@Tristan117
Copy link
Copy Markdown

This looks like a great small quality of life feature!
In my application as a workaround I'm currently manually using an italic font on italic text rather than RichText::italics() which this PR would avoid.

@emilk is there a reason the italic and bold versions of the UbuntuLight default font aren't included in the default fonts (or behind a feature if binary size/performance is a concern for some targets)? Would a PR along these lines be of interest?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants