As depcited in the link https://blogs.kde.org/2011/12/10/font-rendering-calligra-words the font rendering is still ugly in calligra-2.5.5 and qt-4.8.4 Reproducible: Always
Since you are using Gentoo, are you sure freetype is compiled with support for hinting? I checked here and font rendering in the document window is the same here with or without system-wide hinting enabled.
Hm, ok. I do have <pre> $ eix -e freetype [I] media-libs/freetype Available versions: (1) 1.4_pre20080316-r2 (2) 2.4.9-r1 2.4.11 (~)2.4.11-r2 {X auto-hinter bindist bzip2 debug doc fontforge infinality kpathsea nls static-libs utils ABI_X86="32 64 x32"} Installed versions: 2.4.11-r2(2)(10:21:10 03/14/13)(X bzip2 utils -auto-hinter -bindist -debug -doc -fontforge -infinality -static-libs ABI_X86="64 -32 -x32") Homepage: http://www.freetype.org/ Description: A high-quality and portable font engine </pre> So, I'll give it a try with the auto-hint USE set on enabled. En-/Disabling system wide hinting does not change ... or am I supposed to login/logout to kick KDE/XOrg settings out of mem?
Created attachment 78173 [details] LibreOffice and Calligra Sheet font rendering differences with Arial 10pt This is a screenshot of Calligra Sheet and LibreOffice both displaying the rendering of Arial 10pt.
I've added a screenshot with freetype auto-hint enabled. Things change. But not for the better. :( I've aded the versions (and USE) for the packages I think are somehow responsible: [code] # eix -e freetype ; eix -e calligra; eix -e libreoffice; eix -e qtgui [I] media-libs/freetype Available versions: (1) 1.4_pre20080316-r2 (2) 2.4.9-r1 2.4.11 (~)2.4.11-r2 {X auto-hinter bindist bzip2 debug doc fontforge infinality kpathsea nls static-libs utils ABI_X86="32 64 x32"} Installed versions: 2.4.11-r2(2)(15:39:43 03/18/13)(X bzip2 utils -auto-hinter -bindist -debug -doc -fontforge -infinality -static-libs ABI_X86="64 -32 -x32") Homepage: http://www.freetype.org/ Description: A high-quality and portable font engine [I] app-office/calligra Available versions: (4) 2.5.3^t (~)2.5.5^t **2.5.49.9999^t **9999^t {aqua attica +crypt +eigen +exif fftw +fontconfig freetds +gif glew +glib +gsf gsl +handbook +jpeg jpeg2k +kdcraw kdepim +lcms marble mysql +okular openexr opengl opengtl +pdf postgres +semantic-desktop spacenav +ssl sybase test +threads tiff +truetype word-perfect xbase +xml +xslt CALLIGRA_FEATURES="braindump flow karbon kexi krita plan sheets stage words"} Installed versions: 2.5.5(4)^t(12:01:12 03/14/13)(crypt eigen exif fontconfig gif glib gsf handbook jpeg kdcraw kdepim lcms mysql okular opengl pdf semantic-desktop ssl threads tiff truetype xml xslt -aqua -attica -fftw -freetds -glew -gsl -jpeg2k -marble -openexr -opengtl -postgres -spacenav -sybase -test -word-perfect -xbase CALLIGRA_FEATURES="braindump flow karbon kexi krita plan sheets stage words") Homepage: http://www.calligra.org/ Description: KDE Office Suite [I] app-office/libreoffice Available versions: 3.6.4.3 **3.6.9999 (~)4.0.0.3 (~)4.0.1.2 **4.0.9999 **9999-r2 {aqua binfilter binfilterdebug bluetooth +branding +cups dbus debug eds gnome gstreamer +gtk gtk3 java jemalloc kde mysql odk opengl postgres telepathy test +vba +webdav ELIBC="FreeBSD" LIBREOFFICE_EXTENSIONS="nlpsolver pdfimport presenter-console presenter-minimizer scripting-beanshell scripting-javascript wiki-publisher" PYTHON_SINGLE_TARGET="python2_5 python2_6 python2_7 python3_3" PYTHON_TARGETS="python2_5 python2_6 python2_7 python3_3"} Installed versions: 4.0.1.2(16:55:18 03/14/13)(bluetooth branding cups dbus gnome gtk gtk3 kde mysql opengl vba webdav -aqua -debug -eds -gstreamer -java -jemalloc -odk -postgres -telepathy -test ELIBC="-FreeBSD" LIBREOFFICE_EXTENSIONS="presenter-minimizer -nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python2_7 -python3_3" PYTHON_TARGETS="python2_7 -python3_3") Homepage: http://www.libreoffice.org Description: LibreOffice, a full office productivity suite. [I] dev-qt/qtgui Available versions: (4) 4.8.4-r1 {+accessibility aqua c++0x cups dbus debug egl +exceptions gif +glib gtkstyle mng nas nis pch qt3support tiff trace xinerama +xv} Installed versions: 4.8.4-r1(4)(11:51:01 02/18/13)(accessibility cups dbus exceptions gif glib mng qt3support tiff xv -aqua -c++0x -debug -egl -gtkstyle -nas -nis -pch -trace -xinerama) Homepage: http://qt-project.org/ http://qt.digia.com/ Description: The GUI module for the Qt toolkit [/code]
Rescanning my previous comment: I disabled the "auto-hinter" USE again, since the overall font rendering (e.g. thunderbird) turned out bad.
another reason why you might still see ugly fonts is if you have an exclusion range in your systemwide range of hinting. Another thing is that you show a screenshot of sheets. Sheets was never fixed. Sheets uses something different. Do the other applications also have the problem?
(In reply to comment #6) > another reason why you might still see ugly fonts is if you have an > exclusion range in your systemwide range of hinting. Hm. Nope in System Settings / Fonts / Use anti-aliasing: Enabled / Configure an exclusion range is not set. > Another thing is that you show a screenshot of sheets. Sheets was never > fixed. Sheets uses something different. Do the other applications also have > the problem? Oh, didn't know that. I thought of calligra as word, sheets, et al. and this problem is "calligra" not specific to a certain calligra component. But you're right. Word behaves different (second attachment). Though the font is sort of blurry too (but better). Huh ... what can I do? Is there a bug report to this for sheet already ... is there anything I can do to ease the situation (I really like Calligra but this is sort of show stopper; I suppose I do have good skills in C++, Qt, Git, CMake; though not in font rendering and libkde. If you can pinpoint to the sources to look at ...)
Created attachment 78235 [details] Calliga Word Arial font rendering compared to LibreOffice
Hehehe ... been around in the code for some time. Actually the problem lies somewhere deep within the guts of the flake stuff. Tried to kick KoPostscriptPaintDevice device; in sheets/ui/CellView.cpp in favor for a pure QWidget or manipulated libs/flake/KoPostscriptPaintDevice.cpp do return my real DPI instead of the hardcoded 72 ... which actually *did* change something ... but not for the better. And then ... $ find libs/flake -type f -exec file {} \; | grep text | cut -d ':' -f 1 | xargs wc -l | tail -1 68691 total nearly 69k LOC! What-a-beast to get my text rendering right, huh ... would be happy for any hint where text rendering happens in flake ...
dyle@dyle.org, I'm with you about this issue being a showstopper.
it may be a show stopper for you guys, but in general people don't have this problem. Dyle you are welcome to contact me on irc, and then we can try and work out what is causing problems for you, though i must say that on the latest screenshot the problems are not that clear. my irc nick is camillab, and i'm hanging out in the calligra channel
Ok. Challenge accepted! I don't usually hang out in IRCs, so I'll try to contact you asap. Though full-time-worker and family are quite limiting my availability. Can you hint me a link to setup the build environment? I assume I need kdelibs, flake and calligra stuff compiled locally.
http://community.kde.org/Calligra/Building and i understand about not having time - could you hint me at what time of day european time you will be able - I'm almost able to be here 24/7 except for shopping groceries etc
Created attachment 81144 [details] Comparison of fonts rendered in Calligra vs. Kate Comparison of fonts rendered in Calligra vs. Kate with RGB sub-pixel rendering and full hinting enabled on Kubuntu 13.04 (KDE 4.10|).
Camilla, Thank you for offering your time to discuss this issue. As you know, the way people perceive fonts will depend on the display or monitor used, and personal preferences. This can be a very subjective thing. However, we can look at this issue objectively: I've attached an image (http://bugsfiles.kde.org/attachment.cgi?id=81144) that compares Calligra Words with Kate. At the normal viewing resolution, some may perceive that the fonts shown in Calligra look the same as fonts shown in Kate. However, when we zoom into the screen-shot, we can objectively see the difference... The attached image shows how, on my machine, Calligra Words has thicker fuzzier fonts; you should be able to notice, in the zoomed-in version of DejaVu Sans, the characters are thicker and have thicker colored fringes compared to the sharp, thinner characters rendered inKate. If you have the time, please try this: Make sure ~/.fonts.conf does not exist, so it does not override your System Settings. In System Settings, select RGB sub-pixel rendering, uncheck Exclude range, and set Hinting style to full. Then type some text into Kate. Type the same text into Calligra. Take a screen shot of both. Open the screen shot image and zoom in at least 300% or more. In the zoomed-in view, the way the text is drawn in both Kate and Calligra should *not* look different (even on your machine, where you don't perceive a difference at normal resolutions). Ultimately, I think the real issue is, why does Calligra do *different* font hinting than other parts of KDE?
Well we specifically turn of hinting because it doesn't work for us for two reasons: 1) Qt messes it up when zooming in and out, and not it's not a solution to try and fix that, as that would men the entire say 900 page document needs to be relayouted for every minuscule change in zoom 2) it doesn't make sence for rotated text anyway which text can do. So do not compare to kate with full hinting. We specifically turn hinting off
Turning this hinting on in the code again does change the representation. BTW: thougt this Qt rendering issue is solved in Qt 4.8.2 and greater ... me has 4.8.4. But still: the rendering remains sort of blury and slugish compared to the LibroOffice visual of the very same document and font. Does Calligra go for a different font rendering than KDE and yet even LibreOffice? Why so? ... and what is this flake thing in the guts of Calligra? Does it have anything to do with this request here? Camilla Boemann <cbo@boemann.dk> wrote: >https://bugs.kde.org/show_bug.cgi?id=316966 > >--- Comment #16 from Camilla Boemann <cbo@boemann.dk> --- >Well we specifically turn of hinting because it doesn't work for us for >two >reasons: > >1) Qt messes it up when zooming in and out, and not it's not a solution >to try >and fix that, as that would men the entire say 900 page document needs >to be >relayouted for every minuscule change in zoom > >2) it doesn't make sence for rotated text anyway which text can do. > >So do not compare to kate with full hinting. We specifically turn >hinting off > >-- >You are receiving this mail because: >You reported the bug.
flake is the library responsible of the shapes. But it has nothing to do with text. And I'm not sure what issue you are talking about being solved - just because you don't see it doesn't mean other people will not see it . I have no idea what technology LibreOffice uses and it's irrelevant to know. And I actually don't even know what we use because it buried in Qt. I can tell that we use the same as the rest of KDE, except for the fact that we turn off hinting, and you probably should turn off subpixel rendering as if that is picked up by qt for Caliigra as well then it will make the fonts look blurry.
(In reply to comment #18) > flake is the library responsible of the shapes. But it has nothing to do > with text. Ok. > And I'm not sure what issue you are talking about being solved - just > because you don't see it doesn't mean other people will not see it . I found some bug requests here on bugs.kde.org like this one: https://bugs.kde.org/show_bug.cgi?id=291427#c23 which states "closed". Then again: https://bugreports.qt-project.org/browse/QTBUG-23372 is still open. > I have no idea what technology LibreOffice uses and it's irrelevant to know. > And I actually don't even know what we use because it buried in Qt. I can > tell that we use the same as the rest of KDE, except for the fact that we > turn off hinting, and you probably should turn off subpixel rendering as if > that is picked up by qt for Caliigra as well then it will make the fonts > look blurry. Well, I doubt that. I'll attach a screenshot of 4 things: 1. My KDE's SystemSettings Font subpixel rendering hint settings. 2. A LibreOffice showing Arial 10pt 100% 3. A Calligra showing Arial 10pt 100% ... this version has pure hinting enabled. I kicked the source code line disabling this. 4. Pure Qt 4.8.4 showing Arial 10pt (at 100%) All these fonts are different! Having the pure Qt version looking best and Calligra version worst (but this is a subjective, personal opinion). Nevertheless: Calligra *does* something different than Qt. And not for the better. (screenshot coming up ...)
Created attachment 81154 [details] Arial 10pt in LibreOffice, Calligra and pure Qt. Note: the source code for the pure Qt sample is shown on the screenshot itself.
This just shows that you like full hinting, but well you can't have that in calligra, and yes calligra does do something special which is why we forcefully disable full hinting or i looks bad as you say. I take this as case solved - closing as invalid because there are no better reasons to choose from
Created attachment 81174 [details] Arial 10pt in LibreOffice, Calligra and pure Qt - full hinting disabkled Snapshot of LibreOffice Writer, Calligra Words and pure Qt 4.8.4 - full hinting disabled.
(In reply to comment #21) > This just shows that you like full hinting, but well you can't have that in > calligra, and yes calligra does do something special which is why we > forcefully disable full hinting or i looks bad as you say. Nope. Hinting is basically irrelevant to this bus request. Indeed, I started this bug request with no hinting enabled. This is *not* the bug. ... and this "calligra does something special" besides turning hinting off is creating the bad visuals. Qt per se does render the fonts just fine. Even excellent. In the screenshot I just added, hinting is turned off. Now LibreOffice and Qt look totally the same. Calligra does not. It is different. And not for the better. It may be true, that this tweak is needed for some performance reasons. But then with respect to the visual glitches it remains still an open bug. Which just can't be closed now. > I take this as case solved - closing as invalid because there are no better > reasons to choose from Reopening bug. It is not solved.
yes it's different - i just said so, but there is no way around that - and we can't have open bugs for things that are out of our control you latest screenshot doesn't show hinting disabled in the qt example - at least not according to the systemsettings and btw the words you run is not the one you build yourself - i can tell i's still the old ui, so I'm 100% sure of that - and thus you never enabled hinting
(In reply to comment #24) > yes it's different - i just said so, but there is no way around that - and > we can't have open bugs for things that are out of our control Uhm, what is then the "... and yes calligra does do something special"? > you latest screenshot doesn't show hinting disabled in the qt example - at > least not according to the systemsettings Ok. Yet another snapshot. "Really" no hinting ... =) Still: Qt and LibreOffice to render quite the same with pure Qt even being best. Again: Calligra looks just bad. > and btw the words you run is not the one you build yourself - i can tell i's > still the old ui, so I'm 100% sure of that - and thus you never enabled > hinting This is true for the last 2 screenshots, yes. But not for the one before. I just didn't not fix the PATH and I wanted to disable hinting anyway.
Created attachment 81176 [details] Really no hinting at all.
the special thing we do is tell qt that the display is always 72 dpi, and we then zoom in. your qt example uses the actual dpi and no zooming but since we can't just not have zooming we have to do it like we do, another thing is subpixel positioning. We cant have that (again because of supporting zooming) and you have also disabled that in your qt example. But due to the difference in dpi it will look different. Because we need to have zooming there will will be a sweet spot zooming (76,5% on your display, but different on other displays) where the font will look like the designer intended. The only thing we can maybe do is say double the font dpi to 144. It will be a lot of work and it will not solve the underlying issue (that qt can't support dpi changes on the fly, when we change zooming). Maybe you could do this experiemtn for me: two screenshots of calligra: one with 12 pt font shown at 100% and one of 24 pt font shown at 50%. hinting off in both cases naturally And also give me your opinion if there is a visual difference and which you like the better
Created attachment 81179 [details] Calligra Word with Arial 12pt at 100% and Arial 24pt at 50% 1 Screenshot with both ok? ... actually no difference. Both do look equally - uhm - unpleasant. However: rendering a font to 72 DPI and then boost it up to the real DPI, which is currently 96 DPI (or so) on my screen does give me some enlightenment. Clearly this has to look bad. It is as if one makes a tiny picture and than zooms into it to fit some margins. If this is done on an integer (opposed to a floating point) based subpixel calculation than visual artifacts are common. Ah, ok. Now I understand. Still: can't there be an option which states "[X] Prefer nice fonts (hint: this may cause severe performance issues on large documents)"? Since I really, really, really seldom do 900 pages documents. Writing letters up to 2-3 pages and documents of - let's say - 30-40 pages at max is the norm. I also seldom switch DPI and/or font hinting on the fly. All I want is a nice cool looking Calligra for my day-to-day work. And ... sorry ... eye candy does matter. If it does not attract me (visually) I won't be using it.
unfortunately no, it's not so easy to offer such an option. we depend on the cuurent fixed dpi in a lot of places so it would be a lot of work, and besides we would have to disable zooming. The application would effectively freeze up if the user tried to change zoom
A pity ... https://bugreports.qt-project.org/browse/QTBUG-10615?focusedCommentId=120984&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-120984 ... so "solution" 1 is used. I see. So Calligra is then not an option. Sorry, but this is still a show-stopper and for me an open bug. It is not resolved. Is this different in the Qt 5 series?
I'm sorry you feel that way, but cannot really blame you I'm not quite sure if qt5 fixes it - they have some new text rendering, but if it works it would also mean some rewrite on our part to use the new functionality. btw, I don't disagree it's a problem, it's just that the bugtracker is a work tool for me and having issues in here that can't be solved just makes it harder for us to find the bugs that we can fix.
This also happens on openSuse ( 12.3 and KDE 4.10.5 ) so it isn't a unique problem I don't understand why it's a 'wont fix' Does it work anywhere? If so, what is that distro doing with font rendering that makes it works ? regards Mal
I'll try to summarize the situation: 1. Callligra Devs have a problem when rendering the font normally. They think it is a bug in Qt and the way the framework handles font rendering. 2. Letting Qt do font rendering on a normal way will turn calligra apps unresponsive, since some calculations are very cost intensive. 3. In order to "fix" this situation, the calligra devs decided to render all fonts at 75 dpi. 4. This will look ok, as long as you have a screen which closely matches this resolution. But as screen resolutions goes up, having more and more DPI, you'll encounter artifacts and visual glitches. Apple's retina display (going up to 300 DPI) kills this. It's like making a foto at very close range and then scale it up to meet the current display. 5. Calligra devs insist this to be a bug in the Qt framework and essentially "sorry, but not my problem". So in order not to have that much bug reports in their Inbox which are not *their* bugs anyway the status is: Resolved - Won't fix. I personally do not know what is the bug in the Qt framework nor which heavy calculation calligra is doing. I've yet to see some code snippets demonstrating the problem. Anyway, you won't have a problem, if you go for a 74 DPI of your system. This'll work. [but it will look - uhm - very "retro"]
So if it's in QT why is it only Calligra that looks terrible, why not pretty much all of KDE? I cannot believe the devs use 640x480 screens ;-) so either they think big and fuzzy is actually nice or they are not seeing what we see. Then the question is, what does it look like on their screens at a resolution that is vaguely in the 21st century. If it looks nice what are they doing that we are not ?? regards Mal
(In reply to comment #34) > So if it's in QT why is it only Calligra that looks terrible, why not > pretty much all of KDE? Mhm, because most of KDE relies on the Qt rendering and does no rescaling of fonts, I guess. In calligra you can have documents created with a lot of different font sizes and start to zoom in and out at will. This is sure different to ... uh ... let's say: kate. Or kopete. You don't do wired font things there. > I cannot believe the devs use 640x480 screens ;-) so either they think > big and fuzzy is actually nice or they are not seeing what we see. Then > the question is, what does it look like on their screens at a resolution that > is vaguely in the 21st century. If it looks nice what are they doing that > we are not ?? Donnow. I submitted some screenshots to this issue in the past. I didn't saw one of the calligra devs for comparison. KR, Dyle
Mal, click on https://bugs.kde.org/attachment.cgi?id=81154 There you see how Qt does is, how LibreOffice does it and Callilgra does it. I personally find myself in favor of the Qt representation. But this is done with full hinting turned on ... giving Calligra Devs headaches. KR, Dyle
I just wanted to add that I have this issue too, and I also consider it a showstopper. After all, the most important thing a program like Words does is render text, and if that looks ugly that's really a huge problem. Out of interest, did you actually try to re-layout the document on zoom changes? If it would take say a second for an average-sized document, I personally would definitely prefer that over the font rendering issue. I'm not blaming anyone, I just really hope Calligra becomes a success in the future and I see this issue as a major point blocking its path.
This is also a showstopper for me. It's a pity because calligra seems nice...
This is really very sad, at least you should admit this is a problem and set it to a high priority. Any chances this will improve when porting to qt5 /kf5?
As in http://blog.davidedmundson.co.uk/blog/kde_apps_high_dpi "This upcoming release of Qt (5.4) brings us everything we need to support High DPI in our applications. It's not going to be useful for end users just now, but this is a time where we need each and every developer to start getting interested and making sure their applications are ready." Is there a remedy on the horizon?
Au contraire. With DPI increasing, developers are less interested to make the font rendering pixel-perfect.