| Summary: | ktexteditor: lineheight regression | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-ktexteditor | Reporter: | RJVB <rjvbertin> |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | christoph, dshishir, efanzh, glyphimor, l12436.tw, mister.freeman, nate, postix, sdicke, t123yh, tom.schoeps |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | All | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=418620 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
sample text containing Unicode emoji
incorrect lineheight due to #ce4194b5bc2e13a6f02d5d03e7b003fa0eba650b correct rendering, after reverting #ce4194b5bc2e13a6f02d5d03e7b003fa0eba650b 118436: correct rendering, after reverting #ce4194b5bc2e13a6f02d5d03e7b003fa0eba650b both, with shared line background |
||
Created attachment 118435 [details]
incorrect lineheight due to #ce4194b5bc2e13a6f02d5d03e7b003fa0eba650b
The fallback font used here is Segoe UI Symbol
Created attachment 118436 [details]
correct rendering, after reverting #ce4194b5bc2e13a6f02d5d03e7b003fa0eba650b
same fallback font in case it wasn't obvious ;)
Btw, I don't think this has anything to do with a fallback-font. It's simply that some glyphs force other line heights, and in that case we always lose the game. The issue is indeed with different fonts getting substituted based on script coverage. Qt only uses the same point size for the fallback fonts, but each font itself is free to use any (pixel) size for the requested point size, mostly depending on the amount of leading the designer felt required. It seems that both uploaded images are the same and both show the incorrect state. I couldn't reproduce this here since the emojis fit into the line with the font that is used here. I am wondering whether the emojis already extended beyond the line height before, but that was hidden by the workaround with the second drawing pass that was applied there. To determine this, it might perhaps be helpful to have a screenshot of the correct state in which the cursor is in one of the lines with an emoji (since this line's background should be of a different color then, making the line height visible). Created attachment 118449 [details]
118436: correct rendering, after reverting #ce4194b5bc2e13a6f02d5d03e7b003fa0eba650b
Thanks for adding the image. Comparing the correct and the incorrect version in GIMP, it seems that the patch causes no difference in line height for the font used here. So, the problem must come from the other part of the change: the removal of the second drawing pass workaround. Created attachment 118450 [details]
both, with shared line background
Good idea the check the shaded line background mode. I don't know if this more really paints the entre lineheight (or rather, the text height) but it does show a little bit better what's going on. In particular pasting one of the emojis on a line that didn't have one yet:
- shows the line being pushed down (with the reverted commit) as if the emoji is higher
- shows the shaded background doesn't change (much) in height.
An additional test would be to use Segoe UI Symbol as the editor font, but that's not a monospaced font and I don't know to what extend Kate can handle variable-width fonts.
See latest comments in https://phabricator.kde.org/D19283 If you use proper fonts, that works. *** Bug 404713 has been marked as a duplicate of this bug. *** *** Bug 406432 has been marked as a duplicate of this bug. *** *** Bug 390665 has been marked as a duplicate of this bug. *** *** Bug 385798 has been marked as a duplicate of this bug. *** *** Bug 387428 has been marked as a duplicate of this bug. *** *** Bug 412095 has been marked as a duplicate of this bug. *** For me this works, if the font is chosen properly. If you choose a font that will lead to some fallback for some characters and these have different heights, this fails. If somebody has a proper fix for that case that doesn't lead to rendering artifacts between lines, this can be re-opened. Otherwise I consider this fixed. *** Bug 415036 has been marked as a duplicate of this bug. *** *** Bug 414408 has been marked as a duplicate of this bug. *** There's another patch proposed: https://phabricator.kde.org/D25339 |
Created attachment 118434 [details] sample text containing Unicode emoji SUMMARY Commit #ce4194b5bc2e13a6f02d5d03e7b003fa0eba650b introduced a regression when text contains certain Unicode glyphs that cause Qt to use a fallback (= different) font. This is platform independent. STEPS TO REPRODUCE 1. open the attached example document which contains emoji OBSERVED RESULT Incorrect lineheight for lines that contain the emoji EXPECTED RESULT Correct lineheight. SOFTWARE/OS VERSIONS KDE Frameworks Version: KTextEditor master Qt Version: 5.9.7 ADDITIONAL INFORMATION