Bug 103765 - Rendering of system font cramped with Harfbuzz
Summary: Rendering of system font cramped with Harfbuzz
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha1+
Hardware: All All
: high major
Assignee: Khaled Hosny
URL:
Whiteboard: target:5.3.0 target:5.4.0 target:5.3.0.1
Keywords:
: 104173 104223 104575 104738 (view as bug list)
Depends on:
Blocks: Regressions-HarfBuzz
  Show dependency treegraph
 
Reported: 2016-11-07 19:09 UTC by Yousuf Philips (jay) (retired)
Modified: 2018-01-02 22:55 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
harfbuzz vs no-harfbuzz (51.53 KB, image/png)
2016-11-07 19:09 UTC, Yousuf Philips (jay) (retired)
Details
Screenshot of menu with HarfBuzz (18.00 KB, image/png)
2016-11-26 11:03 UTC, Mike Kaganski
Details
Screenshot of menu with HarfBuzz and c49d5dea164b09b05a898495fa2dd48b7ca4f0e4 applied (17.45 KB, image/png)
2016-11-26 11:06 UTC, Mike Kaganski
Details
Screenshot of menu without HarfBuzz (21.36 KB, image/png)
2016-11-26 11:07 UTC, Mike Kaganski
Details
Screenshot of menu with HarfBuzz and https://gerrit.libreoffice.org/32211 applied (18.82 KB, image/png)
2016-12-20 00:08 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2016-11-07 19:09:24 UTC
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
Comment 1 Khaled Hosny 2016-11-07 19:36:31 UTC
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?
Comment 2 Aron Budea 2016-11-08 01:42:58 UTC
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.
Comment 3 Commit Notification 2016-11-11 16:29:51 UTC
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.
Comment 4 Khaled Hosny 2016-11-11 16:33:28 UTC
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.
Comment 5 Khaled Hosny 2016-11-19 13:47:59 UTC
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.
Comment 6 Adolfo Jayme 2016-11-26 02:17:23 UTC
*** Bug 104173 has been marked as a duplicate of this bug. ***
Comment 7 Mike Kaganski 2016-11-26 11:03:50 UTC
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.
Comment 8 Mike Kaganski 2016-11-26 11:06:03 UTC
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.
Comment 9 Mike Kaganski 2016-11-26 11:07:49 UTC
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.
Comment 10 Khaled Hosny 2016-11-26 11:13:26 UTC
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.
Comment 11 Mike Kaganski 2016-11-26 14:44:39 UTC
(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?
Comment 12 Khaled Hosny 2016-11-26 15:18:30 UTC
I guess so, though to be honest I’m not 100% sure it will fix this issue.
Comment 13 Mike Kaganski 2016-11-28 10:35:14 UTC
As the problem seems to impair usage of LO by users with poor eyesight, I raise the importance of this bug.
Comment 14 Adolfo Jayme 2016-11-28 14:22:33 UTC
*** Bug 104223 has been marked as a duplicate of this bug. ***
Comment 15 Mike Kaganski 2016-12-11 10:46:49 UTC
*** Bug 104575 has been marked as a duplicate of this bug. ***
Comment 16 Mike Kaganski 2016-12-20 00:08:29 UTC
Created attachment 129796 [details]
Screenshot of menu with HarfBuzz and https://gerrit.libreoffice.org/32211 applied
Comment 17 Khaled Hosny 2016-12-20 00:29:21 UTC
*** Bug 104738 has been marked as a duplicate of this bug. ***
Comment 18 Commit Notification 2016-12-20 05:16:38 UTC
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.
Comment 19 Commit Notification 2016-12-20 09:24:57 UTC
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.