The numbers of the Vertical Ruler are not formed correctly when OpenGL rendering is enabled. But when default rendering, HA or CPU is enabled the numbered labeling of the vertical ruler is correct. Windows 10 Home 64-bit en-US (1903) with Intel HD Graphics 630 with recent builds of Master/6.4.0 Version: 6.4.0.0.alpha0+ (x64) Build ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-01_22:04:10 Locale: en-US (en_US); UI-Language: en-US Calc: threaded Not present in Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Somewhere in this range 2019-08-16 to 2019-08-27 https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=3e64065612acec2eb29aa21e2b515953422256d7..0fb2927a8fe06e6c3255544b8e4c4c9c0f5a67d3
Created attachment 153855 [details] numbering on vertical ruler is broken
Affects more than just the rotated text of the vertical ruler. With OpenGL rendering enabled (on Winodws builds at least) font metrics are incorrectly used and glyphs are clipped when stamped. I was working with rotating text of table cells for bug 127485 and noticed more than just the vertical ruler mark, all rotated text is being clipped when OpenGL rendering is enabled. OK with 6.3.1.2 and builds of master through 2019-08-16, suggests recent change to Direct2D DirectWrite handling. Attached document with table 'Table contents' style adjusted to use Noto Sans and all table cell contents rotated, and column width and column height optimized for the full table. While test document has style changed, with OpenGL rendering enabled, using any font's rotated glyphs are clipped when stamped to canvas.
Created attachment 154174 [details] sample document table with rotated text showing clipped glyphs with OpenGL rendering
Created attachment 154176 [details] clipped rotated text in Calc cells with OpenGL rendering To be expected, clipping with OpenGL rendering also affecting Calc cells with rotated text.
Created attachment 154177 [details] same Windows system with default GDI rendering, font well formed Version: 6.4.0.0.alpha0+ (x64) Build ID: 0d0e8533afe565564835e6d51500e64066fd565b CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-09-14_07:47:01 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Most likely caused by this https://cgit.freedesktop.org/libreoffice/core/commit/?id=502d73cda8fa1f482634bb6435fd1440757fdad9. I don’t have time to debug it, but if someone can confirm this is real cause I’ll revert it.
*** Bug 127580 has been marked as a duplicate of this bug. ***
Roman K. bisected the chart labeling of bug 127580 <clip> asus@notebook-2 /cygdrive/d/logit/bibisect-win64-6.4 $ git bisect good 237d634d91cd5d1a27714eeedf2f0537691d94e2 is the first bad commit commit 237d634d91cd5d1a27714eeedf2f0537691d94e2 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sun Aug 25 03:32:10 2019 -0700 source 502d73cda8fa1f482634bb6435fd1440757fdad9 https://gerrit.libreoffice.org/#/c/77870/ </clip>
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4ce644feaa732e9f306e6c53300e024ac2a11bb7 tdf#127325: Revert "Use HarfBuzz to get glyph bounding rectangle" It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.