Current status of LCD subpixel rendering

litemotiv · 2010-10-04 15:49:44

cecilyen wrote:

It's called freetype2-infinality in AUR.
Maybe this should put in the ArchWiki? http://wiki.archlinux.org/index.php/Font_Configuration

Yes, there is a small section for infinality, but it might be good to expand it a little by mentioning that it requires the Ubuntu patches (and perhaps links to infinality's configs).

Edit: also, libxft-ubuntu in AUR currently requires and builds freetype2-ubuntu, so this is also something to adapt for infinality. It might be best to split those packages.

Last edited by litemotiv (2010-10-04 15:52:04)

broch · 2010-10-04 18:21:12

http://img829.imageshack.us/img829/5615/rendering.png
less work required and at least similar effect (with cleartype).

Last edited by litemotiv (2010-10-04 20:03:55)

litemotiv · 2010-10-04 18:54:32

broch wrote:

http://img829.imageshack.us/img829/5615/rendering.png
less work required and at least similar effect (with cleartype)

It looks too bold to me and i see some spacing issues, so i'm not sure why you would prefer this over the examples on the previous page. But to each his own..

Last edited by litemotiv (2010-10-04 20:04:08)

broch · 2010-10-04 19:26:15

..
no, no spacing issues more pronounced than in your screenshot.
I do not claim that this is better (check my previous posts). However, I don't see any quality improvement except a lot of work that produces low quality results (in all cases (including mine - so this is clear) rendering is bad.
My point is that except more work nothing changed.

Mod edit: text removed, any further comments on the earlier discussion can be addressed by private message. This thread stays ontopic.

Last edited by litemotiv (2010-10-04 19:54:24)

jxy · 2010-10-04 20:48:38

litemotiv wrote:

cecilyen wrote:
It's called freetype2-infinality in AUR.
Maybe this should put in the ArchWiki? http://wiki.archlinux.org/index.php/Font_Configuration
Yes, there is a small section for infinality, but it might be good to expand it a little by mentioning that it requires the Ubuntu patches (and perhaps links to infinality's configs).

Upstream cairo (version 1.10.0) has already adopt the patch. And the ubuntu patch for fontconfig, which is just a bundle of tweaks of the config files, is useless if you use or merge the local.conf recommended by infinality. We actually only need ubuntu patches for libxft (version 2.1.14, currently) for any apps that use libxft directly. In my opinion, libxft-ubuntu (it's probably better to call it differently) should depend either on freetype2-ubuntu or freetype2-infinality, but not the other way around. I mean, if you don't use any apps that use libxft directly, you don't need to patch libxft.

litemotiv wrote:

Edit: also, libxft-ubuntu in AUR currently requires and builds freetype2-ubuntu, so this is also something to adapt for infinality. It might be best to split those packages.

Despite the misleading name, I would suggest just use libxft-ubuntu and change the dependencies on *-ubuntu to vanilla packages.

jxy · 2010-10-04 20:56:15

brebs wrote:

giddie wrote:
I'd really like to get on top of what is actually going on in the world of subpixel rendering now.
Look in the huge Gentoo fonts thread. The current state-of-the-art is "Infinality".

In addition to the forum thread, you can browse the Gentoo LCD filtering overlay. It is actively maintained and has the latest information.

litemotiv · 2010-10-04 21:42:48

jxy wrote:

Upstream cairo (version 1.10.0) has already adopt the patch.

Yes, but apparently we don't have it in our stock cairo yet.

And the ubuntu patch for fontconfig, which is just a bundle of tweaks of the config files, is useless if you use or merge the local.conf recommended by infinality.

That's possible, it would be good if we could drop that. Did you compare the filters?

Snowknight · 2010-10-05 02:46:51

litemotiv wrote:

That's possible, it would be good if we could drop that. Did you compare the filters?

I haven't prepared screenshots, but the official cairo package (1.10.0-2) and cairo-ubuntu look the same to me when I enable the lcddefault filter in my font configuration. I applied the infinality patches to my freetype2 build as well. Study and use infinality's example local.conf, and you'll see the desired rasterization. I disabled many of the tweaks that the recommended file includes. All my fonts render with the hintslight setting because, as the infinity configuration implores, "subpixel hinting is now enabled with HINTSLIGHT. HINTFULL will produce the original freetype behavior."

I'm not sure if fontconfig-ubuntu should disappear. The *-lcd variants disappeared when freetype/cairo absorbed their features. Yet fontconfig-lcd still exists: it provides a single config file to enable the lcddefault filter. Fontconfig-ubuntu gives a greater number of options. Then again, maybe freetype2-ubuntu or some other entry could absorb those files.

Last edited by Snowknight (2010-10-05 02:51:14)

brebs · 2010-10-05 02:55:44

Snowknight wrote:

as the infinity configuration implores

You're looking at an old version. That's from 3 weeks ago (and only lasted for 2 days) - an eternity in Internet time multiplied by font-rendering time. Notice:

    /********************************************************************
    Changes for 2010-09-16
    /********************************************************************
    
    The hinslight behavior from 9-14 has been removed due to issues
    in how freetype implements light hinting.

In config.
Also notice that the default is hintfull, shown in the "base settings" section of that same config.

litemotiv · 2010-10-05 07:50:11

Snowknight wrote:

I haven't prepared screenshots, but the official cairo package (1.10.0-2) and cairo-ubuntu look the same to me when I enable the lcddefault filter in my font configuration.

Though the differences are subtle, they're definitely not the same. Our stock cairo is a bit fuzzier/heavier, Here is a side by side comparision (look at the letter 'e' for instance):

vNXE4eg

vNXB3cw

The difference is more noticeable with smaller text though, there stock cairo gets really fuzzy and -ubuntu is still tight:

vNXE5MQ

vNXE5Mg

Snowknight · 2010-10-05 12:23:41

Ah, okay. I switched to cairo-ubuntu this morning, and I think the difference is slightly less subtle with either the latest infinality patches or freetype 2.4.3. Or maybe I knew to spot it after reading your post.

I'm happy with the combination I've reached now. The latest infinality.net patch (or maybe it's freetype?) set seems to have fixed my gripe with full hinting and hairline strokes on some bold weight fonts.

jxy · 2010-10-05 18:14:19

litemotiv wrote:

Snowknight wrote:
I haven't prepared screenshots, but the official cairo package (1.10.0-2) and cairo-ubuntu look the same to me when I enable the lcddefault filter in my font configuration.
Though the differences are subtle, they're definitely not the same. Our stock cairo is a bit fuzzier/heavier, Here is a side by side comparision (look at the letter 'e' for instance):

So you only changed cairo to cairo-ubuntu, and kept everything else *-ubuntu, right? Are you using the same set of configurations?

litemotiv · 2010-10-05 19:44:57

jxy wrote:

So you only changed cairo to cairo-ubuntu, and kept everything else *-ubuntu, right? Are you using the same set of configurations?

yes:

% clyde -Rd cairo-ubuntu
% clyde -S cairo

jxy · 2010-10-05 20:22:41

litemotiv wrote:

jxy wrote:
So you only changed cairo to cairo-ubuntu, and kept everything else *-ubuntu, right? Are you using the same set of configurations?
yes:
% clyde -Rd cairo-ubuntu
% clyde -S cairo

The only patch that would make a difference in cairo-ubuntu is the cairo-respect-fontconfig.patch. You can google it for more information. My guess is that your desktop environment (most probably gnome) is changing the hinting style for cairo, such that fontconfig's setup is not respected.

karabaja4 · 2010-10-05 23:14:08

I just experimented with all kinds of *-ubuntu and infinality packages and settings... And I still get the best resultwith *-cleartype packages.

On the screenshot - ttf-tahoma, hintslight, cairo-cleartype, freetype2-cleartype, libxft-cleartype, stock fontconfig.

litemotiv · 2010-10-06 07:51:15

jxy wrote:

My guess is that your desktop environment (most probably gnome) is changing the hinting style for cairo, such that fontconfig's setup is not respected.

Hmm no i'm not using a desktop environment, just a window manager.

giddie · 2010-10-06 08:36:12

Ah! By the by, I've succeeded in making Cairo render exactly the same as Qt by applying the respect-fontconfig patch (http://aur.archlinux.org/packages/cairo … nfig.patch) to Cairo from ABS. Is there any reason anyone can think of why this patch shouldn't be applied to the package in [extra]? If not, I might suggest it to the maintainer.

I'll preempt the suggestion to just use cairo-ubuntu from AUR and say that the huge patch that contains a lot of Debian-specific stuff puts me off :s

jxy · 2010-10-06 14:52:22

litemotiv wrote:

jxy wrote:
My guess is that your desktop environment (most probably gnome) is changing the hinting style for cairo, such that fontconfig's setup is not respected.
Hmm no i'm not using a desktop environment, just a window manager.

I was misinformed. I found the bug report that explains it well. Can you try with only the cairo-respect-fontconfig.patch?

giddie wrote:

Ah! By the by, I've succeeded in making Cairo render exactly the same as Qt by applying the respect-fontconfig patch (http://aur.archlinux.org/packages/cairo … nfig.patch) to Cairo from ABS. Is there any reason anyone can think of why this patch shouldn't be applied to the package in [extra]? If not, I might suggest it to the maintainer.

If the maintainer does not want to apply the patch, we can put up an aur package, which does just that patch.

litemotiv · 2010-10-06 15:16:43

jxy wrote:

I was misinformed. I found the bug report that explains it well. Can you try with only the cairo-respect-fontconfig.patch?

Looks fine with only that patch.

hamelg · 2010-10-06 19:37:26

giddie wrote:

Ah! By the by, I've succeeded in making Cairo render exactly the same as Qt by applying the respect-fontconfig patch (http://aur.archlinux.org/packages/cairo … nfig.patch) to Cairo from ABS.

Great, very valuable for kde users
thank you

schivmeister · 2010-10-07 19:48:43

Font: Trebuchet
Sub-pixel rendering: RGB
Hinting style: Slight

freetype2-cleartype 2.4.3-1
libxft-cleartype 2.1.14-1
cairo 1.10.0-2
fontconfig 2.8.0-1
fontconfig-lcd 2.8.0-1

edit: I just noticed without cairo-cleartype openoffice's font rendering now is crap. Urghh.

Last edited by schivmeister (2010-10-07 19:55:51)

litemotiv · 2010-12-11 10:17:06

After 2 months with -infinality, i've decided to go back to -ubuntu since imo it renders bold fonts much better. Infinality is promising and does a great job on spacing, but the hinting algorithm is not really there yet. Has anyone else come to the same conclusion, or has found ways to work around infinality's bold rendering?

brebs · 2010-12-11 11:35:52

litemotiv wrote:

renders bold fonts much better

On which fonts in particular? You may find this command useful, to identify them:

lsof | grep -i firefox | egrep -i 'ttf|pfb'
(Close & re-open firefox, then go straight to the page in question, otherwise firefox will include all the other fonts from other pages it is showing)

For me, Infinality's spoilt me on spacing, so I cannot use any other rendering

litemotiv · 2010-12-12 10:11:29

Here is one of the more obvious problems, this is regular monospace in xft:

Infinality
vNmlnYQ

Ubuntu
vNmowMw

I'm not sure what goes wrong with the 's' here, it seems like a hinting problem..

brebs · 2010-12-12 10:27:56

Monospace isn't a font - it's an alias.

$ fc-match "monospace"
consola.ttf: "Consolas" "Regular"

What does your "monospace" match to?

Arch Linux

#26 2010-10-04 15:49:44

Re: Current status of LCD subpixel rendering

#27 2010-10-04 18:21:12

Re: Current status of LCD subpixel rendering

#28 2010-10-04 18:54:32

Re: Current status of LCD subpixel rendering

#29 2010-10-04 19:26:15

Re: Current status of LCD subpixel rendering

#30 2010-10-04 20:48:38

Re: Current status of LCD subpixel rendering

#31 2010-10-04 20:56:15

Re: Current status of LCD subpixel rendering

#32 2010-10-04 21:42:48

Re: Current status of LCD subpixel rendering

#33 2010-10-05 02:46:51

Re: Current status of LCD subpixel rendering

#34 2010-10-05 02:55:44

Re: Current status of LCD subpixel rendering

#35 2010-10-05 07:50:11

Re: Current status of LCD subpixel rendering

#36 2010-10-05 12:23:41

Re: Current status of LCD subpixel rendering

#37 2010-10-05 18:14:19

Re: Current status of LCD subpixel rendering

#38 2010-10-05 19:44:57

Re: Current status of LCD subpixel rendering

#39 2010-10-05 20:22:41

Re: Current status of LCD subpixel rendering

#40 2010-10-05 23:14:08

Re: Current status of LCD subpixel rendering

#41 2010-10-06 07:51:15

Re: Current status of LCD subpixel rendering

#42 2010-10-06 08:36:12

Re: Current status of LCD subpixel rendering

#43 2010-10-06 14:52:22

Re: Current status of LCD subpixel rendering

#44 2010-10-06 15:16:43

Re: Current status of LCD subpixel rendering

#45 2010-10-06 19:37:26

Re: Current status of LCD subpixel rendering

#46 2010-10-07 19:48:43

Re: Current status of LCD subpixel rendering

#47 2010-12-11 10:17:06

Re: Current status of LCD subpixel rendering

#48 2010-12-11 11:35:52

Re: Current status of LCD subpixel rendering

#49 2010-12-12 10:11:29

Re: Current status of LCD subpixel rendering

#50 2010-12-12 10:27:56

Re: Current status of LCD subpixel rendering

Board footer