http://bugs.winehq.org/show_bug.cgi?id=59068 --- Comment #4 from Mark Gould <mgould@spindlemedia.com> --- Still reproducible on Wine 11.0, 32-bit prefix, Ubuntu 24.04. An independent API-only check uses CreateCompatibleDC(NULL), Arial with lfHeight=-10 and lfWeight=FW_NORMAL, then ScriptItemize -> ScriptShape -> ScriptPlace. The following values are (abcA+abcB+abcC) / sum(piAdvance), in pixels: Wine 11 builtin Microsoft usp10 under Wine Native Windows AV 14 / 13 13 / 13 13 / 13 To 12 / 11 11 / 11 12 / 12 AVATAR 41 / 37 37 / 37 38 / 38 SAMPLE PROPERTY DESCRIPTION 173 / 173 173 / 173 176 / 176 The Microsoft DLL under Wine is version 1.0626.7601.23259, already bundled with Crystal Reports SP25 x86. Native Windows uses the system usp10.dll, version 10.0.26100.1. Windows and Wine have different Arial versions, so the relevant comparison is total versus advances within each run, not absolute widths across systems. This also affects Crystal Reports layout: a one-pixel mismatch crosses a fixed-width field's fit boundary and can cause extra wrapping/clipping for identical input. Selecting the bundled Microsoft DLL removes the observed variation in 60 repeated renders of the original report. Source inspection at Wine master 1977760e3745c58ee9c2b8aeb93e54e5fe7f14e2 still shows ABC accumulated before SHAPE_ApplyOpenTypePositions, with no reconciliation afterward: https://gitlab.winehq.org/wine/wine/-/blob/1977760e3745c58ee9c2b8aeb93e54e5f... The executable reproduction above was run on Wine 11.0, not a build of current master. This was an AI-assisted investigation; these measurements were obtained by executing the program locally. No implementation or test code is attached. -- 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.