Current status of LCD subpixel rendering

litemotiv · 2010-12-12 10:30:27

brebs wrote:

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

I know, i figured you understood that 'regular' meant 'default', so DejaVu Sans Mono.

brebs · 2010-12-12 11:03:22

Infinality's rendering gives me this, which has no problem with split bold "s". I suggest you try my freetype-2.4.3-20101114-infinality-apply-env-defaults.patch

Bad "s" were supposed to be fixed by the 17-Nov-ish Infinality patch update, IIRC - so are you up-to-date?

litemotiv · 2010-12-12 11:31:07

brebs wrote:

Infinality's rendering gives me this

Is that Xft? Since Cairo doesn't give me this problem.

Bad "s" were supposed to be fixed by the 17-Nov-ish Infinality patch update, IIRC - so are you up-to-date?

Yes i updated 2-3 days ago.

brebs · 2010-12-12 11:51:59

I confess, that was via firefox, so no xft used.

What app are you using? Or can you suggest one for me to check with?

litemotiv · 2010-12-12 12:12:30

brebs wrote:

I confess, that was via firefox, so no xft used.
What app are you using? Or can you suggest one for me to check with?

These were taken in a console (rxvt-unicode), so it propagates to everything under that.

thayer · 2010-12-12 19:16:26

I've been trying out the infinality patch for the last two days, alternating between the different presets. I love the idea of it and the simplicity of choosing ones preference; however I still find the result lacking.

I probably stand alone on my belief, but true Windows 98 font rendering seems the least evil of them all. No matter which font patches I use under Linux, I eventually return to aliased Windows fonts. Under Windows XP, standard rendering and cleartype are interchangeable; both look good. Under Apple...well it's Apple. Linux just can't seem to get it right*.

* A completely opinionated statement of course; your mileage may vary.

Last edited by thayer (2010-12-12 19:25:48)

schivmeister · 2010-12-12 22:41:01

Infinality _almost_ made it here. But no, OpenOffice is still ugly (not that I care now as I replaced it with KOffice), and the fonts in KDM, though they look as fine as with cleartype patches, are not exactly 'uniform' or 'proportionate'. So, back to cleartype with MS fonts.

Last edited by schivmeister (2010-12-12 22:42:03)

thayer · 2010-12-13 00:58:19

schivmeister wrote:

Infinality _almost_ made it here. But no, OpenOffice is still ugly (not that I care now as I replaced it with KOffice), and the fonts in KDM, though they look as fine as with cleartype patches, are not exactly 'uniform' or 'proportionate'. So, back to cleartype with MS fonts.

That screenshot is the result of the -cleartype patches? I'm impressed. Also, I recall reading somewhere that OpenOffice.org uses its own font-rendering engine, though I use it so rarely I could be way off the mark.

thestinger · 2010-12-13 01:22:37

thayer wrote:

schivmeister wrote:
Infinality _almost_ made it here. But no, OpenOffice is still ugly (not that I care now as I replaced it with KOffice), and the fonts in KDM, though they look as fine as with cleartype patches, are not exactly 'uniform' or 'proportionate'. So, back to cleartype with MS fonts.
That screenshot is the result of the -cleartype patches? I'm impressed. Also, I recall reading somewhere that OpenOffice.org uses its own font-rendering engine, though I use it so rarely I could be way off the mark.

OpenOffice, at least in Arch, ignores fontconfig settings (so does the stock arch firefox package), so fonts will look horrible with the -infinality patch unless you also use .Xresources settings in addition to the .fonts.conf. It might just need to be compiled differently, but I wouldn't be surprised if they have their own font rendering engine... I mean they did reinvent the wheel with their own GUI toolkit.

@schiv
You can disable any of the individual infinality patches in /etc/profile.d/infinality-settings.sh, so you might want to give it another chance and just disable the stuff you didn't like (probably stem alignment).

Last edited by thestinger (2010-12-13 01:29:18)

schivmeister · 2010-12-13 19:30:00

@thayer
Yep. More precisely:

cairo-cleartype-xcb 1.10.0-1
freetype2-cleartype 2.4.3-1
libxft-cleartype 2.2.0-1
fontconfig-lcd 2.8.0-1
ttf-ms-fonts

fonts/conf.d important symlinks:

10-autohint.conf
10-lcd-filter.conf

~/.fonts.conf is autogenerated by KDE's font module, which has the following settings:

Anti-aliasing = True
Subpixel rendering = RGB
Hinting style = Slight

The hinting changes things drastically. I find that None works best for GTK+ and Slight for Qt. It depends how much width you like to see. Medium and up totally ruins it.

@thestinger
That still requires me to muck around. With cleartype I do essentially nothing and I have good rendering everywhere including OpenOffice. At least until cleartype remains alive I'll stick to it. By then, infinality or something else would probably be the in-thing. I hope.

karabaja4 · 2010-12-13 20:27:48

@schivmeister, hmm, I get best results with these packages:

cairo-cleartype-xcb
freetype2-infinality
libxft-cleartype
fontconfig-ubuntu
ttf-ms-fonts and Segoe UI (copied)

/etc/fonts/conf.d/ custom symlinks:

10-antialias.conf
10-autohint.conf
10-hinting.conf
10-hinting-slight.conf
10-sub-pixel-rgb.conf

Slight hinting works best everywhere I think. Result:

thestinger · 2010-12-13 21:34:41

karabaja4 wrote:

Slight hinting works best everywhere I think. Result:

In my opinion, that looks awful. You probably shouldn't be mixing the -cleartype packages with -infinality, and things would look better if you were using full TT hinting for fonts with good instructions and only falling back to hintslight autohint for other fonts, like the standard infinality local.conf.

Same thing here:

Text (Arial):
vNnk3Nw

Code block (Consolas):
vNnk3OQ

More Consolas:
vNnk3Ng

I'm using freetype2-infinality and libxft-lcd, no changes to the infinality-settings file, and my font configuration is very similar to the "Infinality" profile in Infinality's local.conf. I'm still noticing some rare color fringes making it through the LCD filtering, mostly on bold fonts. The default strong gibson filter is also too blurry for my tastes so I should probably change it (check out the x in the code block screenshot).

After replacing ttf-ms-fonts and ttf-vista-fonts with the fonts from a win7 install, things are looking a lot better. ttf-ms-fonts has version 2.00 of fonts that are now at version 5.00 or higher and the hinting has really gotten a lot better (along with wider unicode support).

libxft-lcd example (urxvt with monaco), not really on par with gtk+, qt and other applications that use cairo from what I can tell:
vNnk3OA

Last edited by thestinger (2011-01-11 23:57:26)

Gillian00 · 2010-12-22 10:30:55

Hi,

I followed your instructions and tweaks with infinality patches and fonts.conf etc etc but I have still a little problem:

You can see I have beautiful rendering at the top of the webpage and crapy fonts in the middle of the webpage.
So nice rendering works with kde apps, desktop, and most webpages with chromium or firefox but for some webpages or apps like kopete, I just have crapy fonts

Can you help me ??

Thanks ^^

EDIT: crapy rendering with facebook also ...

EDIT n°2: I have better rendering when I set bigger fonts, How can I have good rendering with small fonts ??

--mod edit: use thumbnails, see: https://wiki.archlinux.org/index.php/Fo … s_and_Code

Last edited by Gillian00 (2010-12-22 11:24:40)

estevao · 2011-06-07 01:11:00

I believe that this thread is still relevant, so I'll post my cleartype configuration and some shots.

Packages:

fontconfig 2.8.0-1
fontconfig-lcd 2.8.0-1
freetype2-cleartype 2.4.4-1
cairo-cleartype 1.10.0-1
libxft-cleartype 2.1.14-1

.fonts.conf:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>rgb</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
  <edit name="autohint">
   <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="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="lcdfilter">
   <const>lcddefault<const>
  </edit>
 </match>
</fontconfig>

Some shots:

For my taste cleartype is the best choice and the packages still work, the only problem is that they are outdated.

Someone still using cleartype patches? Thanks.

Last edited by estevao (2011-06-07 01:18:22)

thestinger · 2011-06-07 01:26:03

Just use freetype2-infinality and disable the features that you don't like (in /etc/profile.d/infinality-settings.sh).

You can get the same result by setting INFINALITY_FT_FILTER_PARAMS to what the cleartype patches use.

Last edited by thestinger (2011-06-07 01:26:39)

brebs · 2011-06-07 01:36:52

Those are huge fonts. Here's what I use (Infinality's rendering).

estevao · 2011-06-07 01:38:42

@thestinger:

The _exact same_ result or something similar?

Do you know the INFINALITY_FT_FILTER_PARAMS that the cleartype patches use? I didn't find them in the patches.

Thanks.

@brebs:

I like huge and well rendered fonts. Small fonts gives me headache.

Can you tell me your setup?

Thanks.

Last edited by estevao (2011-06-07 01:49:24)

brebs · 2011-06-07 02:03:26

My config is scattered on the huge Gentoo fonts thread, along with my Infinality config. I'm using Infinality's ~/.fonts.conf

$ xdpyinfo | grep -B1 dot
dimensions: 1920x1080 pixels (372x230 millimeters)
resolution: 131x119 dots per inch

estevao · 2011-06-07 02:37:37

I adapted the pkgbuild of libxft-cleartype from AUR and it worked just fine. Now I have libxft-cleartype-2.2.0.

EDIT: The same thing with cairo-cleartype, now I'm running cairo-cleartype-1.10.2. Wondering why these packages aren't recommended anymore... some idea? Thanks.

pkgbuilds:

http://paste.archlinux-br.org/1736
http://paste.archlinux-br.org/1737

Last edited by estevao (2011-06-07 17:49:04)

estevao · 2011-06-07 20:34:53

Someone still using cleartype patches?

Thanks.

brebs · 2011-06-07 21:02:56

estevao wrote:

Do you know the INFINALITY_FT_FILTER_PARAMS that the cleartype patches use? I didn't find them in the patches.

Here's a big clue. Look at line 19 of cairo-cleartype's cairo-9999-cleartype.patch:

static const int   fir_filter[5] = { 0x1C, 0x38, 0x55, 0x38, 0x1C };

I'll let you do the hex-to-dec conversion

You could also experiment with different arrays, if you feel like it.

Sounds like cairo-cleartype is a candidate for adoption.

estevao · 2011-06-07 21:24:28

@brebs:

I'll convert and try this array later. Thanks for the detective work on this.

I already tested all the suggested arrays and none suits my needs, unfortunately.

I leaved a message for cairo-cleartype maintainer on AUR.

Last edited by estevao (2011-06-07 21:26:23)

bwat47 · 2011-06-08 01:35:42

Am I the only one that vastly preferrs the ubuntu font rendering patches to infinality? I tried using infinality and tweaking its rendering but I couldn't get it as nice and readable as the ubuntu patches.

estevao · 2011-06-08 01:57:19

@bwat47

I prefer ubuntu patches in relation to infinality too, in fact, the final result of ubuntu patches is very similar to cleartype (just a little bit worse IMO). Give cleartype a try, you'll like it.

Last edited by estevao (2011-06-08 01:59:51)

estevao · 2011-06-20 14:50:56

Hey guys,

The cleartype packages are back on AUR!

https://wiki.archlinux.org/index.php/Fo … e_packages

freetype2-cleartype: http://aur.archlinux.org/packages.php?ID=8108
cairo-cleartype: http://aur.archlinux.org/packages.php?ID=8110
libxft-cleartype: http://aur.archlinux.org/packages.php?ID=8112

Last edited by estevao (2011-06-20 17:49:13)

Arch Linux

#51 2010-12-12 10:30:27

Re: Current status of LCD subpixel rendering

#52 2010-12-12 11:03:22

Re: Current status of LCD subpixel rendering

#53 2010-12-12 11:31:07

Re: Current status of LCD subpixel rendering

#54 2010-12-12 11:51:59

Re: Current status of LCD subpixel rendering

#55 2010-12-12 12:12:30

Re: Current status of LCD subpixel rendering

#56 2010-12-12 19:16:26

Re: Current status of LCD subpixel rendering

#57 2010-12-12 22:41:01

Re: Current status of LCD subpixel rendering

#58 2010-12-13 00:58:19

Re: Current status of LCD subpixel rendering

#59 2010-12-13 01:22:37

Re: Current status of LCD subpixel rendering

#60 2010-12-13 19:30:00

Re: Current status of LCD subpixel rendering

#61 2010-12-13 20:27:48

Re: Current status of LCD subpixel rendering

#62 2010-12-13 21:34:41

Re: Current status of LCD subpixel rendering

#63 2010-12-22 10:30:55

Re: Current status of LCD subpixel rendering

#64 2011-06-07 01:11:00

Re: Current status of LCD subpixel rendering

#65 2011-06-07 01:26:03

Re: Current status of LCD subpixel rendering

#66 2011-06-07 01:36:52

Re: Current status of LCD subpixel rendering

#67 2011-06-07 01:38:42

Re: Current status of LCD subpixel rendering

#68 2011-06-07 02:03:26

Re: Current status of LCD subpixel rendering

#69 2011-06-07 02:37:37

Re: Current status of LCD subpixel rendering

#70 2011-06-07 20:34:53

Re: Current status of LCD subpixel rendering

#71 2011-06-07 21:02:56

Re: Current status of LCD subpixel rendering

#72 2011-06-07 21:24:28

Re: Current status of LCD subpixel rendering

#73 2011-06-08 01:35:42

Re: Current status of LCD subpixel rendering

#74 2011-06-08 01:57:19

Re: Current status of LCD subpixel rendering

#75 2011-06-20 14:50:56

Re: Current status of LCD subpixel rendering

Board footer