Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[HOWTO]Freetype subpixel font rendering - lcd monitors Pt 2
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 17, 18, 19 ... 27, 28, 29  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
rahulthewall
Veteran
Veteran


Joined: 01 Nov 2007
Posts: 1264
Location: Zürich

PostPosted: Mon Nov 01, 2010 3:37 pm    Post subject: Reply with quote

libXft has reached version 2.2.0 in portage. Do we have a patch for that already?
_________________
Who shall guard the guards?
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Mon Nov 01, 2010 4:27 pm    Post subject: Reply with quote

rahulthewall wrote:
libXft has reached version 2.2.0 in portage. Do we have a patch for that already?

Simply don't apply 001_no_export_freetype.diff

pezed, try hintfull for the broken bold fonts. See above in this thread for how to identify them:

lsof | grep -i firefox | egrep -i 'ttf|pfb'
Back to top
View user's profile Send private message
iGold
n00b
n00b


Joined: 02 Nov 2010
Posts: 2

PostPosted: Tue Nov 02, 2010 10:51 am    Post subject: Reply with quote

I just want to ask is it important to set real DPI for subpixel hinting and LCD filter?

I have 9" netbook with real DPI about 134, but 96 DPI has autodetected by X Window. If I set DPI to 134 fonts become too big at 9-10 points and also many UI elements begin to work incorrectly. But it seems to glyph edges more colourful at 96 DPI.

FYI: I use freetype2-infinality (and respective local.conf), libxft-lcd and "respect fontconfig" patched cairo in LXDE under Arch Linux.
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Tue Nov 02, 2010 4:37 pm    Post subject: Reply with quote

iGold wrote:
But it seems to glyph edges more colourful at 96 DPI

That's a clue to the answer - yes, it's important.

DPI is *two* values - horizontal and vertical, because we don't have square monitors.
Back to top
View user's profile Send private message
ssteinberg
Apprentice
Apprentice


Joined: 09 Jul 2010
Posts: 206
Location: Israel

PostPosted: Tue Nov 02, 2010 5:04 pm    Post subject: Reply with quote

PaulBredbury wrote:
iGold wrote:
But it seems to glyph edges more colourful at 96 DPI

That's a clue to the answer - yes, it's important.

DPI is *two* values - horizontal and vertical, because we don't have square monitors.


Nor are we using square resolutions (whether native or actual). Our pixels are squares, horizontal and vertical pixel density is identical.
(You deserve to be punched if you are one of those using a 1280x1024 resolution on 4x3 monitor...)
Back to top
View user's profile Send private message
aoeuaoue
n00b
n00b


Joined: 26 Feb 2010
Posts: 31

PostPosted: Tue Nov 02, 2010 9:06 pm    Post subject: freetype USE flags Reply with quote

hi,

I've been always confused about the USE flags in media-libs/freetype in portage it has two USE flags dealing with qualty of fonts.
Code:

[-    ] auto-hinter (media-libs/freetype):
Use the unpatented auto-hinter instead of the (recommended) TrueType bytecode interpreter


and the other one is:
Code:

[- c  ] bindist - Flag to enable or disable options for prebuilt (GRP)  packages (eg. due to licensing issues)


Now without doing this crazy patching what's the preferred USE flag to use with freetype package? Currently I haven't turned on any. But my Inconsolata font looks a bit crazy in terminals with some letters. For instance the word Terminator looks like this:

Terminator

Which USE flag is better to use with freetype, bindist or auto-hinter?

Thanks in advanced.

P.S.: I wish manufacturers would make computer monitors with RETINA DISPLAY :D
Back to top
View user's profile Send private message
mbar
Veteran
Veteran


Joined: 19 Jan 2005
Posts: 1979
Location: Poland

PostPosted: Wed Nov 03, 2010 7:54 am    Post subject: Reply with quote

PaulBredbury wrote:
rahulthewall wrote:
libXft has reached version 2.2.0 in portage. Do we have a patch for that already?

Simply don't apply 001_no_export_freetype.diff

pezed, try hintfull for the broken bold fonts. See above in this thread for how to identify them:

lsof | grep -i firefox | egrep -i 'ttf|pfb'


Could someone please update the overlay?
Back to top
View user's profile Send private message
iGold
n00b
n00b


Joined: 02 Nov 2010
Posts: 2

PostPosted: Wed Nov 03, 2010 8:23 am    Post subject: Reply with quote

Thank you for the answer, PaulBredbury.
Well, I found why my fonts were so colourful. This effect was only in firefox because of switched off option --enable-system-cairo in recent Arch binary version of firefox (https://bbs.archlinux.org/viewtopic.php?id=105660). When I rebuilt FF with --enable-system-cairo it began render fonts the same way as other applications. Much better even with incorrect DPI setting.
Back to top
View user's profile Send private message
luscinius
n00b
n00b


Joined: 17 Jul 2008
Posts: 63

PostPosted: Wed Nov 03, 2010 3:50 pm    Post subject: Reply with quote

I also have problems similar to pezed.
Note that in the pictures shown the horizontal bar of the "e" letter appears uplifted. I think it was mentioned that some of the patches implement hinting in vertical direction only. This would explain the behavior of the "e" letter (in particular, the fact that the horizontal bar is lifted only for some particular font sizes). Would it be possible to introduce a USE flag to disable these particular patches?

I have another question: what is the fontconfig cache, the one in .fontconfig and /var/cache/fontconfig? After a freetype upgrade the fonts did not look good, and removing .fontconfig/* fixed it. Otherwise the fonts look differently on different computers with the same configuration.

aoeuaoue:
bindist and auto-hinter are the two separate USE flags, and they can be used in any combination.
The fragment of the ebuild they are used in is:
Code:
 
   if ! use bindist; then
      # See http://freetype.org/patents.html
      # ClearType is covered by several Microsoft patents in the US
      enable_option FT_CONFIG_OPTION_SUBPIXEL_RENDERING
   fi

   if use auto-hinter; then
      disable_option TT_CONFIG_OPTION_BYTECODE_INTERPRETER
      enable_option TT_CONFIG_OPTION_UNPATENTED_HINTING
   fi

Thus USE="+bindist" makes disables subpixel rendering, and USE="+auto-hinter" disables bytecode interpreter (the latter one is no longer patented).
You can also try changing your fontconfig settings.
Back to top
View user's profile Send private message
aoeuaoue
n00b
n00b


Joined: 26 Feb 2010
Posts: 31

PostPosted: Wed Nov 03, 2010 6:52 pm    Post subject: Reply with quote

luscinius wrote:
I also have problems similar to pezed.
Note that in the pictures shown the horizontal bar of the "e" letter appears uplifted. I think it was mentioned that some of the patches implement hinting in vertical direction only. This would explain the behavior of the "e" letter (in particular, the fact that the horizontal bar is lifted only for some particular font sizes). Would it be possible to introduce a USE flag to disable these particular patches?

I have another question: what is the fontconfig cache, the one in .fontconfig and /var/cache/fontconfig? After a freetype upgrade the fonts did not look good, and removing .fontconfig/* fixed it. Otherwise the fonts look differently on different computers with the same configuration.

aoeuaoue:
bindist and auto-hinter are the two separate USE flags, and they can be used in any combination.
The fragment of the ebuild they are used in is:
Code:
 
   if ! use bindist; then
      # See http://freetype.org/patents.html
      # ClearType is covered by several Microsoft patents in the US
      enable_option FT_CONFIG_OPTION_SUBPIXEL_RENDERING
   fi

   if use auto-hinter; then
      disable_option TT_CONFIG_OPTION_BYTECODE_INTERPRETER
      enable_option TT_CONFIG_OPTION_UNPATENTED_HINTING
   fi

Thus USE="+bindist" makes disables subpixel rendering, and USE="+auto-hinter" disables bytecode interpreter (the latter one is no longer patented).
You can also try changing your fontconfig settings.


So, do you mean I can benefit with having nicer fonts by setting those two USE flags? Currently I don't have +bindist nor +auto-hinter turned on.

thanks
Back to top
View user's profile Send private message
luscinius
n00b
n00b


Joined: 17 Jul 2008
Posts: 63

PostPosted: Wed Nov 03, 2010 7:03 pm    Post subject: Reply with quote

Quote:

So, do you mean I can benefit with having nicer fonts by setting those two USE flags?

Probably no. These USE flags disable some features (sub-pixel rendering or hinting using built-in hints). As far as I understand, it can be done using fontconfig as well (e.g., using eselect fontconfig for the system-wide changes). I would not fo it myself.
Regarding Inconsolata font: which terminal are you using? Does this font look bad in other apps as well?
Back to top
View user's profile Send private message
swimmer
Veteran
Veteran


Joined: 15 Jul 2002
Posts: 1310
Location: Netherlands

PostPosted: Thu Nov 04, 2010 11:30 am    Post subject: Reply with quote

I solved the problem with the letter "e" by using infinality's local.conf from 14-09-2010 ...

HTH
swimmer
Back to top
View user's profile Send private message
darklegion
Guru
Guru


Joined: 14 Nov 2004
Posts: 468

PostPosted: Fri Nov 05, 2010 4:46 am    Post subject: Reply with quote

PaulBredbury wrote:
iGold wrote:
But it seems to glyph edges more colourful at 96 DPI

That's a clue to the answer - yes, it's important.

DPI is *two* values - horizontal and vertical, because we don't have square monitors.


So what is the real world answer, use hardware DPI or always force 96 DPI?
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Fri Nov 05, 2010 5:51 am    Post subject: Reply with quote

Use the DPI which is the physical reality of your monitor.

96 and 120 dpi, are just convenient hacks.

Example on my PC:

$ xdpyinfo | grep -B1 dot
dimensions: 1920x1080 pixels (372x231 millimeters)
resolution: 131x119 dots per inch
Back to top
View user's profile Send private message
darklegion
Guru
Guru


Joined: 14 Nov 2004
Posts: 468

PostPosted: Fri Nov 05, 2010 8:05 am    Post subject: Reply with quote

PaulBredbury wrote:
Use the DPI which is the physical reality of your monitor.

96 and 120 dpi, are just convenient hacks.

Example on my PC:

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


Okay, I've been using DisplaySize based on the dimensions of my monitor. However, DPI seems to be the same value for both vertical and horizontal. Is this expected, or should most monitors have different vertical and horizontal DPI?

It's a 32 Inch Panasonic TV (uses an IPS-alpha panel, which could be relevant here)

Code:

DisplaySize 698 393


Code:

xdpyinfo | grep -B1 dot
dimensions:    1920x1080 pixels (707x398 millimeters)
resolution:    69x69 dots per inch
Back to top
View user's profile Send private message
bi3l
Apprentice
Apprentice


Joined: 06 Feb 2003
Posts: 268
Location: France

PostPosted: Fri Nov 05, 2010 8:16 am    Post subject: Reply with quote

mbar wrote:
Could someone please update the overlay?

Done.
_________________
OGMRip - LCD filtering (Wiki)
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Fri Nov 05, 2010 8:23 am    Post subject: Reply with quote

1920/707*25.4 = 68.9...
1080/398*25.4 = 68.9...

So looks right.

There's 25.4 millimetres in an inch.
Back to top
View user's profile Send private message
mbar
Veteran
Veteran


Joined: 19 Jan 2005
Posts: 1979
Location: Poland

PostPosted: Fri Nov 05, 2010 8:52 am    Post subject: Reply with quote

bi3l wrote:
mbar wrote:
Could someone please update the overlay?

Done.


many thanks!
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2858
Location: Bay Area, CA

PostPosted: Sun Nov 14, 2010 8:07 pm    Post subject: Reply with quote

So, after the upgrade to freetype 2.4.3 from lcd-filtering overlay, my fonts look bigger than they looked with 2.4.2. What happened? How do I fix it? I am still logged into the same X session, so DPI is 96 all over.

One more thing: in certain fonts, 's' is looking weird with middle part gone!
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Mon Nov 15, 2010 12:09 am    Post subject: Reply with quote

devsk wrote:
in certain fonts, 's' is looking weird with middle part gone!

This is noticeable with FreeMono and MS Mincho, and can't really be cured with fontconfig rules.

Anyway, will hopefully have a new release soon.
Back to top
View user's profile Send private message
Infinality
n00b
n00b


Joined: 12 Aug 2010
Posts: 24
Location: Wisconsin, USA

PostPosted: Mon Nov 15, 2010 4:02 am    Post subject: S issue Reply with quote

The s issue is a result of the horizontal stem width snapping (that makes autohint look like Windows fonts). It's annoying me too, and I'm trying to figure out a way to fix it without ruining the rest of the glyphs. Any suggestions would be appreciated!

8)

EDIT: The way I recommend approaching this bug, from me, the coder, to you guys, the end-user is this: Given how awesome FreeMono looks now, compared to before, who cares about a little problem with the s. :D
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2858
Location: Bay Area, CA

PostPosted: Mon Nov 15, 2010 6:10 am    Post subject: Reply with quote

Man, I hate this ping pong. Every upgrade of freetype has been disruptive and I am left to tune the whole damn thing from scratch. Now, my fonts are ugly thick and bigger than before in gtk apps, and smaller and thicker in KDE. Also, some fonts are bigger than others in the same firefox window. Going back to 2.4.2 for now.
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Tue Nov 16, 2010 1:40 am    Post subject: Reply with quote

Hooray, a new Infinality release :D

Fonts look different (improved) yet again, and there's many new options. Will take a while to digest all of this 8O
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2858
Location: Bay Area, CA

PostPosted: Tue Nov 16, 2010 3:26 am    Post subject: Reply with quote

PaulBredbury wrote:
Hooray, a new Infinality release :D

Fonts look different (improved) yet again, and there's many new options. Will take a while to digest all of this 8O
And once you digest, you will help us mere mortal get good looking normal fonts, right?...:-D
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Tue Nov 16, 2010 3:35 pm    Post subject: Reply with quote

This patch will make things slightly easier - freetype-2.4.3-infinality-20101114-brebs-all-in-one.patch.bz2

It's the result of:

Code:
patch -Np1 -i freetype-add-subpixel-hinting-infinality-20101114-1.patch  &&
patch -Np1 -i freetype-enable-subpixel-hinting-infinality-20100909-1.patch  &&
patch -Np1 -i freetype-entire-infinality-patchset-20101114-1.patch  &&
patch -Np1 -i freetype-2.4.3-20101114-infinality-apply-env-defaults.patch  &&
patch -Np1 -i freetype-2.2.1-enable-valid.patch  &&
patch -Np1 -i freetype-2.4.3-git-20101109.patch  &&

# Enable system zlib
sed -i -r 's:.*(#.*SYSTEM_ZLIB.*) .*:\1:' include/freetype/config/ftoption.h  &&

rm -f include/freetype/config/ftoption.h.orig src/base/ftobjs.c.orig src/truetype/ttinterp.c.orig include/freetype/internal/ftobjs.h.orig


Apply it, and only it, to vanilla freetype 2.4.3, then compile.

freetype-2.4.3-20101114-infinality-apply-env-defaults.patch replaces the need for any shell exports, as long as you agree with the settings I've chosen. And freetype-2.4.3-git-20101109.patch applies all the latest git updates (fixing yet another security bug).

You'll still have to pay attention to fontconfig settings, though.

Shell exports are a bad idea, because they only apply if the app is started from the shell command-line. They do *not* apply if I start e.g. firefox from the XFCE menu.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page Previous  1, 2, 3 ... 17, 18, 19 ... 27, 28, 29  Next
Page 18 of 29

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum