I get gaps in font rendering at some sizes. The letters in which the gaps occur vary depending on the sizes. Some sizes are OK. E.g. times new roman 12 point at 95%, which is shown in the accompanying link. The image in the http link included is from Libre Office but I see the same thing in other apps. I did not have this problem on the same machine with open office when I was running Ubuntu netbook remix, which I believe is based on gnome. FYI: I am running an EEE pc with Mint Linux 14. Reproducible: Always Steps to Reproduce: One example: 1. Type some text containing the letter e in Libre Office (this will probably happen in any app that can render fonts in different sizes and zooms, but I don't have any others handy that I know of) 2. times new roman 12 point 3. zoom to 95% Actual Results: e's have gaps in them Expected Results: They should not have gaps
I am not seeing the bug using Virtual box on my windows machine, using KDE 4.7.4 I suspect the hardware (Asus EEE netbook 1000HD) may have something to do with it. It also seems like the font rendering improved with the last Mint upgrade, which included massive KDE updates. But I can't be sure. I never saw the issue (over several years) with the Ubuntu netbook remix, which is probably based on Gnome. By the way, I do have antialiasing turned on, with full hinting. None of the font settings seemed to help.
LibreOffice is no KDE application. Do the fonts look bad only in LibreOffice, or in all applications?
Yes, i see the broken fonts in other applications, but it is harder to control, hence more difficult to come up with a repeatable failure. Is there a KDE application that will let me test fonts at different sizes and zooms? I do not see the broken fonts in Libre under other windowing systems (including Gnome) so I'm pretty sure this is at least partly a KDE problem, or some problem with the interaction between Libre and KDE using this hardware. I would hate to have to switch to gnome. Thanks, -= miles =-
> Is there a KDE application that will let me test fonts at different sizes and zooms? System Settings > Application Appearance > Fonts allows you to bring up a font chooser, where you can enter any text and font size. Just be sure to cancel unwanted changes. Please indicate if fonts there are also broken, ideally with a screen shot.
Created attachment 78905 [details] broken font example
Created attachment 78906 [details] broken font example
I tried the case that I outline above (Times new roman, 12 point * .95 = 11.4 point) and did not see the same effect. So apparently this is partly a Libre problem. However, I did find a couple of examples which I just uploaded. (I think the screen shots are sufficient to replicate). I also have suspicions about this particular hardware. I will follow up with Libre on this. Thanks, -= miles =-
Comment on attachment 78905 [details] broken font example The "QuickType II" screen shot seems to indicate the font has bad hinting. Try changing KDE font settings to "slight" hinting.
This must be a quirk of the Asus eeePC hardware and the way the font renderers or X11 drivers use it. I get a similar problem when working in large print in all non-KDE applications including Terminal, WINE, ... on Ubuntu 11.10 (without KDE) on an Asus eeePC 900. About the only application that doesn't do it is Wenlin running on WINE. Wenlin does not use any text output API; it does its own font rendering and sends bitmaps to the screen. Everything else uses the system to render text and there lies the bug (somewhere). About 15% of letters are affected, apparently at random. Once a particular letter is affected (say, lower-case 'n'), that same letter will take the exact same broken form next time it's displayed. So the broken form must be being stored in some kind of glyph cache. As I was running the Compiz window manager, I wanted to try turning off OpenGL and/or compositing, but when I ran "ccsm" to do so, ccsm segfaulted whenever I tried to change any of the settings. (Reducing my DPI setting before running ccsm does not fix this.) However, I can confirm that the problem does not go away when I switch to the Openbox window manager (which is not compositing). As this isn't a KDE problem, would it be possible to somehow "move" this bug report into the correct forum? (but where would that be? I'm suspecting Xft but I could be wrong)
Do you remember exactly which version of Ubuntu Network Remix you were running? (It could be anything between 8.04 and 10.10; it was merged into the desktop edition from 11.04.) There might be something in its default settings that fixes the problem; if we knew which version you had, we could try installing it in a VirtualBox and looking at the settings. (Or it might just be that it uses software that predates the introduction of the bug. However it might still be useful knowing which version it was; those who have eeePCs which are not connected to the Internet can at least run that old version if they wish.)
Just found a RedHat bug report of the same problem: https://bugzilla.redhat.com/show_bug.cgi?id=495323 (that Thinkpad and my Eee both use the same Intel 915GM graphics chipset). This report mentions a workaround of disabling KMS (kernel mode switching), which can be done by adding "nomodeset" as a kernel parameter, for example by editing /etc/default/grub and adding nomodeset to the GRUB_CMDLINE_LINUX_DEFAULT setting (then run "grub-mkconfig -o /boot/grub/grub.cfg" and reboot). I just did this on an Eee and the broken fonts problem disappeared, but I got an 800x600 mode, which looks rather horizontally "stretched" on the eeePC's 1024x600 display. (The report also mentions possible fixes in various 2.6 kernel versions, but I'm using a kernel that identifies itself as 3.0.0-32-generic and still have the problem.) Fonts do seem to be much better (but not completely fixed) when I disable the swap partition (by commenting out the swap line in /etc/fstab and rebooting). This is in response to a comment in the above RedHat report which mentioned forcing a lot of swap so as to reproduce the bug more reliably. The logical conclusion of this is that DISABLING swap is a possible workaround. I have 1G of RAM on this eeePC, which is more than enough for what I want to do with it, so I don't really need swap. I don't understand why having swap makes the glyph corruption problem worse, but I'm happy to do without swap if it makes it better. (Note that glyph corruption is still there even without swap, but it's much less severe. It might still be made a little bit worse after resuming from suspend to RAM though.)
Cannot reproduce with KDE Plasma 5.13 and KDE Frameworks 5.49. Can you?