Created attachment 128551 [details] harfbuzz vs no-harfbuzz Text is cramped in the menu bar and toolbar comboboxes as can be seen in the attached screenshot. I'm running Linux Mint 17.3 (Ubuntu 14.04 base) with Noto Sans as the system font. Version: 5.3.0.0.alpha1+ Build ID: 11cab8aba359c655a75791ddbc0f2ffeae8ce206 CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; VCL: gtk2; Layout Engine: new; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-11-06_23:07:09 Locale: en-US (en_US.UTF-8); Calc: group
On Linux, HarfBuzz is used in both old a new layout engines, and the code is mostly based on the old Linux code, so I’m surprised there is a difference. Can you test with the alpha release and see if you can see the difference there as well?
Confirmed with the same 5.3 daily build / Ubuntu 16.04. Also confirmed with alpha1. To be clear, I used SAL_USE_COMMON_LAYOUT to enable common layout in alpha1, and SAL_NO_COMMON_LAYOUT to disable common layout in the daily build, and in both cases the rendering of menus looked cramped when common layout was enabled.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c49d5dea164b09b05a898495fa2dd48b7ca4f0e4 tdf#103765: Minimize the effect of rounding to int It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This should be fixed now. There is still some difference (the new text might be slightly wider) but I believe the new rendering is the correct one.
The fix for this caused bug 103891, so I’m going to revert it. Thinking about this again, this big might related to the fact that we don’t use FreeType to get glyph advance widths so if FreeType changed the width (e.g. because of hinting), we might be using different glyph widths for layout. Not sure how to fix this, though.
*** Bug 104173 has been marked as a duplicate of this bug. ***
Created attachment 129023 [details] Screenshot of menu with HarfBuzz Yes, Bug 104173 is indeed a dupe for this. Reverting commit d35b5c8db00afb0316b7ae4c43126a5dad194cbb (i.e. activating commit c49d5dea164b09b05a898495fa2dd48b7ca4f0e4) makes things much better. This screenshot made with screen resolution shows current state on Windows (HarfBuzz enabled, commit c49d5dea164b09b05a898495fa2dd48b7ca4f0e4 partially reversed). The following two screenshots show the same area for reverted d35b5c8db00afb0316b7ae4c43126a5dad194cbb, and previous state (with old layout engine). It's better to switch between them in sequence when their position on screen is the same, to see pixel differences.
Created attachment 129024 [details] Screenshot of menu with HarfBuzz and c49d5dea164b09b05a898495fa2dd48b7ca4f0e4 applied This is with d35b5c8db00afb0316b7ae4c43126a5dad194cbb reverted. I mistakingly named previous as "c49d5dea164b09b05a898495fa2dd48b7ca4f0e4 applied", but actually this one is.
Created attachment 129025 [details] Screenshot of menu without HarfBuzz Previous state. Please notice that this is *almost* identical to how HarfBuzz works with d35b5c8db00afb0316b7ae4c43126a5dad194cbb reverted; but there are still sometimes 1-pixel shifts.
So I think this all comes down to the fact that we don’t do subpixel positioning and accumulate rounding error, i.e. bug 103322.
(In reply to Khaled Hosny from comment #10) > So I think this all comes down to the fact that we don’t do subpixel > positioning and accumulate rounding error, i.e. bug 103322. ... in which case the abovementioned issue is no more an enhancement, and this one depends on it?
I guess so, though to be honest I’m not 100% sure it will fix this issue.
As the problem seems to impair usage of LO by users with poor eyesight, I raise the importance of this bug.
*** Bug 104223 has been marked as a duplicate of this bug. ***
*** Bug 104575 has been marked as a duplicate of this bug. ***
Created attachment 129796 [details] Screenshot of menu with HarfBuzz and https://gerrit.libreoffice.org/32211 applied
*** Bug 104738 has been marked as a duplicate of this bug. ***
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9eb4b14ffa57cd7bbdf0fc43096f5f1e65c8e388 tdf#103765: Round positions instead of truncating It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e63617ef934d3602bbc22f0f01c77b024347e60&h=libreoffice-5-3 tdf#103765: Round positions instead of truncating It will be available in 5.3.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.