[Bug 59961] New: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll
http://bugs.winehq.org/show_bug.cgi?id=59961 Bug ID: 59961 Summary: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwrite Assignee: wine-bugs@list.winehq.org Reporter: markus.kern1@gmx.at Distribution: --- Created attachment 81344 --> http://bugs.winehq.org/attachment.cgi?id=81344 with override -- Bug Report Created by Claude --- Version: wine-11.12 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 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. 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. Observe that the bold text renders visually identical to the regular weight. For comparison: open Notepad and manually apply Bold formatting to text using the same installed font family — bold renders correctly there. welcher bug passt am besten zu meinem fehlerbild? Durchforstete Fehlerliste und identifizierte nächstbeste Übereinstimmung Von der Liste passt am besten: Bug 32965 – "arialbd.ttf not found (Text applied to textures in Kerbal Space Program are not visible)" (Component: fonts) Warum das die beste Übereinstimmung ist Das ist der einzige Eintrag in der Liste, der sich explizit auf die Bold-Variante einer Font-Datei bezieht (arialbd.ttf = Arial Bold) – exakt das Muster, das du hattest: Regular-Schnitt wird gefunden und korrekt gerendert, der Bold-Schnitt wird von Wine nicht aufgelöst/gefunden, obwohl die Datei vorhanden ist. Einschränkung, die du kennen solltest Er liegt unter Komponente fonts, nicht dwrite – das ist wahrscheinlich ein älterer, GDI-naher Bug (Kerbal Space Program nutzt vermutlich kein DirectWrite), während dein Fall ja klar über die dwrite-Schicht lief. Die Symptomatik (Bold-Datei wird nicht gefunden/genutzt) ist aber sehr ähnlich, auch wenn der zugrunde liegende Code-Pfad ein anderer sein könnte. Von den echten dwrite-Bugs in der Liste (54028, 53739, 59252, 59488/89, 48447, 51150, 51367, 56717, 59218, 59487, 50627, 53311) behandelt keiner explizit Weight-/Bold-Gruppierung – die meisten drehen sich um Font-Fallback, fehlenden Text, Performance oder Abstürze bei anderen Programmen. Dein spezifisches Problem (Familie wird erkannt, aber Bold-Weight-Zuordnung schlägt fehl) scheint als eigenständiger Bug noch nicht sauber erfasst zu sein. Praktischer Vorschlag Falls du das dokumentieren willst, wäre ein neuer Bugreport unter Komponente dwrite vermutlich der sauberere Weg, statt 32965 zu kommentieren (der ja ein anderes Programm und wahrscheinlich einen anderen Code-Pfad betrifft). Du hättest mit deinem Fall (Evernote/CEF, Inter-Variable-Font-Familie, Bold wird bei Wine-dwrite.dll ignoriert, mit nativer dwrite.dll behoben) einen sehr klaren, reproduzierbaren Report – das ist genau die Art von Beitrag, die den Wine-Entwicklern hilft, weil du schon den Vergleich Wine-dwrite vs. Native-dwrite als Beweis lieferst. Willst du, dass ich dir einen strukturierten Bugreport-Entwurf dafür erstelle? ist eigentlich inter zwingend notwendig? Evaluierte Notwendigkeit von Inter-Schriftart nach Behebung des Rendering-Problems Nein – "Inter" ist nur der erste Kandidat in der CSS-Fallback-Kette, kein Hard-Requirement: font-family: Inter, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif Der Browser/CEF-Renderer geht die Liste von links nach rechts durch und nimmt den ersten Font, den er tatsächlich findet. Fehlt "Inter" komplett, fällt er automatisch auf den nächsten verfügbaren zurück – z.B. "Segoe UI" (die ist ja über deine kopierten Windows-Fonts vermutlich ohnehin vorhanden) oder letztlich das generische sans-serif. Der entscheidende Punkt jetzt, nach deinem Fix Da die eigentliche Ursache (Wines dwrite.dll gruppiert Bold-Varianten nicht korrekt) jetzt durch die native dwrite.dll systemweit behoben ist, betrifft das nicht nur Inter, sondern jede Font-Familie in deinem Prefix. Das heißt: Selbst wenn du "Inter" komplett entfernst und der Browser auf "Segoe UI" oder sogar nur generisches sans-serif zurückfällt, würde Bold jetzt korrekt dargestellt werden – weil die native DirectWrite-Engine die Weight-Gruppierung für alle installierten Fonts sauber übernimmt, nicht nur für Inter. Praktisch heißt das für dich Du musst Inter nicht behalten, wenn du Speicherplatz sparen oder den Prefix aufräumen willst Die optische Übereinstimmung mit dem "echten" Evernote-Look (Windows/Mac-Client) ist aber nur mit Inter gegeben – ohne Inter sieht der Text etwas anders aus (Segoe UI hat andere Proportionen/Zeichenformen) Falls dir das Erscheinungsbild egal ist und nur "Bold funktioniert" zählt, kannst du die Inter-Dateien und den Registry-Import jederzeit wieder entfernen, ohne dass das Bold-Problem zurückkommt – der Fix sitzt ja jetzt auf Ebene der DirectWrite-Engine, nicht auf Ebene der einzelnen Font Falls du die Inter-Fonts drinlässt, hast du also im Grunde nur den optisch "originalgetreueren" Look zusätzlich zur ohnehin behobenen Bold-Funktionalität. ok - erstelle mir infos für einen bugreport bei wine Orchestrierte strukturierten Bug-Report mit technischen Details und bilingualer Formatierung Hier ein strukturierter Report-Entwurf, den du bei WineHQ Bugzilla (Component: dwrite) einreichen kannst. Bug-Reports dort sind auf Englisch üblich, daher hab ich den Report-Inhalt direkt auf Englisch formuliert – du musst nur noch die Platzhalter (Wine-Version etc.) ergänzen. Component: dwrite Summary: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll Version: [bitte wine --version einfügen] OS: Fedora 44, Linux (Wine devel branch) Description When running a CEF/Chromium-based Windows application (Evernote 11.23.2) under Wine, text styled with font-weight: bold (or <b> tags) is rendered in the regular weight instead of bold — but only for certain font families. The issue is reproducible with the "Inter" font family (all 18 static weight variants, Thin through Black, plus italics, installed as separate HKLM\...\CurrentVersion\Fonts registry entries pointing to individual .ttf files per weight, e.g. "Inter Bold (TrueType)"="Inter-Bold.ttf"). Classic GDI-based rendering (tested with Notepad) correctly displays bold text using the exact same installed fonts. This isolates the issue to Wine's dwrite.dll (builtin) font weight/family grouping, rather than to font installation or GDI itself. Steps to reproduce Install Inter font family (all static weights) into C:\windows\Fonts, with matching registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts. Run a CEF/Chromium-based Windows application that renders HTML/CSS text with font-family: Inter, ... and applies font-weight: bold (or <b>) to some of that text. Observe that bold text renders visually identical to regular-weight text. For comparison: open Notepad (or another classic GDI app) and manually apply Bold formatting to text in the same font family — bold renders correctly. Expected result Bold text should render with the corresponding bold font face, matching GDI-based rendering behavior. Actual result Bold text renders in the regular weight; no visual distinction between normal and bold text. 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 dwrite.dll copied from a genuine Windows installation into system32, bold rendering works correctly for the same font/application/registry setup — confirming the regression is isolated to Wine's builtin dwrite.dll implementation, not to font installation, registry setup, or the application itself. Additional notes Fully disabling dwrite (DllOverride: disabled) causes the application to fail to start entirely — the application has a hard dependency on dwrite.dll being present in some form (native or builtin), it cannot fall back to GDI-only rendering. This may be related to font family/weight grouping logic in Wine's dwrite implementation (similar in nature to historic issues like bug 584769 in other DirectWrite implementations, where GDI-style vs. DirectWrite-style family grouping — based on name table / weight-width-slope family name — differ). Zwei Dinge, die du vor dem Einreichen noch ergänzen solltest: wine --version – exakte Versionsnummer Falls du magst, ein Vorher/Nachher-Screenshot (Bold mit builtin dwrite vs. mit nativer dwrite.dll) – das ist bei Font-Rendering-Bugs fast immer hilfreicher als reine Textbeschreibung und wird von Wine-Maintainern gerne gesehen Soll ich dir noch eine minimale Testanwendung/HTML-Datei vorbereiten, die das Problem ganz ohne Evernote reproduziert (nur reines HTML mit font-family: Inter + font-weight: bold in einem CEF-Testkontext)? Das würde den Report für die Wine-Entwickler noch einfacher nachvollziehbar machen, da er nicht an eine proprietäre App gebunden ist. beim bugreport - lass das mit inter weg und mache in auf english neu Generalized bug report, removing font-specific details Hier die überarbeitete Version – generisch gehalten, ohne Bezug zu Inter, auf Englisch: Component: dwrite Summary: dwrite.dll (builtin) does not apply bold font weight in CEF/Chromium-based application; native dwrite.dll works correctly Version: [insert wine --version output here] 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.
http://bugs.winehq.org/show_bug.cgi?id=59961 --- Comment #1 from Markus <markus.kern1@gmx.at> --- Created attachment 81345 --> http://bugs.winehq.org/attachment.cgi?id=81345 without override -- 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.
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.
http://bugs.winehq.org/show_bug.cgi?id=59961 --- Comment #3 from Markus <markus.kern1@gmx.at> --- please remove the initial comment - it contains info from the claude chat window that is not relevant for the bug report -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59961 --- Comment #4 from Nikolay Sivov <bunglehead@gmail.com> --- There are different ways for it to groups fonts in families, and both will depend on actual font data. The much easier way to test something like that is to use Notepad++ which is able to render through dwrite. Which fonts exactly are use copying to system32/fonts ? P.S. please next time explain the issue in your own words, instead of generating it. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59961 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://win.desktop.evernot | |e.com/builds/Evernote-lates | |t.exe -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59961 --- Comment #5 from Markus <markus.kern1@gmx.at> --- Hello Nikolay, I've used the inter font family (github.com/rsms/inter) In a new prefix with Notepad++ it works flawless - bold is displayed correctly. -- 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.
participants (1)
-
WineHQ Bugzilla