| View previous topic :: View next topic |
| Author |
Message |
rahulthewall
Veteran
Joined: 01 Nov 2007
Posts: 1264
Location: Zürich
|
 Posted: Mon Nov 01, 2010 3:37 pm Post subject: |
 |
|
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 |
|
 |
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Mon Nov 01, 2010 4:27 pm Post subject: |
|
|
| 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 |
|
|
iGold
n00b
Joined: 02 Nov 2010
Posts: 2
|
| Posted: Tue Nov 02, 2010 10:51 am Post subject: |
|
|
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 |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Tue Nov 02, 2010 4:37 pm Post subject: |
|
|
| 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 |
|
|
ssteinberg
Apprentice
Joined: 09 Jul 2010
Posts: 206
Location: Israel
|
| Posted: Tue Nov 02, 2010 5:04 pm Post subject: |
|
|
| 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 |
|
|
aoeuaoue
n00b
Joined: 26 Feb 2010
Posts: 31
|
| Posted: Tue Nov 02, 2010 9:06 pm Post subject: freetype USE flags |
|
|
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  |
|
| Back to top |
|
|
mbar
Veteran
Joined: 19 Jan 2005
Posts: 1990
Location: Poland
|
| Posted: Wed Nov 03, 2010 7:54 am Post subject: |
|
|
| 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 |
|
|
iGold
n00b
Joined: 02 Nov 2010
Posts: 2
|
| Posted: Wed Nov 03, 2010 8:23 am Post subject: |
|
|
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 |
|
|
luscinius
n00b
Joined: 17 Jul 2008
Posts: 63
|
| Posted: Wed Nov 03, 2010 3:50 pm Post subject: |
|
|
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 |
|
|
aoeuaoue
n00b
Joined: 26 Feb 2010
Posts: 31
|
| Posted: Wed Nov 03, 2010 6:52 pm Post subject: |
|
|
| 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 |
|
|
luscinius
n00b
Joined: 17 Jul 2008
Posts: 63
|
| Posted: Wed Nov 03, 2010 7:03 pm Post subject: |
|
|
| 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 |
|
|
swimmer
Veteran
Joined: 15 Jul 2002
Posts: 1330
Location: Netherlands
|
| Posted: Thu Nov 04, 2010 11:30 am Post subject: |
|
|
I solved the problem with the letter "e" by using infinality's local.conf from 14-09-2010 ...
HTH
swimmer |
|
| Back to top |
|
|
darklegion
Guru
Joined: 14 Nov 2004
Posts: 468
|
| Posted: Fri Nov 05, 2010 4:46 am Post subject: |
|
|
| 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 |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Fri Nov 05, 2010 5:51 am Post subject: |
|
|
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 |
|
|
darklegion
Guru
Joined: 14 Nov 2004
Posts: 468
|
| Posted: Fri Nov 05, 2010 8:05 am Post subject: |
|
|
| 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 |
|
|
bi3l
Apprentice
Joined: 06 Feb 2003
Posts: 268
Location: France
|
| Posted: Fri Nov 05, 2010 8:16 am Post subject: |
|
|
| mbar wrote: | | Could someone please update the overlay? |
Done.
_________________
OGMRip - LCD filtering (Wiki) |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Fri Nov 05, 2010 8:23 am Post subject: |
|
|
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 |
|
|
mbar
Veteran
Joined: 19 Jan 2005
Posts: 1990
Location: Poland
|
| Posted: Fri Nov 05, 2010 8:52 am Post subject: |
|
|
| bi3l wrote: | | mbar wrote: | | Could someone please update the overlay? |
Done. |
many thanks! |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Sun Nov 14, 2010 8:07 pm Post subject: |
|
|
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 |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Mon Nov 15, 2010 12:09 am Post subject: |
|
|
| 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 |
|
|
Infinality
n00b
Joined: 12 Aug 2010
Posts: 24
Location: Wisconsin, USA
|
| Posted: Mon Nov 15, 2010 4:02 am Post subject: S issue |
|
|
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!
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. |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Mon Nov 15, 2010 6:10 am Post subject: |
|
|
| 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 |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Tue Nov 16, 2010 1:40 am Post subject: |
|
|
Hooray, a new Infinality release
Fonts look different (improved) yet again, and there's many new options. Will take a while to digest all of this  |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Tue Nov 16, 2010 3:26 am Post subject: |
|
|
| PaulBredbury wrote: | Hooray, a new Infinality release
Fonts look different (improved) yet again, and there's many new options. Will take a while to digest all of this |
And once you digest, you will help us mere mortal get good looking normal fonts, right?... |
|
| Back to top |
|
|
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Tue Nov 16, 2010 3:35 pm Post subject: |
|
|
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 |
|
|
|
Documentation, Tips & Tricks
