Created attachment 156115 [details] Shows how it looks as you continue pasting smileys. First is how it looks immediately after print dialog closes. SUMMARY Printing an emoji to PDF causes the cursor and characters to be in wrong places and often not show up. Problem affects all open files and new documents until you start a new kate process. STEPS TO REPRODUCE 1. In a blank document, paste a smiley, i.e. 😊 (U+1F60A). 2. Press Ctrl+P or use menu File->Export->Print, and print the document to PDF file. OBSERVED RESULT (Resulting PDF does not actually display the smiley, but that is not the bug I'm reporting here.) After print dialog closes, cursor will have moved to middle of the smiley instead of being after it. The position (line, col) doesn't change, but the displayed position does. If you continue pasting smileys, only every 4th smiley appears, and the cursor advances slowly. The characters are "there" in theory (you could save them to a file), but not all of them show up. At first, I thought it was just superimposing them, but if you're pasting them with various text in front, it's still only every 4th smiley that appears, however it might not show any until the 3rd. This is reproducible, but I've seen some variation, e.g. 2 of every 4 show up, but so overlapped they almost look like one. Also, if before you printed the smiley, you had another open document with a string of smileys, after the print dialog closes, these will all show up, but extremely overlapped into one. EXPECTED RESULT Printing to PDF should not corrupt the behavior of Kate. SOFTWARE/OS VERSIONS Kubuntu 22.10 Kate 22.08.2 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION In the screenshots to follow, it may appear I have more characters entered than I do, judging from the line:column indicator in the status bar. This is only because of bug 465305. If you count each smiley twice, it all adds up, e.g. cursor starts at 1, add "foobar" (6) and seven smileys (14) to get cursor at column 21.
Created attachment 156116 [details] screenshot showing only 1 of 7 entered emojis
Created attachment 156117 [details] screenshot of smileys in a document before print took place vs after Smileys that existed in a document before the print operation all show, but stacked up.
Created attachment 156118 [details] screenshots showing collapse as cursor moves to lines of existing smileys Neglected to mention that a string of pre-existing smileys does not collapse on top of each other until you move your cursor onto the line containing them. (If your cursor was already there, it will seem immediate.) You don't have to move it into the range containing them, just anywhere in that line. This can be the document you print, or it can be open alongside the one you print.
The smileys are ok for me with the current version but other strange stuff happens like the theme is altered...
Git commit 786fc1c139e56d9e143b1a9a707e28527f1eafd1 by Christoph Cullmann. Committed on 13/09/2024 at 18:35. Pushed by cullmann into branch 'master'. ensure modify the renderer that is used for printing instead of altering the renderer of the view we do want to print Related: bug 488605, bug 487081, bug 483550 M +7 -7 src/printing/printpainter.cpp https://invent.kde.org/frameworks/ktexteditor/-/commit/786fc1c139e56d9e143b1a9a707e28527f1eafd1