Bug 1570

Summary:	Subpixel Hinting support for Cairo
Product:	Mageia	Reporter:	Anshul Jain <anshulajain>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	Normal	CC:	marja11
Version:	1
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	fontconfig-2.8.0-5.mga1	CVE:
Status comment:
Attachments:	config file to enable subpixel rendering through cairo

Description Anshul Jain 2011-06-04 05:18:36 CEST

Description of problem:

The existing libfreetype6 is built with the bytecode interpreter support enabled...but has subpixel hinting disabled. By enabling subpixel hinting all Qt/KDE apps have perfect subpixel rendered fonts, but the GTK/GNOME ones are still fuzzy. This can be easily rectified by adding a 10-lcd-filter.conf file in /etc/fonts/conf.avail with a symlink to /etc/fonts/conf.d. The contents of this file are :-

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<!-- Enable freetype's new subpixel filter. Currently, only a cairo
version containing the patches from freedesktop #10301 respects this
setting. -->
<match target="font">
<edit mode="assign" name="lcdfilter">
<const>lcddefault</const>
</edit>
</match>
</fontconfig>
 
This would round off the whole font rendering cycle as cairo respects this setting through fontconfig (fdo # 10301). A screenshot with GTK apps enabling subpixel support :- http://www.imagebam.com/image/c6273b135062324

Comment 1 Anshul Jain 2011-06-04 05:21:22 CEST

Created attachment 514 [details]
config file to enable subpixel rendering through cairo

Comment 2 Ahmad Samir 2011-06-04 05:33:40 CEST

Actually Qt4 apps aren't affected at all by whether the runtime freetype2 is built with sub-pixel rendering or not; as actually Qt4 has a _build time_ check, if the freetype2 package installed when building qt4 doesn't have sub-pixel rendering enabled, Qt4 uses its internal rendering code (which is the same as the code that was in Cairo, and was changed when Cairo upstream applied the freetype2 patches, as you can see from fdo #10301).

I think this is a duplicate of bug 1549, i.e. it'll be resolved by the Tainted freetype2 build.

As for providing 10-lcd-filter.conf, I don't think enforcing lcddefault is optimum, we should just leave it as whatever upstream default is (IINM the upstream default is still lcdlegacy); and users who want to tweak it can either edit ~/.fonts.conf or use a global config file.

Comment 3 Marja Van Waes 2011-10-17 21:34:50 CEST

(In reply to comment #2)

> I think this is a duplicate of bug 1549, i.e. it'll be resolved by the Tainted
> freetype2 build.
> 
And bug 1549 was a duplicate of 1909, which got fixed.

So, is the problem resolved, now?

CC: (none) => marja11

Comment 4 Marja Van Waes 2011-11-13 09:43:23 CET

(In reply to comment #2)

> I think this is a duplicate of bug 1549, i.e. it'll be resolved by the Tainted
> freetype2 build.
> 
Bug 1549 was a duplicate of bug 1909 (really the other way around, of course), that issue got solved

> As for providing 10-lcd-filter.conf, I don't think enforcing lcddefault is
> optimum, we should just leave it as whatever upstream default is (IINM the
> upstream default is still lcdlegacy); and users who want to tweak it can either
> edit ~/.fonts.conf or use a global config file.

and this won't be done

So this bug report can be closed, I choose "wontfix" for the second issue instead of "duplicate" for the first, because before Ahmad chose not to set this bug report to the "resolved-duplicate" status

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX