http://bugs.winehq.org/show_bug.cgi?id=59925 --- Comment #7 from Robert Owens <robowens@me.com> --- Follow-up (codepoint discriminator + source-level diagnosis): the defect is specific to U+002D and is NOT in Wine's dwrite analyzer. CODEPOINT DISCRIMINATOR Holding the text pattern constant and varying only the mark's codepoint (offscreen RenderTargetBitmap, wine-staging 11.10), only U+002D renders as .notdef. U+2010 HYPHEN, U+2011 NON-BREAKING HYPHEN, U+2013 EN DASH, U+2014 EM DASH, U+2212 MINUS SIGN, and ASCII '=' / '.' / middle-dot all render correctly -- in both Segoe UI and Eurostile. So the defect is font-independent and specific to the single codepoint U+002D, not a dash/line-break-class or generic-fallback issue. SOURCE + TRACE DIAGNOSIS (vanilla wine-11.10 source; +dwrite,+font trace of the offscreen --render run) 1. dlls/dwrite/analyzer.c get_char_sa() does NOT special-case U+002D. The only hyphen it marks no-visual is U+00AD (SOFT HYPHEN), plus the ZWSP/ZWNJ/ZWJ/LRM/RLM range 0x200b-0x200f. U+002D is classified as a normal visible Latin/Common character, which is correct. So this is not analogous to bug 55529 (a real analyzer misclassification). 2. The hyphen is never handed to dwrite shaping. Every line itemizes as the runs L"...A", L"B", L"C NL", L"C4", L"1" -- the hyphen is orphaned into a run that never reaches dwritetextanalyzer_GetGlyphs (zero L"-" runs in the whole trace). This split is byte-identical across all five lines, including the four whose hyphen renders fine. So the orphaning/split is not the bug. 3. The hyphen character never reaches the GDI/win32u glyph path either. dlls/win32u/font.c has no U+002D special-case, and the only freetype_get_glyph_outline calls whose glyph argument is 0x2d are a sequential glyph-INDEX metrics walk (...0024,0025,...,002c,002d,002e,002f..., format GGO_METRICS) of a cached GDI font being measured for text extent -- a red herring, not the hyphen character. There are zero glyph-outline calls for the actual hyphen glyph ids (Futura 14 / Eurostile 15 / Tahoma 16). 4. IDWriteFontFallback::MapCharacters is never called (count 0). WPF runs its own fallback: IDWriteFont::HasCharacter probed 37x, load_system_links 2586x. The per-character HasCharacter walk (covering every char incl. the four 0x2d) occurs for exactly one of the five lines -- the Futura line -- and not for the Segoe line (which tofus) nor the Eurostile lines (which render here). So even within WPF's own fallback the per-font code path varies, and HasCharacter-walk presence does not track the render-vs-tofu outcome. 5. The public DirectWrite surface is already verified correct for U+002D (see the negative-control attachments): IDWriteTextLayout, MapCharacters, HasCharacter(0x2d)=true, GetGlyphIndices(0x2d)=real glyph all pass for these fonts. Net: every Wine layer that IS asked about U+002D answers correctly. The drop happens inside WPF/PresentationCore's own run-itemization + per-font fallback bookkeeping running on Wine -- it orphans the hyphen identically for the lines that render and the line that tofus, then decides render-vs-drop in a path that +dwrite/+font does not expose (managed code + glyph-run rasterization). A maintainer familiar with the PresentationCore <-> Wine boundary will likely have to look at which Wine API WPF's internal fallback queries for the orphaned single-hyphen run, and why that diverges for Segoe. -- 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.