On Windows 10 Pro 64-bit en-US with Version: 5.3.0.0.alpha0+ Build ID: cbf36dd473fdc9e8d8b78c9e9317836a7cbbc6c7 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-06-01_00:32:07 Locale: en-US (en_US) Seem to be doing better with DirectWrite font composition on Windows when OpenGL rendering is enabled. However, the calculated height of glyphs seems erratic and glyphs for whole lines of text are framed wrong. See attached example document and clips with and without OpenGL rendering enabled. With OpenGL rendering enabled and DirectWrite composition glyphs are not positioned centered and are being clipped as compared to default rendering.
Created attachment 125432 [details] Writer document with a mix of BMP and SMP glyphs
Created attachment 125433 [details] clip of sample document without OpenGL rendering
Created attachment 125434 [details] clip of sample document using OpenGL rendering
Is it always just non-BMP glyphs that get clipped, or would "weird" glyphs like these pictograms be clipped also if they were for characters in the BMP?
Created attachment 125456 [details] Writer document with glyphs for symbols from BMP codepoints (In reply to Tor Lillqvist from comment #4) > Is it always just non-BMP glyphs that get clipped, or would "weird" glyphs > like these pictograms be clipped also if they were for characters in the BMP? Attached another test document (and screen clips) with mostly BMP on lines (1F607 and 1F608 for control). Also, several PUA codepoints (E425, E427, E429) for symbols to show (or not) substitution. So, yes would say the miscalculated DirectWrite character bounds with OpenGL rendering only seem to affect glyphs for the SMP codepoints.
Created attachment 125457 [details] test file without OpenGL rendering Version: 5.3.0.0.alpha0+ Build ID: cbf36dd473fdc9e8d8b78c9e9317836a7cbbc6c7 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-06-01_00:32:07 Locale: en-US (en_US) Name NVIDIA GeForce GTX 750 Ti PNP Device ID PCI\VEN_10DE&DEV_1380&SUBSYS_37553842&REV_A2\4&1D0A902F&0&0018 Adapter Type GeForce GTX 750 Ti, NVIDIA compatible Adapter Description NVIDIA GeForce GTX 750 Ti Adapter RAM (2,147,483,648) bytes Installed Drivers nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um,nvwgf2um Driver Version 10.18.13.6191 Driver c:\windows\system32\drivers\nvlddmkm.sys (10.18.13.6191, 11.90 MB (12,478,528 bytes), 2/23/2016 11:26 PM)
Created attachment 125458 [details] test file with OpenGL rendering
Repro with OGL enabled. Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+ Build ID: cf0fea5546c9b6b30d18deb084ddaa5e08aad41b CPU Threads: 4; OS Version: Windows 6.1; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-07-30_23:31:05 Locale: fi-FI (fi_FI); Calc: CL
Find the experimental[1] HarfBuzz based common layout fixes this nicely. =-note-= [1] experimental at 5.3.0, target 5.4?
(In reply to V Stuart Foote from comment #9) > [1] experimental at 5.3.0, target 5.4? Target is 5.3 unless there are any blocker, it will soon be turned on by default on master.
(In reply to V Stuart Foote from comment #9) > Find the experimental[1] HarfBuzz based common layout fixes this nicely. > > > =-note-= > [1] experimental at 5.3.0, target 5.4? sorry, that here, but where i can read about HarfBuzz and how to activate it in LibreOffice?
(In reply to kompilainenn from comment #11) > (In reply to V Stuart Foote from comment #9) > > Find the experimental[1] HarfBuzz based common layout fixes this nicely. > > > > > > =-note-= > > [1] experimental at 5.3.0, target 5.4? > > sorry, that here, but where i can read about HarfBuzz and how to activate it > in LibreOffice? See the description of bug 103403 You have to launch soffice.exe from the same terminal window you use to set the environment variable.