D6695: Fix text labels in sidebar occasionally rendering cut off

[Henrik Fehlauer]

rkflx added a comment.


  In https://phabricator.kde.org/D6695#136126, @dhaumann wrote:
  
  >
  
  
  
  
  > (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.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D6695

To: rkflx, #okular
Cc: dhaumann, aacid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20170819/8b38a105/attachment.html>