| Summary: | Click and drag with text tools returns an empty vector layer if the active color is not dark enough (nightly build e528a61e) | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Regis <regis> |
| Component: | Tool/Text | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bbond2343, griffinvalley |
| Priority: | NOR | ||
| Version First Reported In: | nightly build (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/-/commit/79b6fe0120373e6791ef1e5bd8dbb3784fcd38bd | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
|
Description
Regis
2025-05-26 13:14:04 UTC
Hi, I can't reproduce this. Can you give me more information? 1. Which colors cause this? I have personally tried with "#99efe5", "#f4dad0" and "#d7d7d7", none of them seem to cause a crash. 2. Which font are you trying this with? Does it happen with all fonts? I tried the colors you mentioned (#99efe5, #f4dad0, #d7d7d7) and it caused the same issue. I just noticed it doesn't affect all color hues in the same manner on my side either. For example for greens, the "zone" on the color selector creating the bug is fairly smaller, but still it's there. But shades of red are especially affected on my side. For example this one: #bf3429. The font is Segoe UI (default on Windows I think). I switch to Verdana and it doesn't change a thing. I'll try a total reset of my settings by moving temporarily my resources folder to see if it helps. Update: I reset both my resources folder and the settings via the interface (Settings -> reset all settings) and the issue is still here for me. So far I had the issue on two Windows computers (one on Windows 11 Home, the other on Windows 11 Pro). A total reset of Krita didn't help. I tested the same build on my Linux install (Mint Cinnamon), and no problem here. So it might be a Windows related issue. Tomorrow, I'll try to get my hand on the last nightly that didn't have the problem on Windows, if that can help find out what changed when it started to happen. 🐛🧹 Thanks for your comment! Automatically switching the status to REPORTED so the team can perform further triage. In the future you may also do this yourself when providing needed information. Hi, I managed to test the nightly build on another Windows 11 computer (version 24H2) where there was no version of Krita installed before, and with only default settings. It seemed to work better, I could create text by click and drag with most of the colors that caused issues on my computer. But still, I could reproduce the bug with some colors, one of them being this one: #8fdf9b I created a block by click and drag with this color and the block appeared empty. If I create a block the same way but with another color that works, and then select the text and change the color to #8fdf9b, the text disappears, or worse, Krita hangs and crashes after a few seconds or minutes. I hope this helps reproduce the issue! *** Bug 514390 has been marked as a duplicate of this bug. *** Will add this note here in case it's easier to look here than go back to my report, on what I noticed when I experienced the bug. If the CYMK view is open in the specific color selector, it seems to be any color where the amount of black is 134 or less. Ok, after asking around, this bug also happens on MacOS, Windows and Android... but not Linux; the platform I'm on :/ I'll mark it as confirmed for now. So, we may have just found a fix for this: initializing the font metrics integers correctly. Freya was kind enough to help me debug this, and found that the font was offset massively off canvas, due the metrics being wrong. My suspicion is that what happened was that when we got our font metrics struct, because the values were not be initialized, they were reading the memory that was previously used by the font color and thus the font color affected the baseline offset and seemed like it would "dissapear" (it would be off-canvas). We're now initializing the font metrics properly, so this should be fixed. Please check if the next nightly fixes this! Hi, Thanks a lot for looking into this, and for the fix :) I can confirm that now it works on Windows at least, with last night's build. I just wonder about the current behavior: when creating the placeholder text, the text color defaults to black no matter the color that is set as foreground color. So if you try to edit the text that sets the foreground color back to black. Would it be possible to have the color at text creation follow the current foreground color? With the current behavior, that means that if you set your color on the selector just before you create your text, you will have to set your color again manually after selecting the text (as you may not have that color in your color history yet). Great, I'll close this then.
> I just wonder about the current behavior: when creating the placeholder text, the text color defaults to black no matter the color that is set as foreground color.
Yeah, that's a separate bug, still need to look into that.
The text-color-is-always-black is now also fixed, btw. That's awesome, thanks a lot :) Thanks so much for the fix! |