SUMMARY Inserting a newline at the beginning of the textbox creates a region in which, if new text is inserted, it lacks any of the specified attributes (font, size, color) and is rendered in the default formatting despite the settings displayed when it is selected. This text will appear in white no matter your font color. Fixing each attribute requires setting a different setting, pressing "save", and then switching it back again, which must be done separately for font, font color, and font size. Just re-selecting the intended settings without first changing leaves the broken text unchanged. STEPS TO REPRODUCE 1. Create a text box, set non-default text color, font, and font size and type some text 2. Go to the start of the text, press return 3. Insert some new text on the first line OBSERVED RESULT The new text is white in the text box regardless of current font color, and when pressing "save", the rendered text is the wrong size and wrong font EXPECTED RESULT The text should render consistently with the settings displayed in the text window when it is selected. SOFTWARE/OS VERSIONS Windows: 10
I can confirm this for 4.2.5, 4.2.6 beta-1 and the latest 4.3.0 pre-alpha appimages. I see slightly different things in terms of colour, font, etc. This does not happen if you save and close the text editor before adding the new first line, then open the text editor, add a new first line and type text on it.
Created attachment 122632 [details] Screenshot of bugged text box When I reopen the text box after saving and closing it with bugged text that I typed before a leading newline, it looks like this
Created attachment 122633 [details] screenshot of bugged text to put it in words, the text before the newline gets rendered overlapping with the rest of the text. Also, when I save the text box again after making a change, the actual text overlaps as well. This is a picture of a single text object, from saving the previously shown textbox.
To reproduce the overlapping text (or at least see the lines of text after the "bugged" text render at the wrong height) in 4.2.6: 1. In a new canvas, make a text box. 2. In the text window, make the left side of the existing text size 18, and the rest of the line poitn 36. 3. Add a newline at the start of the text box 4. On the first line, type a line or two of text (it will be in default small font) 5. press save and close the text window 6. Double-click the text to reopen the text window 7. The text should already be overlapping in the text window; do nothing and press save and close again 8. The text is now displaced and overlapping 9. Double-click the text again 10. The text is even more displaced; do nothing and press save and close 11. Now the text on the last line should have moved above the first lines of text 12. Double-click the text again 13. The newlines have vanished from the text box, but any newlines within the "broken" text that was originally typed will continue to be rendered. However, the original line of text now gets rendered to the right of the broken text. Now, finally, the text stops changing whenever you open the text box (but it's rendered in a nonsensical way).
I see that happening in the 4.2.6 appimage and the latest 4.3.0 pre-alpha appimage on Linux. This information will be useful for the developers to, hopefully, fix it.
The behavior in Linux is slightly different. If you follow the steps in comment 4, making sure to type at least 2 lines of "broken" text, what happens is that when you reopen the text box the first time, the broken small text expands to the font size of the neighboring text without changing the spacing, which results in overlapping with itself. Funnily enough, the line spacing box shows this change accurately, although it shouldn't have changed to begin with.
Sometimes I can reproduce the bug in comment 6 in windows, but I'm not sure what I did differently (except that the bugged text appeared in white when it happened). So I assume the overlapping bug can happen in linux too. Also, I noticed that when producing overlapping text with the steps described in comment 4, one of the lines of text ends up with 0% line spacing. So in either case, the bug manifests as an unpredictable change in the line spacing setting.
NOTE: the bug will not occur if before adding the new line, "SVG" tab is activated at least once.
When I activate the SVG tab before inserting the new line, the new text becomes bold.
It looks like an empty line between two lines is getting converted into SVG using "line height", so next time you open the text editor you end up with two lines with ridiculous line height instead of three lines with different font sizes. But in my case the text doesn't overlap and looks exactly the same all the time. The line thing is probably a duplicate of bug 420471 (or at least caused by the same thing). The incorrect font and font size is still preset, even after my fix to bug 411393. Note: for reference, in LibreOffice Writer text would automatically use the font and font size of the leftmost text.
I cannot reproduce this on 5.1.5 as well as 5.2.0 nightly (508d078b73). Can someone else here also confirm that this has been fixed?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!