On Windows 10 Pro 64-bit en-US with nVidia GPU Version: 6.1.0.0.alpha1+ (x64) Build ID: c5f8a296fcfc08f8ac441cb8300a7565caa50b53 CPU threads: 8; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-10_01:41:43 Locale: en-US (en_US); Calc: group The Formula editor is having issues composing its nodes. Notably, scalable nodes are not sized correctly, and while default GDI rendering makes a glyph assignment, they are not placed correctly. With OpenGL rendering, the wrong glyphs for scalable nodes are being used (fallback of some sort) and sm nodes are misplaced and mis-sized. STR: 1. launch LibreOffice with OpenGL rendering enabled 2. Open a new Math Formula 3. note the Expressions sidebar - glyphs in the Urnary/Binary Operators are misplaced 4. use drop list to select the Brackets elements - the upper section fixed brackets show (all OpenSymbol glyphs) - in the lower section all the "scalable" brackets, getting bad font assignment and unknown glyphs are used for the sample nodes On repeat with Default GDI rendering. For the sizable brackets, correct glyph is used, but still misplaced and sized. =-note-= Work on salfont.cxx and winlayout.cxx in https://gerrit.libreoffice.org/#/c/47408/ https://gerrit.libreoffice.org/#/c/47279/ led to OpenGL font handling issues of bug 117517 https://gerrit.libreoffice.org/#/c/54046/ has resolved that mostly.
Created attachment 142007 [details] Clips of the Unary/binary and Brackets panels with OpenGL and with Default GDI rendering
Hi V Stuart Foote, I reproduced with LO 6.1.0.0.alpha1+ (x64) Build ID: c5f8a296fcfc08f8ac441cb8300a7565caa50b53 CPU threads: 2; OS: Windows 6.1; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-10_01:41:43 Locale: fr-FR (fr_FR); Calc: CL also with LO 6.1.0.0.alpha1+ (x64) Build ID: 4c5b4752786ae2c174cd8fa8aa42b27a0994f34a CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-08_23:43:34 Locale: fr-FR (fr_FR); Calc: CL but not with LO 6.1.0.0.alpha1+ (x64) Build ID: 08441d466dd70c203a519a133aaf1a5997adbbd3 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-07_01:12:11 Locale: fr-FR (fr_FR); Calc: CL
Font fallback seems to be affecting more of the Expressions Sidebar's pannels, moving between the panels--initially correct on launch, moving between the pannels eventuall a cache is flushed and the font fallback is wrong. The example grids are getting weird metric so the grid entry is a single column and font fallback is failing so neither Open Symbol nor Liberation Serif are getting good glyphs and show "missing glyph" boxes. It also affects the formula pane on refresh. Loss of fallback font affecting both OpenGL _and_ Default rendering. @Khaled, saw you've been poking at this with -- thanks! https://gerrit.libreoffice.org/#/c/54154/ =-ref-= On Windows 10 Home 64-bit en-US (ver 1709) with Version: 6.1.0.0.alpha1+ (x64) Build ID: 8162520f251f3382b84d97319ca7facf0bb9c670 TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-13_00:48:05 Build ID: 29cebedfbdc8a8d3bf47e9a8148dc081bf86eb10 TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-16_00:28:23 Build ID: 8c07193cec5e09d50b20bc5b107da02a7d8f05a5 TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-17_23:03:56
Created attachment 142193 [details] clip of sm with failing font fallback
Created attachment 142228 [details] font cahce loss affecting StartCenter as well So, it seems to affect more than just the sm module. From Writer, closing the last open document to revert to the StartCenter shows it has lost its font cache and all glyphs are stamped as unknown with odd metrics. On Windows 10 Home 64-bit en-US with Version: 6.1.0.0.alpha1+ (x64) Build ID: e1a8338876bd161de4e9d9a4b22d4bc5335f7cee CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-18_23:55:37 Locale: en-US (en_US); Calc: CL
Regression introduced by: author Jan-Marek Glogowski <glogow@fbihome.de> 2017-12-26 15:14:31 +0000 committer Khaled Hosny <khaledhosny@eglug.org> 2018-05-08 00:55:27 +0200 commit bdccb7e9991d83029eb2f2f11327b54534a00db8 (patch) tree c32e95c49849647dc72c1071f375f3d2b67d8d7a parent 9615e45d2e2bac79c252a018846e4f20012cfa34 (diff) Refactor CommonSalLayout font handling Moves all platform specific code from CommonSalLayout into the platform specific plugins. This way the vcl library won't depend on the Qt5 libraries and the Qt5Font header can be moved into the qt5 VCL plugin. While at it, switch the CommonSalLayouts font reference from the FontSelectPattern to the LogicalFontInstance and also add the harfbuzz font handling to the instance. Bisected with: bibisect-win32-6.1 Adding Cc: to Jan-Marek Glogowski
Resolved fixed on Windows 10 Home 64-bit en-US with Version: 6.2.0.0.alpha0+ (x64) Build ID: 86ca9badf9be518be3456afde70271bc1f956065 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-07-11_02:27:04 Locale: en-US (en_US); Calc: CL Both default GDI+ and OpenGL based rendering handing fonts correctly =-ref-= https://cgit.freedesktop.org/libreoffice/core/commit/?id=fad862e290d727fc9fefe206f6e4b807482c4175 https://cgit.freedesktop.org/libreoffice/core/commit/?id=ca4e75d694a5fb41a1c800146319aa6ba34d8bab
Created attachment 143611 [details] Brackets Elements in LO 6.2.0.0, OpenGL on, Windows 7 Hello, Bug still there with LO 6.2.0.0.alpha0+ Build ID: 7ba295853669f7c333ba22e8284e9732091c67fa CPU threads: 2; OS: Windows 6.1; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-07-18_00:09:49 Locale: fr-FR (fr_FR); Calc: CL
(In reply to Jacques Guilleron from comment #8) > Created attachment 143611 [details] > Brackets Elements in LO 6.2.0.0, OpenGL on, Windows 7 > > Hello, > > Bug still there with > LO 6.2.0.0.alpha0+ Build ID: 7ba295853669f7c333ba22e8284e9732091c67fa > CPU threads: 2; OS: Windows 6.1; UI render: GL; > TinderBox: Win-x86@42, Branch:master, Time: 2018-07-18_00:09:49 > Locale: fr-FR (fr_FR); Calc: CL Issue with the Round Brackets [Scalable] is with the node calculation, not with the glyph selection from font. It behaves correctly on the formula canvas. Issue here is fixed.
Indeed, the issue is still reproducible in Versión: 6.1.0.2 Id. de compilación: b3972dcf1284967612d5ee04fea9d15bcf0cc106 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group threaded Let's keep it tracked in bug 118884