Fix text labels in sidebar occasionally rendering cut off
AbandonedPublic

Authored by rkflx on Jul 14 2017, 7:10 AM.

Details

Reviewers
None
Group Reviewers
Okular
Summary

For some combinations of font and font size, text labels in the sidebar
are rendered incorrectly, i.e. the right and left border is cut off.
This is a problem internal to the text label and not related to the
containing widget, as this even occurs when a wider text label above or
below still renders fine at the same horizontal position.

This fix is adapted from a similar fix to plasmate in R855:f3d78281.

Test Plan

Use default fonts, change application language to Dutch. Compare text
rendering of sidebar labels before and after fix.

BeforeAfter

Diff Detail

Repository
R223 Okular
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
rkflx created this revision.Jul 14 2017, 7:10 AM
Restricted Application added a project: Okular. · View Herald TranscriptJul 14 2017, 7:10 AM
rkflx edited the test plan for this revision. (Show Details)Jul 14 2017, 7:14 AM
aacid added a subscriber: aacid.Jul 24 2017, 2:43 PM

If QFontMetrics is failing for some font, we either need to fix the font itself or QFontMetrics, workarounding it in every single application doesn't seem like a good idea.

rkflx planned changes to this revision.Jul 30 2017, 6:43 PM

With my Kate hat on I have to add that some fonts are quite broken, i.e. it may very well be that QFontMetrics has no chance in ever always returning accurate metrics (we have to fight issues like that in katepart in quite ugly ways). That said, this patch fixes a problem now by tweaking the paddling left and right. Since this is about 10 pixels in total, I would say this workaround is better than the graphical artifacts we otherwise get.

A proper fix in Qt (or maybe even in the font or similar) is certainly better, but unlikely to happen soon. With this in mind, the patch looks good to me.

In any case, someone else should decide whether this solution is ok, or whether there is a better fix in a realistic timeframe.

@rkflx What you could try is to make a small test that shows this issue. Maybe this only appears with certain fonts at certain font sizes. In case you can reproduce, you should open a Qt bug report. Maybe one already exists...

rkflx added a comment.Aug 19 2017, 1:25 PM

(we have to fight issues like that in katepart in quite ugly ways)

Any links for that?

[...] this workaround is better than the graphical artifacts we otherwise get. A proper fix in Qt (or maybe even in the font or similar) is certainly better, but unlikely to happen soon.

+1 on being pragmatic and fixing Okular right now (but I'll probably alter the workaround slightly or add a comment at least)

@rkflx What you could try is to make a small test that shows this issue. Maybe this only appears with certain fonts at certain font sizes. In case you can reproduce, you should open a Qt bug report. Maybe one already exists...

I'm on it (on and off since three weeks already, currently deep in Qt glyph stuff) with a whole matrix of testcases. Spoiler: It's complicated. Here is what I got so far:

  • adding a hardcoded amount of pixels will always fix it (~5px, can be bigger), with no side effects (text will always fit in layout since the padding is already added before, we just cut too much off of the text when rendering)
  • width() instead of boundingRect(text).width() would fix it too (sheer luck and will probably fail for other font sizes, gives advance width instead of dimensional width, i.e. the wrong thing to use according to qt docs)
  • boundingBox(QRect(), 0, text) does fix it, but might be slower and even worse for other font sizes (behaves wonky in my tests)
  • width(), boundingBox() and boundingBox(QRect) differ between each other – okay in principle, but sometimes the actual numbers are totally off compared to the on-screen rendering and the difference in widths between each other is inconsistent too (none/positive/negative depending on various factors)
  • contradictions as well as omissions in Qt API docs (coordinate systems, expected behaviour, recommendations)
  • some of the problems only happen with hinting styles "none" and "slight" on linux, fine on windows and with "medium" and "full" on linux
  • multiple (but not all) fonts affected (same fonts on windows fine), but only for some sizes and (to make it even more complex) screen dpi ranges
  • probably due to adding support for horizontal subpixel hinting, according to similar Qt bugs
  • maybe even multiple issues spread all over Okular/Qt/HarfBuzz/Font
  • occurs at least in current Tumbleweed and Neon (old 16.04 base), each with Qt 5.9.1 (still need to also test older Qt)
  • Noto from upstream git master also affected

I'll work on it some more and try to clarify with Qt upstream. Somehow there must be a root cause for all of this.

rkflx abandoned this revision.Aug 24 2018, 10:47 PM
Restricted Application added a subscriber: okular-devel. · View Herald TranscriptAug 24 2018, 10:47 PM

Was this resolved, or did you give up?