Start Words, and create a new document using any template. Type some text. It is rendered without any anti-aliasing. Repeatedly try to zoom in. There won't be any anti-aliasing until zoom factor is over 300%, at which point fonts would look smooth. All other KDE/GTK applications have no such problem. Reproducible: Always Actual Results: Font anti-aliasing works in Words. Expected Results: Font anti-aliasing does not work in Words.
It works just fine. Are you sure you are not talking about hinting plus you have qt less than 4.8
I've got KDE 4.8.2 and libqt 4.8.1. Yesterday also upgraded to KDE 4.8.3 with same results. And it does not "work just fine".
Created attachment 70946 [details] screenshot showing anti-aliased text Please check the attached screenshot. The text is antialiased. You could attach a screenshot of words showing your problem, but I suspect a local configuration issue.
Yes by all means, attach a screenshot. We can always reopen this bug, if it turns out it's a real problem and not just a local issue.
Created attachment 70961 [details] Bad font rendering Here you go - two windows - one at default zoom and another at 302% zoom
Created attachment 70962 [details] Words vs OpenOffice Example of proper font smoothing by OpenOffice.
I must admit it does look bad, but I still think it's a local or distribution problem - like the dpi info of your screen not set, or no scalable fonts installed. Can please check that your dpi info is correct
> It is rendered without any anti-aliasing. Look at the text in menus etc. You configured KDE to not use text anti-aliasing.
$ xdpyinfo| grep reso resolution: 133x133 dots per inch
Created attachment 70969 [details] KDE font settings As you can see anti-aliasing is enabled. Only font sizes below 7pt are excluded. As I recall, the default document template in Words uses Arial 12pt.
Also, if you look at the window title bar font - it uses anti-aliasing. So I strongly doubt that my KDE font settings are at fault here.
try see if turning off the exclusion below 7pt off helps You cannot compare pt numbers so it may make a difference. Especially since you have a high dpi screen (well higher than mine)
yes that must be it - i just tried excluding a wide range and then I get no antialiasing either. About pt numbers in words versus the kde dialog - there is a conversion factor: your dpi / 72= 133 / 72 roughly a factor 2 meaning when you say below 7pt in words that means below 14 pt. But for zooming of text to work you need to have no exclusion range at all. other wise it will still be visible when zoomed in Unfortunately qt doesn't allow us to turn off antialiasing exclusion ranging
Where does "72" come from into the equation? How strange. Are you implying that Words (and other Calligra apps) interpret KDE font antialiasing settings differently to all other applications? This makes no sense, sorry.
72 comes from the fact that there are 72 pt per inch. The way Qt works is it does it's layout in pixels (make sense as it looks nicer), however it breaks down when you want to zoom in and out, so we have to force the same dpi upon Qt all the time and we have chosen 72 as that corresponds to pt Everything we do internally also happens in pt so it works together. That works nicely except for this antialiasing setting. We actually force antialiasing on, but i guess we can't control the exceptions. I wasn't aware of this. So it's a limitation in qt, however i suggest you just don't use the exclusion range, as I don't foresee this being implemented in qt
I see. This explains why only Words is subject to this behaviour. IMHO, it is unreasonable to require users to not exclude a range from anti-aliasing because that's the only option that results in clear fonts at small sizes. This is a very commonly used option which is mentioned in pretty much any guide on how to get good-looking fonts on Linux.
yes. Feel free to open a bug against Qt
IMHO, it is your - developer of an application that exhibits a problem - responsibility, not mine - user of the application - to raise bugs against a 3rd party library you chose to build the application on, link them to the defect reported against your app, so other poor sods who encounter the same issue don't have to waste their and your time over and over again.
Well I don't disagree it should be fixed and ultimately I will have to do some things too. But please understand I'm very busy with fixing a lot of other bugs. You have done a great thing by reporting this bug. I've learned something, so thank you very much. But I also know that I wil not have the time to follow up on this. This is free software where nothing happens unless someone with an itch steps up and does the work. So I ask you to please take it to the next level and drive this bug to being fixed.