Created attachment 111718 [details] Text antialiasing produces uneven strokes thickness in Krita 4.0 krita-4.1.0-pre-alpha-ddc6882-x86_64.appimage Text antialiasing produces uneven strokes thickness in Krita 4.0. In this attachment you can clearly see how the letter "L" is wider, while the horizontal stroke in the letter "e" is barely visible. Is it a hinting problem? Or is it caused by sub-pixel/greyscale antialising style? Krita's approach is tailor towards ordinary screen UI text display but not good for used with artwork. For typography task, GIMP's approach is faithful to the font's original design and thus preferable.
Hi, Tyson! Could you please provide with two files, from Gimp and from Krita? I cannot reproduce the problem without it... The only thing I see is that Gimp uses a different resolution for fonts...
Created attachment 111802 [details] Screenshot Gimp vs Krita Here is what I have locally
Created attachment 111808 [details] GIMP vs Krita text rendering in XCF
Created attachment 111809 [details] GIMP vs Krita text rendering in KRA
There are a few factors involved about Krita's text rendering problem: 1) Font/background colors and subpixel antialiasing 2) Krita's way of handing font size against dpi (or what ever reference it uses) 3) Krita's way of handing hinting First of all, I noticed that when text in Krita has a non-grey color, it often looks weird over a grey-color background. This probably has something to do with text antialiasing method. GIMP probably use "Subpixel" method which allows subpixels produced by antialiasing interpolation to have color/transparency. Krita on the other hand, uses the "Grayscale" method. It makes the subpixels looks disjointed with the main color and closer to the background color, therefore the final result look uneven to human perception. The particular example I included can be considered to be the extreme situation. Secondary, a same font size in Krita and GIMP produces different actual font size (both document are 640x480, 72dpi). A) I don't know what Krita's font size unit is -- in my .kra file it is "9", but in SVG it says "16pt". But "9" and "16pt" in Krita matches the size of 12px in GIMP. I don't know which is more correct, but at least Krita's font size is proportional relative to the canvas size, which is very confusing and I might need to file another BUG report just for that. Thirdly, hinting changes how freetype forces the letters into screen pixels. It has the following values: none, slight, medium, full. It might be useful for screen UI text but wrong for everything else. Krita might be using medium, which distorts the font's original shapes, and this effect is further worsened by greyscale antialiasing creating a very weird result under certain circumstances.
The font I used in the examples is "Days One". It's a free font licensed under OFL. You can get it from: https://fonts.google.com/specimen/Days+One https://www.dafont.com/days.font And typo in comment 5: *handing >> handling
Created attachment 111821 [details] GIMP's Hinting method adjustment I think if we can implement something like GIMP's Hinting method control then it would be perfect for everyone. This issue probably has something to do with freetype's subpixel and hinting mechanism, the following information might be helpful: https://www.freetype.org/autohinting/hinter.html https://www.freetype.org/freetype2/docs/text-rendering-general.html https://wiki.archlinux.org/index.php/font_configuration
@Tyson could you please see if the first problem (weird "greyscale" anti-aliasing) goes away if you select the text in Krita using the Select Shapes Tool, go to Tool Options and to the "Stroke" tab, and then select "None" ("No Fill")? If yes, it might be a duplicate of bug 418141. (I've found a place where dpi is hardcoded but it's hardcoded to 72, so on 72dpi canvas it probably shouldn't be a problem :/ so the size/dpi issue still needs more work)
Created attachment 131511 [details] Krita 4.3 Text-Aliasing after toggling stroke in Shape Selection Tool Hi Tymond, it worked! Although that option was set to "None" by default, by switching it to "Solid" then back to "None", I was able to make the result look proper, just like what GIMP produced. This workaround is going to be big help. Thank you very much! :D
@Tyson I fixed bug 411393 already, it should be in nightly stable builds and in 4.4.0 beta. For the size against dpi - I'm gonna follow it up in bug 404011 because that was only about font size + dpi and I had to unduplicate it from bug 397616 anyway. Can you please tell me which bugs out of those three you listed are still present *except for* the issue mentioned in bug 404011?
Hi Tymond, I can confirm bug 397616 still happens, while bug 411393 is fixed (but I'm not sure I understand what that bug was about)
So to sum up: Issue 1) is fixed now and was a duplicate of bug 411393. Issue 2) is a duplicate of bug 404011, there is a MR open: https://invent.kde.org/graphics/krita/-/merge_requests/716 Issue 3) still happens. (I'm going to unassign myself).