<table><tr><td style="">rkflx added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D6695" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D6695#136126" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;" rel="noreferrer">D6695#136126</a>, <a href="https://phabricator.kde.org/p/dhaumann/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;" rel="noreferrer">@dhaumann</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"></div>
</blockquote>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>(we have to fight issues like that in katepart in quite ugly ways)</p></blockquote>
<p>Any links for that?</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>[...] 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.</p></blockquote>
<p>+1 on being pragmatic and fixing Okular right now (but I'll probably alter the workaround slightly or add a comment at least)</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p><a href="https://phabricator.kde.org/p/rkflx/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;" rel="noreferrer">@rkflx</a> 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...</p></blockquote>
<p>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:</p>
<ul class="remarkup-list">
<li class="remarkup-list-item">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)</li>
<li class="remarkup-list-item"><tt style="background: #ebebeb; font-size: 13px;">width()</tt> instead of <tt style="background: #ebebeb; font-size: 13px;">boundingRect(text).width()</tt> 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)</li>
<li class="remarkup-list-item"><tt style="background: #ebebeb; font-size: 13px;">boundingBox(QRect(), 0, text)</tt> does fix it, but might be slower and even worse for other font sizes (behaves wonky in my tests)</li>
<li class="remarkup-list-item"><tt style="background: #ebebeb; font-size: 13px;">width()</tt>, <tt style="background: #ebebeb; font-size: 13px;">boundingBox()</tt> and <tt style="background: #ebebeb; font-size: 13px;">boundingBox(QRect)</tt> 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)</li>
<li class="remarkup-list-item">contradictions as well as omissions in Qt API docs (coordinate systems, expected behaviour, recommendations)</li>
<li class="remarkup-list-item">some of the problems only happen with hinting styles "none" and "slight" on linux, fine on windows and with "medium" and "full" on linux</li>
<li class="remarkup-list-item">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</li>
<li class="remarkup-list-item">probably due to adding support for horizontal subpixel <em>hinting</em>, according to similar Qt bugs</li>
<li class="remarkup-list-item">maybe even multiple issues spread all over Okular/Qt/HarfBuzz/Font</li>
<li class="remarkup-list-item">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)</li>
<li class="remarkup-list-item">Noto from upstream git master also affected</li>
</ul>
<p>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.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R223 Okular</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D6695" rel="noreferrer">https://phabricator.kde.org/D6695</a></div></div><br /><div><strong>To: </strong>rkflx, Okular<br /><strong>Cc: </strong>dhaumann, aacid<br /></div>