http://bugs.winehq.org/show_bug.cgi?id=59961 --- Comment #2 from Markus <markus.kern1@gmx.at> --- OS: Fedora 44, Linux (Wine devel branch) Description When running a CEF/Chromium-based Windows application under Wine, text styled with CSS font-weight: bold (or HTML <b> tags) renders in the regular weight instead of bold. This occurs with a TrueType font family installed as separate static weight files (Regular, Bold, etc.), each registered individually under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts (e.g. "<Family> Bold (TrueType)"="<family>-bold.ttf"). Classic GDI-based rendering (tested with Notepad, same font family, same installed files) correctly displays bold text. This isolates the issue to Wine's builtin dwrite.dll font weight/family grouping rather than to font installation, registry setup, or the application itself. Steps to reproduce #1 Install a TrueType font family with separate static weight files (Regular + Bold at minimum) into C:\windows\Fonts, with matching registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts. #2 Run a CEF/Chromium-based Windows application that renders HTML/CSS text referencing that font family and applies font-weight: bold (or <b>) to part of the text. #3 Observe that the bold text renders visually identical to the regular weight. #4 For comparison: open Notepad and manually apply Bold formatting to text using the same installed font family — bold renders correctly there. Expected result Bold text should render using the corresponding bold font face, matching the behavior seen with GDI-based rendering. Actual result Bold text renders in the regular weight; there is no visual distinction between normal and bold text within the CEF/Chromium-based application. Workaround confirmed Overriding dwrite to use the native Windows DLL fixes the issue completely: wine reg add "HKCU\Software\Wine\DllOverrides" /v "dwrite" /t REG_SZ /d "native,builtin" /f With a genuine dwrite.dll copied from a real Windows installation into system32, bold rendering works correctly for the identical font/application/registry setup — confirming the regression is isolated to Wine's builtin dwrite.dll implementation. Additional notes Fully disabling dwrite (DllOverride: disabled) causes the application to fail to start entirely — it has a hard dependency on dwrite.dll being present in some form (native or builtin) and cannot fall back to GDI-only rendering. This may be related to font family/weight grouping logic in Wine's dwrite implementation — potentially similar in nature to historic family-grouping issues seen in other DirectWrite implementations, where GDI-style grouping (by name table ID 1) and DirectWrite-style grouping (by weight-width-slope family name) can diverge for fonts installed as separate per-weight files. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.