Bug 307824

See also bug 290485.

Created attachment 74333 [details]
Screenshot

Created attachment 74941 [details]
Screenshot from http://kde.org

The problem is not only on phoronix.com, and not only with crowded spacing. The problem occurs on many sites, and mostly (IME) produces too much spacing. Too much extraneous spacing makes text difficult to read, as well as crowded spacing.

I'm attaching a screenshot from the home page of http://kde.org, where I've mouse-selected a line. KHTML has rendered it so it seems there are spaces in front of the commas (as in "providing major updates to KDE Plasma Workspaces , KDE Applications , and the"). However, if I paste the line into Konsole, with a fixed-pitch font, this shows there are not really extra spaces.

Note the breaks in the mouse selection. Before the commas, the HTML has "</a>" end tags. Could KHTML be mistakenly allowing space for these tags? There's also a small gap in the following line between "KDE Platform" and the "." (not mouse-selected).

These problems started happening with 4.9.2.

Created attachment 75006 [details]
Screenshot of Akregator rendering http://commit-digest.org/issues/2012-09-30/

Adding attachment showing Akregator rendering http://commit-digest.org/issues/2012-09-30/. Notice the poor layout of the contributors at the top. The Commit Summary is unreadable.

Created attachment 75226 [details]
Test case

Created attachment 75227 [details]
Screenshot of test case

The test case has five numbered paragraphs, basically all the same (with extra lines in paragraphs 3 and 4), of different font sizes. It demonstrates that text spacing varies, becoming too much or too little according to the font size, the length of the sentence and particular character combinations. This sounds as though it might be something to do with kerning, but the problems happen with a fixed-pitch font as well as a proportional font. In the screenshot I show Courier, but I've also tested with Palatino, Liberation Sans and other proportional fonts.

It's not really a rendering problem with commit-digest.org. The bunched-up effect is due to the use of fixed-size elements to construct the bar chart, etc.

I found the rendering problem proper goes away if I turn on sub-pixel rendering through System Settings / Application Appearance / Fonts.

See also bug 225040.

*** Bug 322451 has been marked as a duplicate of this bug. ***

It seems the bug is fixed in KDE 4.11 - at least in Konqueror and some other apps that can display HTML (Kmail, Krusader). However, it's still present in Akregator: only there the HTML is rendered with subpixel positioning enabled. Any idea how is that possible? QtWebKit itself disables subpixel positioning by setting QFont::ForceIntegerMetrics. Switching to KHTML kpart makes no difference in both Konqueror and Akregator (but it works - User-Agent changes). Does anybody know how the bug was fixed in Konqueror in the first place? I'm now looking for any clue in Akregator source, so any pointers would be appreciated.

It's not fixed on my system (KHTML 4.12.1), so what you see might be specific to your system.

That makes it even more mysterious... I'm using stable Gentoo system with KWebKitPart (but there's no difference with plain KHTML kpart).

It's OK on my system, Kubuntu 13.10 with the KDE PPA updates. libkhtml5 is version 4:4.12.0-0ubuntu1~ubuntu13.10~ppa1.

I forgot to check sub-pixel rendering. I don't see a setting for it now in System Settings, though. How can I check/change the setting?

I don't have subpixel rendering enabled, I don't like it, it reminds me of chromatic abberation in photos... I have this settings in .config/fontconfig/fonts.conf (fontconfig before 2.10 used ~/.fonts.conf):

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <dir>~/.fonts</dir>
 <match target="font" >
  <edit mode="assign" name="rgba" >
   <const>none</const>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hinting" >
   <bool>true</bool>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hintstyle" >
   <const>hintslight</const>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="antialias" >
   <bool>true</bool>
  </edit>
 </match>
</fontconfig>

Just to prevent potential confusion: subpixel rendering and subpixel positioning are completely different concepts. Subpixel rendering means taking advantage of the fact that LCD display usually consists of rows of alternating red, green and blue pixels to achieve three times higher horizontal resolution - if you don't mind the color artifact on letter edges. While subpixel positioning means that position of each letter is calculated with split-pixel precision. When enabled, the same letter is rendered differently each time, which is most apparent in strings like these: iiiiiiiiiii ooooooo. With hinting in place you can no longer calculate the horizontal size of a block of text as a sum of the horizontal sizes of letters. Subpixel positioning is enabled by default since QT 4.8 and it seems there's no way to disable it in configuration, only in code by setting font.setStyleStrategy(QFont::ForceIntegerMetrics). That's what QtWebKit does, unconditionally, and that's why I'm so puzzled by this bug.

OK, I found the setting in System Settings / Application Appearance / Fonts / Anti-aliasing / Configure.

I confirm the problem is not apparent now, whether or not sub-pixel rendering is enabled, or whether or not anti-aliasing is enabled. I tested the phoronix.com page reported initially, and my test case in comment 6.

(Wow, it really looks horrible with anti-aliasing disabled altogether!)

Could you also try Akregator?(In reply to comment #16)
> I confirm the problem is not apparent now, whether or not sub-pixel
> rendering is enabled, or whether or not anti-aliasing is enabled. I tested
> the phoronix.com page reported initially, and my test case in comment 6.
Could you also try Akregator as in comment 5? And maybe also look closely at the testcase in Konqueror to make sure subpixel positioning is really disabled? Best would be to take a screenshot and magnify it in Kolourpaint or something, all those dots should look exactly the same, pixel for pixel.

I still have the same article in my Akregator archive as in the screenshot in comment 5, and now it's rendering fine. As I said in comment 8, though, I don't think the original problem there was due to the bug we're discussing here. I suspect there have been some changes to the stylesheet, or something else server-side.

I've also run the test case on Debian jessie/sid with KDE 4.11.3. Anti-aliasing was set to "System Settings" with this .config/fontconfig/fonts.conf:

<?xml version="1.0"?><!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>none</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintmedium</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>
 </match>
</fontconfig>

That rendered OK, as it did when I set sub-pixel rendering on. GIMP shows that sub-pixel rendering really was off in the first case. I'll upload screen shots.

BTW, bug 225040 is still present for me.

Created attachment 84571 [details]
Screenshot of test case on Debian jessie/sid with anti-aliasing = System Settings

Created attachment 84572 [details]
Screenshot of test case on Debian jessie/sid with sub-pixel rendering enabled

This bug has nothing to do with sub-pixel (RGB) rendering, but with fractional font metrics that has been introduced in Qt 4.8 to improve the text quality. KHTML simply adds the integer widths of each character to compute the bounding boxes, instead of passing the complete string.

But PLEASE do not "fix" it by using ForceIntegerMetrics. This looks even more ugly, once you get used to fractional metrics. It's one of the reasons I still use KHTML for reading the net.

Still, as I noted in comment 8, I found (14 months ago) that turning on sub-pixel rendering made the spacing problem go away.

(In reply to comment #21)
> But PLEASE do not "fix" it by using ForceIntegerMetrics. This looks even
> more ugly, once you get used to fractional metrics. It's one of the reasons
> I still use KHTML for reading the net.
Unfortunately changing KHTML/WebKit to use fractional metrics would likely be a large amount of work and it would need someone knowledgeable with the code base. It seems ForceIntegerMetrics was added to Qt specifically for WebKit, even Qt developers weren't able to make WebKit use fractional metrics when they integrated it into Qt. The only thing I was able to do was to set ForceIntegerMetrics in KHTMLPart which makes the rendering problem in Akregator go away (because Akregator uses KHTMLPart directly, even when WebKit browser engine is selected).

Created attachment 84652 [details]
Disable subpixel positioning in KHTML

*** Bug 312197 has been marked as a duplicate of this bug. ***

*** Bug 334489 has been marked as a duplicate of this bug. ***

Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!

I do not use konqueror any longer, so let's this bug die...

It's also no longer relevant for Akregator, it switched to QtWebEngine long ago.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!