Package Details: freetype2-infinality 2.7.1-1

Git Clone URL: (read-only)
Package Base: freetype2-infinality
Description: TrueType font rendering library with Infinality patches and custom settings.
Upstream URL:
Licenses: GPL
Conflicts: freetype2
Provides: freetype2=2.7.1, freetype2-infinality-ultimate,
Submitter: None
Maintainer: dobo
Last Packager: dobo
Votes: 459
Popularity: 5.402684
First Submitted: 2010-07-14 15:27
Last Updated: 2017-01-13 23:54

Required by (428)

Sources (10)

Latest Comments

alaskanarcher commented on 2017-04-10 23:54

I get this warning early in the package() step.

libtool: warning: remember to run 'libtool --finish /usr/lib'

And I get about 15 of these warnings during the package step.

libtool: warning: '/home/aslevy/aur/freetype2-infinality/src/freetype2/objs/' has not been installed in '/usr/lib'

Is this normal behavior?
Thank you

tomaszgasior commented on 2017-04-08 15:46

Can you create 32-bit multilib versions of your infinality packages?

dobo commented on 2017-02-16 14:55

Erm, after upgrading harfbuzz and recompiling this everything works. At least for me.

hpstg commented on 2017-02-16 13:48

Any way for this to be fixed/patched/maintained? The fonts really look better with it.

jaro3 commented on 2017-01-17 12:15

harfbuzz doesn't build :-( The only solution is to get rid of these unmaintained infinality fonts as described here:

HarfBuzz 1.4.1: test/shaping/test-suite.log

# TOTAL: 24
# PASS: 22
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/arabic-fallback-shaping

Running tests in ./tests/arabic-fallback-shaping.tests
Testing fonts/sha1sum/df768b9c257e0c9c35786c47cae15c46571d56be.ttf:U+0633,U+064F,U+0644,U+064E,U+0651,U+0627,U+0651,U+0650,U+0645,U+062A,U+06CC
Actual: [uni06CC.fina=10+1655|uni062A.medi=9+868|uni0645.init=8+1098|uni0650=2@189,0+0|uni0651=2@228,736+0|uni064E=2@967,1259+0|uni0651=2@1006,736+0|uni06440627.fina=2+1470|uni064F=0@558,-10+0|uni0633.init=0+1585]
Expected: [uni06CC.fina=10+1655|uni062A.medi=9+868|uni0645.init=8+1098|uni0650=2@221,0+0|uni0651=2@260,736+0|uni064E=2@935,1259+0|uni0651=2@974,736+0|uni06440627.fina=2+1470|uni064F=0@558,-10+0|uni0633.init=0+1585]
1 tests failed.
FAIL tests/arabic-fallback-shaping.tests (exit status: 1)

FAIL: tests/vertical

Running tests in ./tests/vertical.tests
Testing fonts/sha1sum/191826b9643e3f124d865d617ae609db6a2ce203.ttf:U+300C
Actual: [uni300C.vert=0@-448,-578+0,-1024]
Expected: [uni300C.vert=0@-512,-578+0,-1024]
Testing fonts/sha1sum/f9b1dd4dcb515e757789a22cb4241107746fd3d0.ttf:U+0041,U+0042
Actual: [gid1=0@-590,-2128+0,-2789|gid2=1@-601,-2125+0,-2789]
Expected: [gid1=0@-654,-2128+0,-2789|gid2=1@-665,-2125+0,-2789]
Testing fonts/sha1sum/f9b1dd4dcb515e757789a22cb4241107746fd3d0.ttf:U+0041,U+0042
2 tests failed.
FAIL tests/vertical.tests (exit status: 1)

==> ERROR: A failure occurred in check().

Ralf_Mardorf commented on 2017-01-15 16:09

To workaround the harfbuzz issue, you need to recompile harfbuzz.

$ sudo abs
$ sudo pacman -Syu
$ cp -ai /var/abs/extra/harfbuzz/ /tmp/
$ cd /tmp/harfbuzz/
$ makepkg -si

With nano you could edit the pkgrel, but it's not required, you could rebuild harfbuzz without editing anything, just rebuild it.

This is already explained by my comment from 2017-01-12.

Please use a forum to get help, the comments are inappropriate.

fausterjames commented on 2017-01-15 15:12

I'm here because I can't run some programs like deluge. Running deluge gets me :

> ImportError: /usr/lib/ undefined symbol: FT_Get_Var_Blend_Coordinates

When I post this on harfbuzz github they tell me that the bug isn't related to them but to this package freetype2-infinality as their package is build against the latest freetype2 package,

See this issue :

I also don't understand why you're able to install freetype2 and remove freetype2-infinality when I have this error message. I was able to replace fontconfig-infinality with fontconfig but it didn't help much with the main problem.

Ralf_Mardorf commented on 2017-01-15 14:23

freetype from official repositories and freetype2-infinality are in sync. What version do you expect?
The error message you get informs you about what you need to do. Doesn't it?
However, installing freetype2 could be done on my install, without such an issue.
The comments aren't the right place to request the kind of help you need.

[rocketmouse@archlinux ~]$ pacman -Si freetype2 | grep Ver
Version : 2.7.1-1
[rocketmouse@archlinux ~]$ grep freetype2-infinality /var/log/pacman.log | tail -1
[2017-01-14 12:22] [ALPM] upgraded freetype2-infinality (2.7-1 -> 2.7.1-1)
[rocketmouse@archlinux ~]$ sudo pacman -S freetype2
resolving dependencies...
looking for conflicting packages...
:: freetype2 and freetype2-infinality are in conflict. Remove freetype2-infinality? [y/N] y

Packages (2) freetype2-infinality-2.7.1-1 [removal] freetype2-2.7.1-1

Total Download Size: 2.56 MiB
Total Installed Size: 5.74 MiB
Net Upgrade Size: -0.60 MiB

:: Proceed with installation? [Y/n] n

Take a look at

replace it with

ebrilo commented on 2017-01-15 13:53

>Hi I read that Dobo wanted to update the package january 13 but there is still no update on 15

You gotta be kidding..

Last Updated: 2017-01-13 23:54

fausterjames commented on 2017-01-15 13:15

Hi I read that Dobo wanted to update the package january 13 but there is still no update on 15. Do you guys know if this package is going to be uptaded ? If not could you point me to how to uninstall it in order to install freetype2 as when I try to do so I get :

`:: freetype2 and freetype2-infinality are in conflict. Remove freetype2-infinality? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: fontconfig-infinality: removing freetype2-infinality breaks dependency 'freetype2-infinality'
:: grip-git: removing freetype2-infinality breaks dependency 'freetype2-infinality'`

Ralf_Mardorf commented on 2017-01-14 19:52

Read the comments!

This was several times explained by the comments.

Read the Wiki!

validpgpkeys is basic PKGBUILD knowledge, let alone that this topic was part of the latest checksum discussion.

Aco commented on 2017-01-14 18:30

what is wrong..

Wats Verifying source file signatures with gpg...
freetype-2.7.1.tar.bz2 ... FAILED (unknown public key C1A60EACE707FDA5)
freetype-doc-2.7.1.tar.bz2 ... FAILED (unknown public key C1A60EACE707FDA5)
ft2demos-2.7.1.tar.bz2 ... FAILED (unknown public key C1A60EACE707FDA5)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Makepkg was unable to build freetype2-infinality.

dobo commented on 2017-01-13 14:00

I will update tonight. I was quite busy last days.

ebrilo commented on 2017-01-12 18:25

>I don't know what you are discussing

We're discussing newely released freetype2 v. 2.7.1, wich is needed by updated harfbuzz.

Freetype2 v. 2.7.1 haven't yet been patched with infinality by it's maintainer (and looks like it will never be), plus original infinality site is long dead.

So some good guys yesterday did the maintainer's job here:

And we're currently talking about how to get this patched freetype2 to AUR in order to make the world perfect again.

Ralf_Mardorf commented on 2017-01-12 17:41

I don't know what you are discussing. Assuming it should be the harfbuzz issue, consider just to rebuild harfbuzz

$ sudo abs
$ sudo pacman -Syu
$ cp -ai /var/abs/extra/harfbuzz/ /tmp/
$ cd /tmp/harfbuzz/
$ makepkg -si

does the trick.

With nano I edited the pkgrel, but even this isn't required.

[rocketmouse@archlinux ~]$ pacman -Si harfbuzz{,-icu} | grep Ver
Version : 1.4.1-1
Version : 1.4.1-1
[rocketmouse@archlinux ~]$ pacman -Q harfbuzz{,-icu}
harfbuzz 1.4.1-2
harfbuzz-icu 1.4.1-2

Ok, now I see, official repositories provide 2.7.1 instead of 2.7, so it's not in sync anymore with the package from extra.

ebrilo commented on 2017-01-12 17:23

>Ask dobo :)

Looks like he's not going to do anything with it since 2016-11-29.. Orphan mb?

kokoko3k commented on 2017-01-12 11:51

> Will it be presented in aur?
Ask dobo :)

ebrilo commented on 2017-01-11 15:11

>I think we managed to make it work with 2.7.1
>Changes should stabilize soon, please check:

I've just installed it (from your github link) - works just fine. I'd say, it works perfectly. Will it be presented in aur? Just to keep it in order, you know..

And many thanks, man! I've already started becoming desperate breaking my eyes with soapy, smoky glyphs, rendered with standard freetype.

kokoko3k commented on 2017-01-11 11:53

I think we managed to make it work with 2.7.1
Changes should stabilize soon, please check:

Bunker commented on 2017-01-09 12:09


Thank you for the reply. Now I do have the problem that's listed below by nTia89. So the I'm supposed to do the downgrade.

However, if you get p*ssed off everytime some user, that maybe like me is rather new and asks a question that seems stupid to you, you should maybe ask if maintaining a package is something for you.

To explain I did skim the comments, but the one you are referring to, doesn't show until you choose show all comments.

I knew I had to import a key, but I did not know that I have to use the key that's shown as failed to import. That is my mistake I agree.

Ralf_Mardorf commented on 2017-01-09 07:19

Bunker commented on 2017-01-09 00:39
>If it is still needed as it listed as a dependency for
>It fails building because of gpg-key errors:
>==> Verifying source file signatures with gpg...
>freetype-2.7.tar.bz2 ... FAILED (unknown public key C1A60EACE707FDA5)
>freetype-doc-2.7.tar.bz2 ... FAILED (unknown public key
>C1A60EACE707FDA5) ft2demos-2.7.tar.bz2 ... FAILED (unknown public key
>C1A60EACE707FDA5) ==> ERROR: One or more PGP signatures could not be
>verified! ==> ERROR: Makepkg was unable to build freetype2-infinality.

You are completely uninterested to do anything yourself. You are neither willing to read the Arch Wikis, nor to google and worst of all, you are even not reading the comments. I already explained how to import a missing key. Should each user write the same comment and should we explain each user how to import a key? Is this the meaning of "user-centric"?

[rocketmouse@archlinux ~]$ gpg --keyserver hkp:// --recv-keys C1A60EACE707FDA5
gpg: key C1A60EACE707FDA5: "Werner Lemberg <>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

See also

Bunker commented on 2017-01-09 00:39

If it is still needed as it listed as a dependency for fontconfig-infinality.

It fails building because of gpg-key errors:

==> Verifying source file signatures with gpg...
freetype-2.7.tar.bz2 ... FAILED (unknown public key C1A60EACE707FDA5)
freetype-doc-2.7.tar.bz2 ... FAILED (unknown public key C1A60EACE707FDA5)
ft2demos-2.7.tar.bz2 ... FAILED (unknown public key C1A60EACE707FDA5)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Makepkg was unable to build freetype2-infinality.

digitalone commented on 2017-01-08 14:31

I think this packet is not needed anymore.

Scimmia commented on 2017-01-08 00:51

Safe? Not really. Partial updates are not supported; if things don't break now, they will in the future.

digitalone commented on 2017-01-07 23:57

harfbuzz upgrade breaked my system.
I downgraded to 1.3.4-1 version and now it works.
Is this safe?

cryzed commented on 2017-01-07 23:22

Rather bohoomil's fork needs to pull in the freetype2 2.7.1 changes which include "FT_Get_Var_Blend_Coordinates"; downgrading harfbuzz will sooner or later break your system. You'll probably have to go back to using an up-to-date (probably the official) version of freetype2 for now. It's really unfortunate that bohoomil seems to be MIA.

Curly commented on 2017-01-07 23:13

You need to downgrade harfbuzz to 1.3.4. A few packages don't work with the latest version.

nTia89 commented on 2017-01-07 21:22

Actually I am with packages from bohoomill repo.
I decided to switch to AUR one.
Compiling this package I get this error and the compilation process stops:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/ undefined reference to `FT_Get_Var_Blend_Coordinates'
collect2: error: ld returned 1 exit status
make: *** [Makefile:471: /tmp/yaourt-tmp-mattia/aur-freetype2-infinality/src/ft2demos-2.7/bin/ftbench] Error 1
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/ undefined reference to `FT_Get_Var_Blend_Coordinates'
collect2: error: ld returned 1 exit status
make: *** [Makefile:489: /tmp/yaourt-tmp-mattia/aur-freetype2-infinality/src/ft2demos-2.7/bin/ftdump] Error 1
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/ undefined reference to `FT_Get_Var_Blend_Coordinates'
collect2: error: ld returned 1 exit status
make: *** [Makefile:468: /tmp/yaourt-tmp-mattia/aur-freetype2-infinality/src/ft2demos-2.7/bin/ftlint] Error 1
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../lib/ undefined reference to `FT_Get_Var_Blend_Coordinates'
collect2: error: ld returned 1 exit status
make: *** [Makefile:504: /tmp/yaourt-tmp-mattia/aur-freetype2-infinality/src/ft2demos-2.7/bin/ttdebug] Error 1

Any suggestion?

lowsky commented on 2016-12-30 04:01

The PGP issue is one annoying problem. Users shouldn't need to search the web to find solutions to install software. We should be beyond such pettiness by this point.

This should work with an AUR helper like Yaourt simply because the average user is using that to install AUR packages.

Ralf_Mardorf commented on 2016-12-11 19:26

When became using AUR helpers a "standard" to use AUR?

Have you ever considered to read ?

murphy commented on 2016-12-11 18:55

This should work with a standard AUR update (yaourt,etc.) and it's currently breaking with a PGP integrity issue.

Understood that it's possible to add the keys, but since this is non-standard, there should be some sort of error after the package integrity fails stating both:

1) that it is expected
2) a suggestion on how to fix this (though the specific key is not necessarily needed).

andreab82 commented on 2016-11-30 15:45

DOH! Thanks lostkhaos!

lostkhaos commented on 2016-11-30 14:48

@andreab82 I believe that he just selected a server at random from the pool (perhaps one closeby to himself). You can use the command without specifying a keyserver in particular and the command will still work just fine (e.g. gpg --recv-keys [thekeyyouwant])

@Ralf_Mardorf I think your responses are pretty uncalled for. AUR comments aren't a support channel, sure, but it was a simple question with a simple answer. Your tone is one of the things that make people think Arch users are elitist jerks; telling someone to choose a different distro over a simple missing key is a bit dramatic.

Ralf_Mardorf commented on 2016-11-30 09:56

If you want to stay with Arch Linux, you need to do some research on your own.

Don't delete your comments, if you ask me to reply to your comments. Next time get your hands dirty, before you post a request.

Ralf_Mardorf commented on 2016-11-30 08:52

Please stop recommending idiotic non-solutions such as "--skippgpcheck".
The error messages informs you what to do. Inside the PKGBUILD you'll find this:


So one of several possibilities is running

gpg --keyserver hkp:// --recv-keys 58E0C111E39F5408C5D3EC76C1A60EACE707FDA5

to solve the issue. There are other ways to get the key, too.
If you need to spam the AUR comments with such a non-issue, then Arch Linux is not the appropriate Linux distribution for you. Please use another distro.

starlight commented on 2016-11-30 01:27

signature verification fails (multiple tries)

==> Verifying source file signatures with gpg...
freetype-2.7.tar.bz2 ... FAILED (error during signature verification)
freetype-doc-2.7.tar.bz2 ... FAILED (error during signature verification)
ft2demos-2.7.tar.bz2 ... FAILED (error during signature verification)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Makepkg was unable to build freetype2-infinality.

dobo commented on 2016-11-29 18:55

* Upgrade to 2.7.
* Sync with ABS PKGBUILD.
* Get patches from archfan.

mailme commented on 2016-08-27 19:03

Patches for 2.6.5 exist. You just haven't looked hard enough. ;)

Freso commented on 2016-08-24 12:47

.install file suggests to install lib32-freetype2-infinality, but there is no such package.

dobo commented on 2016-08-23 16:02

I can't update because ultimate patches aren't ready yet for 2.6.5.

Ralf_Mardorf commented on 2016-05-11 02:35

The answer to your question is given by the comments.

Perhaps I'm mistaken, since mareex isn't mentioned by the latest PKGBUILD.

Ralf_Mardorf commented on 2016-02-16 20:40

For your information, infinality.install mentions lib32-freetype2-infinality-ultimate, but no package with this name is available.

mareex commented on 2016-02-17 08:49

I changed this to lib32-freetype2-infinality (removed "ultimate" at the end). Although the package does not exist, I think someone should create it. I am on arm. So I cannot test that. Some one could just take these PKGBUILDS:

sekret commented on 2016-05-10 21:24

Your install script says

If you are using [multilib], please install/upgrade
lib32-freetype2-infinality, too.

But this package isn't provided here. Will you provide one or should someone else do it? I could do it, but I think it would make more sense if it had the same maintaner as this package here :-)

BlubbTec commented on 2016-05-09 18:46

Works fine now, thanks!

dobo commented on 2016-05-09 15:55

Updated, thanks for the info. Actually I haven't looked at e-mails and I've noticed those comments just after uploading fixed version..

AlK commented on 2016-05-09 13:15

Please update the PKGBUILD from the bohomill github repository[1] (he fixed the issue[2])


phant0m commented on 2016-05-09 09:19

As a quick fix I suggest the following:
provides=('' 'freetype2=$pkgver' 'freetype2-infinality' 'freetype2-infinality-ultimate')

Ralf_Mardorf commented on 2016-05-09 07:20

We need to edit the PKGBUILD for this version, most likely the maintainer will provide a fixed PKGBUILD for the next version.

$ pacman -Q freetype2-infinality; pacman -Qi freetype2-infinality | grep Provides
freetype2-infinality 2.6.3-2
Provides : freetype2=2.6.3 freetype2-infinality freetype2-infinality-ultimate

SpicyCat commented on 2016-05-09 06:39

I get a conflict when updating

looking for conflicting packages...
:: freetype2 and freetype2-infinality are in conflict. Remove freetype2-infinality? [y/N]

As @graysky said, maybe the PKGBUILD needs be updated.

BlubbTec commented on 2016-05-08 22:40

It seems that harfbuzz now depends on freetype2, and thus I get a conflict when updating:

:: freetype2 and freetype2-infinality are in conflict

Not sure what the solution is for this case.

graysky commented on 2016-05-08 13:27

Note that libbluray now requires so please mirror [extra]/freetype2's PKGBUILD and add the following:


dobo commented on 2016-04-19 15:09

Weird. Works for me.

snakeroot commented on 2016-04-18 15:48

File "" does not pass sha1sums validity check.

Synthead commented on 2016-03-22 18:37

Mentioning a package that doesn't exist should be treated as a bug as it is wrong information that is confusing to users.

mareex commented on 2016-02-17 08:49

I changed this to lib32-freetype2-infinality (removed "ultimate" at the end). Although the package does not exist, I think someone should create it. I am on arm. So I cannot test that. Some one could just take these PKGBUILDS:

Ralf_Mardorf commented on 2016-02-16 20:40

For your information, infinality.install mentions lib32-freetype2-infinality-ultimate, but no package with this name is available.

mareex commented on 2016-02-16 18:08

I've adopted this pkg because it has been orphan for a while now. If someone wants to have it just leave a comment.

Det commented on 2016-02-12 16:07

The package is orphan. Nobody wants to take it away?

It's filled with votes.

sekret commented on 2016-02-05 22:08

Could you please add 'armv7h' to the arch line? It builds just fine on my Raspberry Pi 2 :)

Most probably it builds just fine for armv6h too (e.g. Raspberry Pi 1), but I cannot confirm...

Iyyel commented on 2016-01-15 13:41

Hi. I'm having the same problem as jperry down below. Any tips or tricks?

jperry commented on 2015-11-14 21:37

EDIT: it worked fine with makepkg, just not with yaourt. Something funny going on. Feel free to ignore.

Hi, the freetype source package (freetype-2.6.tar.bz2) isn't passing the validity check. It must have been updated.

ventieldopje commented on 2015-09-01 23:19

@iuseakeyboard, because if you look closely you'll see it hasn't been maintained since 2013. At that time 2.4.12 was the newest version available, now today that is really really old. Freetype 2.6 is the newest available and thanks to bohoomil the patches also work for this version.

Have a look on his site for a pre-built binary repository if you're more comfortable using that.

iuseakeyboard commented on 2015-09-01 21:58

According to the latest version is 2.4.12. The "old package" is already 2.4.12. Why are we "upgrading" to boohomil's version? What am I missing here?

ventieldopje commented on 2015-08-31 19:17

Don't know about HiDPI but it's easy to install and try. I notice a _huge_ improvement on my 27" 1440p screen, no fringing, no aliasing and super sharp. Simply can't be done without these patches.

denspirit commented on 2015-08-31 17:53

Any visible visual improvements using this package on HiDPI screens? Looking for opinion.

ventieldopje commented on 2015-08-31 17:22

Adopted the package and built it with the latest infinality patches and freetype version. fontconfig-infinality will be updated shortly.

Marcel_K commented on 2015-07-28 23:47

"The website is temporarily in static offline mode.
Only a very limited set of project pages are available until the main website returns to service."

dkasak commented on 2015-07-28 23:39

freetype-2.4.12.tar.bz2 fails the checksum check.

jaro3 commented on 2015-05-11 01:07

There is a bug in the latest release which prevents build of some packages:

FT_Get_X11_Font_Format is defined in freetype2/ftxf86.h, but in infinality, it's defined in freetype2/ftfntfmt.h.

See e.g. HERE:

hadrons123 commented on 2015-01-23 02:19

I am going to fix only freetype security patches for this package and follow RHEL7 for fixes only if its necesary since the freetype version is close to RHEL7.

thorion commented on 2014-04-09 11:17

@Jristz The upstream for this package is released at This package gives the latest version of infinality, which is not yet caught up to the latest version of freetype2.

Marcel_K commented on 2013-10-16 15:08

To all out-of-date-flaggers: please read Shanto's comment of 2013-05-11 15:35.

Jristz commented on 2013-10-15 09:35

@falcongg maybe because freetype2 2.5.0 is on extra??

Anonymous comment on 2013-07-27 08:20

Why in the world this package is flagged as outdated?!

Anonymous comment on 2013-05-29 13:13

@nuc - Probably because in my makepkg.conf I needed to put --user-agent "Mozilla/4.0" for some package I forget which one... Hmm that would explain it I guess.

curl -L --user-agent "Mozilla/4.0"

Thanks for making me realize.

nuc commented on 2013-05-28 01:05

@dreur: LOL how could this AUR packag even work for me??

Anonymous comment on 2013-05-28 01:03

Fixed PKGBUILD: source file for freetype was downloading a sourceforge html

New URL:${pkgver}/freetype-${pkgver}.tar.bz2


nuc commented on 2013-05-16 01:50


nuc commented on 2013-05-16 01:45

it has appeared freetype-infinality-2.4.12-20130514_01-x86_64.tar.bz2

Shanto commented on 2013-05-11 15:35

Please stop flagging this package by looking at vanilla FreeType2 release schedule. This (FreeType2-INFINALITY) package will get updated ONLY when a new patch (against a new FT2 release) appears at

lrm commented on 2013-01-22 21:01

Please disregard my out of date flag. My error. The download was failing due to bad flags in the makepkg DLAGENT (not following redirects). The package is fine. My apologies.

Marcel_K commented on 2013-01-22 17:06

@lrm: Strange, it worked for me.

lrm commented on 2013-01-22 16:26

Failing checksum verification.

w0ng commented on 2013-01-11 23:37

==> Validating source files with md5sums...
freetype-2.4.11.tar.bz2 ... FAILED
freetype-infinality-2.4.11-20130104_04-x86_64.tar.bz2 ... Passed
freetype-2.2.1-enable-valid.patch ... Passed
==> ERROR: One or more files did not pass the validity check!


wolftankk commented on 2013-01-08 04:27

2013-01-04 – Update to latest Freetype version 2.4.11

thestinger commented on 2012-12-22 14:47

@initzero: The subpixel hinting support is now upstream (and enabled in the package in [testing]), but there are additional patches included with this that aren't (yet!).

Anonymous comment on 2012-12-22 13:29

It's now included in upstream!

at include/freetype/config/ftoption.h

Jristz commented on 2012-12-21 18:07

the freetype2 in extra was update to 2.4.11-2
this mean that this need update too??

Anonymous comment on 2012-10-02 04:38

Hello! Does any one know whether we still need a cairo wich respect-fontconfig patch? It seems the patch hasn't been merged upstream. But only place on aur has this patch is cairo-ubuntu, which relys on freetype-ubuntu...

Anonymous comment on 2012-08-18 20:16

@graysky - My mistake. I had an old .zshrc where I had export GNUMAKE=gnumake set. Once I deleted that line everything compiled ok. Thanks for the help.

graysky commented on 2012-08-18 10:51

@rodyaj - No problems here. Have you tried to compile in a clean chroot? I'm guessing you're missing something on your system or have a bad conf file somewhere along the line.

Anonymous comment on 2012-08-18 03:26

Error trying to install 2.4.10-1:

GNU make (>= 3.80) or makepp (>= 1.19) is required to build FreeType2.
Please try
`GNUMAKE=<GNU make command name> ./configure'.
or >&2
`GNUMAKE="makepp --norc-substitution" ./configure'.

kvasthval commented on 2012-08-12 12:45

Am I the only one getting pagefaults in WINE with this installed? Could be related to the 32-bit libraries though, but there are no problems whatsoever with the vanilla freetype2 packages...

lazx888 commented on 2012-06-19 15:13

Having some trouble with some terminus (terminus-font-ttf) characters being cut off - any ideas on how to fix this?

Anonymous comment on 2012-06-19 14:32

About those newlines in bash array. That's probably from me. To me, they are neither extra nor ugly. Individual elements would be fine in one line, only if they are short, like 'foobar' or 'barfoo'. Longer elements certainly look better on a line of their own. It is also cleaner in a diff.

Huulivoide commented on 2012-06-19 14:11

Usually it is unneeded to copy the source to a secondary -build directory.
This only the case for git/svn/bzr/... packages as building in the same
directory will make the repository unclean possibly preventing further
updates, without making a whole new checkout/clone of the repository all
over again. Cmake based projects also usually have build directory as
usually cmake based projects support building outside the source directory,
unlike automake based ones. This keeps the sourcecode folder itself clean
from the compiled binary files.

Also adding few extra newlines to here and there, would improve the
readability of the PKGBUILD. Another this is also your
'foobar' 'barfoo'
parts. Why not just simply write ('foobar' 'barfoo') ? Why the extra/ugly
newlines in those? I'm refering to optdepends and source fields.

Anonymous comment on 2012-06-18 23:25

Never mind, got it. Turns out base-devel was uninstalled on my computer, so I just installed it again.

Anonymous comment on 2012-06-18 20:30

I have multilib-devel and fakeroot installed.

Shanto commented on 2012-06-18 19:52

@bl3ndy do you have the devel packages installed?

Anonymous comment on 2012-06-18 19:33

I'm getting this error whenever I try to update to 2.4.10:

"==> Starting build()...
/tmp/yaourt-tmp-user/aur-freetype2-infinality/./PKGBUILD: line 32: patch: command not found"

Shanto commented on 2012-06-18 07:54

Updated to 2.4.10 - Please report (packaging) issues, if any.

Shanto commented on 2012-06-18 07:44

Links to patches fixed.

Anonymous comment on 2012-06-18 04:19

We can't build this package anymore because both bug35833.patch and bug35847.patch are not available (404 error).


ressler commented on 2012-04-23 20:57

@graysky: Perhaps I pushed the button incorrectly since it wasn't the reference to the upstream package that was out of date. There are a couple of patches needed to upstream to make it cooperate with preview-latex (part of auctex). These patches had been applied to freetype2 in Extra; my pushing the Out-of-Date button was a request to have them applied to the infinality version as well. Shanto has graciously applied those patches and all is now well. I apologize if that wasn't quite the right way to go about it. Thank you all.

Shanto commented on 2012-04-22 00:55

Patches added.

graysky commented on 2012-04-20 01:13

Why out of date?

ressler commented on 2012-04-16 20:33

The main freetype2 package is at build 2 which includes several patches to fix its behavior with gs. This is needed to get preview-latex working. Any chance of adding those patches to the infinality build?

thestinger commented on 2012-04-14 07:53

@alexcortes: because the patch was accepted upstream

alexcortes commented on 2012-04-14 03:44

The libxft-lcd is not more in AUR. :-(

hadrons123 commented on 2012-03-19 17:06

Could please anyone create a pkgbuild in AUR with patch for Chromium which Infinality has created to fix font rendering in Chromium

I want it too...

graysky commented on 2012-03-13 12:31

Shanto - you gotta flag the pkg out of date, not just post a comment or else the maintainer may not see your comment.

Shanto commented on 2012-03-12 23:36

Out-of-date? Please follow

Anonymous comment on 2012-03-11 10:53

Hello! Could please anyone create a pkgbuild in AUR with patch for Chromium which Infinality has created to fix font rendering in Chromium > 13 versions. bug page topic on forum and patches

Shanto commented on 2012-02-20 17:26

@xlogo I guess I disowned that one in error. Adopted now. Thanks!

Anonymous comment on 2012-02-20 14:30

fontconfig-infinality appears to be orphaned. Are you going to maintain it since is a dependency to freetype2-infinality?

Kaurin commented on 2012-02-19 17:29

From paintown's devs:
<jonrafkind> you should say that glyphs are not read correctly using this package

Kaurin commented on 2012-02-19 17:28

This package breaks the game "paintown" that is in the community repo. I probably had this package installed as a dep for something else, and completely forgot about it. Devs from paintown helped me debug a white screen bug. After digging around, they suspected it had something to do with freetype. When i checked my packages, i noticed that i had this package installed instead of vanilla freetype2. After switching to freetype2, the problem was gone and the game works.

Kaurin commented on 2012-02-19 17:25

This package breaks paintown

wodim commented on 2012-02-16 02:56

It is up to date.

0rAX0 commented on 2012-01-30 09:59

Hey, I said before that Nautilus crashes when browsing SVG icons, I investigated the issue. This is the complete error:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xaaf1fb40 (LWP 27764)]
0xb6d00fb7 in _lcd_stem_align (bitmap=0xb41566cc, mode=FT_RENDER_MODE_LCD,
slot=0xb4156680, translate_value=0xaaf1b528,
scale_value=0xaaf1b52c, alignment_strength=100, fitting_strength=100,
No such file or directory.

Any ideas?

hadrons123 commented on 2012-01-21 19:08

I think its uptodate.

hadrons123 commented on 2012-01-21 19:08

I think its uptodate.

Shanto commented on 2011-12-17 14:00

@snuo I'd rather wait for a week (or less) for the infinality author to adopt it.

snuo commented on 2011-12-17 05:25

Here's a link for notlostyet's tarball:
(It's Dropbox, so there's no silly 60sec wait.)

It installed without a hitch!

Anonymous comment on 2011-12-14 20:56

Current version (20111125_1) is causing crashes in both Chromium 16 and Firefox 8. It happens, for example, on when scrolling the bottom-right frame using the scrollbar (not the scroll-wheel on your mouse).

Discussed here:

Tarball with a patch and updated PKGBUILD here:

Shanto commented on 2011-12-09 00:01

@cstadegaart, @forkboy: Sorry.. That was me. I guess, I forgot to link post-install to post-upgrade (containing the big message) while updating infinality instructions recently (Xresources no more needed...). (Think a Cut followed by forgotten Paste operation). Thanks forkboy for pointing this out - Fixed this earlier today.

Anonymous comment on 2011-12-08 22:11

@forkboy Well that may be the reason. But is that normal?

Anonymous comment on 2011-12-08 14:20

post-installation message doesn't show on first install.

Anonymous comment on 2011-12-06 06:55

Damn! I even double checked the installation for any messages to make sure there isn't one to prevent a silly post. But after your paste I tried again and hocus pocus, I see it too. Well at least I know that the way I have been looking for post installation messages was the right one, but I'm still confused how I managed to overlook this message two times. Thanks everybody for your feedback and sorry for any inconvenience!

Shanto commented on 2011-12-05 18:25


Anonymous comment on 2011-12-05 17:21

No need to get hostile. It is the Arch Way not to put a default symlink in conf.d or to automatically run the script. That was not what I was suggesting and in my opinion this should not be implemented.

What I ran into was the fact that I didn't see a post install or upgrade message when installing infinality. How and when should I had read it? When did I miss it? If it is a file I have to look up myself --and possibly this is the default method for many AUR packages out there-- how have I managed these past few years :P without reading these messages. Help me out here.

Jib commented on 2011-12-05 08:52

Please no symlink; that's not the Arch way. And some users might want to stick with local.conf.
As you said, users _should_ read install msg.

reflexing commented on 2011-12-05 08:31

@Shanto: If somebody decided to install unsupported package, he knows what he's doing. He decided to install it _already_, so he want it working immediately, doesn't he?

Shanto commented on 2011-12-05 01:12

Messages about /etc/profile.d/ and /etc/fonts/conf.avail/52-infinality.conf are there in post_install/post_upgrade. If you didn't watch that's not my fault - I don't think I have much to do there.

How many of you would like this package to put symlink inside /etc/fonts/cond.d by default? If I get enough number of positive opinion, I will consider doing so. (I personally prefer that but I want to respect majority opinion here.)

rtimush commented on 2011-12-04 20:33

I agree with cstadegaart, in my opinion a link to conf.d should be a default option.

Anonymous comment on 2011-12-04 18:18

I didn't get a post-installation message (or I wasn't watching the right monitor) for running /etc/profile.d/ and linking /etc/fonts/conf.avail/52-infinality.conf to ../conf.d/. Would be helpful for people who don't know how to configure the infinality patch properly.

Yegorius commented on 2011-11-29 15:56

"~/.Xresources" is not needed any more.

Anonymous comment on 2011-11-26 09:14

Another new release :D

falconindy commented on 2011-11-24 02:16

@Shanto: Well, you don't. But given the scope of the package and the fact that you're applying (only 3) patches provided by an "upstream", I think it's fine. You'll clearly see any reject and where it happened.

@Yegorius: No, the point is to _not_ iterate over ls ( If you insist on using a loop, use a glob, i.e. for patch in *.patch; do patch -Np1 < "$patch"; done

adrianx commented on 2011-11-23 21:26

@jskier A slight change to /etc/fonts/conf.d/31-cantarell.conf has made Cantarell fonts appear again.

Edit 31-cantarell.conf and change the binding from "weak" to "strong". See

adrianx commented on 2011-11-23 21:25

@jskier A slight change to /etc/fonts/conf.d/31-cantarell.conf has made Cantarell fonts appear again.

Edit 31-cantarell.conf and change the binding from "weak" to "strong". See

Shanto commented on 2011-11-23 14:12

falconindy@ Thanks! Updated this in the way you like, but without bumping $pkgrel because the resulting package doesn't give you anything new. However, I have a question for you. Having all patch files concatenated together, how do you tell exactly which patch file failed after a patch failure (in future, with later versions of freetype2 and/or infinality)?

Yegorius commented on 2011-11-23 14:06

Even simplier:
local pf
for pf in $(ls ${srcdir}/freetype-*.patch); do
patch -Np1 -i ${pf}

reflexing commented on 2011-11-23 04:33

@falconindy can't see spoiled bash scripts, can you :)

falconindy commented on 2011-11-22 22:21

Can we get some sanity in this PKGBUILD? I really dislike seeing iteration over ls when the proper syntax is fewer keystrokes...

Anonymous comment on 2011-11-22 21:34

The issue of tiny fonts in certain places was fixed for me by setting INFINALITY_FT_AUTOHINT_INCREASE_GLYPH_HEIGHTS to false. There must be some weird bug, because what happens in some cases is actually the opposite of the intended effect.

Anonymous comment on 2011-11-22 17:54

Hey, a heads-up: update you /etc/profile.d/ with infinality-settings.pacnew! Some old settings are no longer needed, and there are some new ones.

jskier commented on 2011-11-22 14:20

Re: cantarell fonts, going back to plain freetype2 package fixes things, so it probably is infinality.

jskier commented on 2011-11-22 13:18

Cantarell fonts are replaced with Arial for me. Are there new font substitutions or is this another issue?

fettouhi commented on 2011-11-21 11:03

@einhard: Yeah I use KDE. fixed the problem with adding the symlink to /etc/fonts/conf.avail/52-infinality.conf.

Anonymous comment on 2011-11-21 11:00

@fettouhi In /etc/profile.d/ change SET_XFT_SETTINGS to no (SET_XFT_SETTINGS=no) or adjust your fonts other way with system/DE settings. Do you use KDE?

Shanto commented on 2011-11-21 10:21

Added missing official depends (bzip2, sh). Improved post-install message with example commands.

reflexing commented on 2011-11-21 08:40

@fettouhi did you make a symlink of /etc/fonts/conf.avail/52-infinality.conf? Cite from post-install:
You are advised to make symlink of this file either at "/etc/fonts/conf.d/" to enable it system-wide, or at "~/.fonts.conf.d/

fettouhi commented on 2011-11-21 08:37

Is anybody else having issues with the new infinality patches. My fonts are a complete mess now. Suddenly I have very very tiny fonts in various places and others are normal.

Shanto commented on 2011-11-20 21:14

provides=("freetype2=$pkgver") added back.

reflexing commented on 2011-11-20 21:03

SHanto please, change provides= to provides=("freetype2=$pkgver")

reflexing commented on 2011-11-20 21:02

@SHanto please, change provides= to provides=("lib32-freetype2=$pkgver")

fettouhi commented on 2011-11-20 20:58

I'm getting error now saying

:: fontconfig: needs freetype2>=2.3.11
error: failed installing the package

fettouhi commented on 2011-11-20 20:58

I'm getting error now saying

:: fontconfig: needs freetype2>=2.3.11
error: failed installing the package

Shanto commented on 2011-11-20 20:48

@reflexing: Done

reflexing commented on 2011-11-20 20:41

@Shanto Please, change "install=('infinality.install')" string to "install=infinality.install" in PKGBUILD due to changed handling in Pacman 4.

wodim commented on 2011-11-20 20:32

Thank you very much Shanto :))) Can you update the lib32 version as well?

Shanto commented on 2011-11-20 20:31

@wodim: Updated!

wodim commented on 2011-11-20 20:11
20111120, released today.

Shanto commented on 2011-11-20 20:10

@wodim exactly which version do you think is new (as of now)?

wodim commented on 2011-11-20 14:29

Are you working in the new version?

Shanto commented on 2011-11-20 13:08


fettouhi commented on 2011-11-20 13:07

I'm disowning this because I don't have the time to maintain it.

wodim commented on 2011-11-20 13:00

Please update.

Anonymous comment on 2011-11-20 09:10

Or rahter

Anonymous comment on 2011-11-20 09:08

New release!

fettouhi commented on 2011-11-18 10:34

Updated to 2.4.8!

eworm commented on 2011-10-28 14:38

Sorry, rebuilt about 50 AUR packages to get gpg signatures today... Some of them break with pacman 4.0. Did not notice that someone else reported it before my post...

SanskritFritz commented on 2011-10-28 14:27

Hmm, second thought, that was probably a bot, lol

SanskritFritz commented on 2011-10-28 14:26

eworm: you are the third to say that. read before post.

eworm commented on 2011-10-28 14:21

Brackets around the install file break makepkg from pacman 4.0. Please use install=infinality.install! Thanks a lot!

fettouhi commented on 2011-10-27 12:12

I'm using KDE4, e.g. Dolphin so I don't know about Nautilus.

@trontonic: I'll fix that when pacman 4 leaves testing.

xyproto commented on 2011-10-27 11:14

please change install=('infinality.install') to just install=infinality.install

xyproto commented on 2011-10-27 11:13

please change install=(infinality.install) to just install=infinality.install

0rAX0 commented on 2011-10-27 10:49

No problem. BTW, does it crash your Nautilus(if you use it) when browsing SVG icons?

fettouhi commented on 2011-10-27 10:48

@rAX: I'll fix that when pacman 4 leaves testing.

SanskritFritz commented on 2011-10-27 08:48

Woa, that will be a huge issue here on AUR...

0rAX0 commented on 2011-10-27 08:38

Pacman 4 don't work with install=('...'). It needs to be install=...

fettouhi commented on 2011-10-27 05:48

Adopted and updated! Let me know how this works :).

Anonymous comment on 2011-10-27 05:11

I disowned the infinality packages (this one and the lib32 variant). Anybody interested please pick it up. Thanks.

0rAX0 commented on 2011-09-12 13:32

Nautilus segfaults with this package(or the git version) installed, but only when browsing a directory of SVG's (48px icons). Try to browse the Elementary set for example.

gborzi commented on 2011-08-12 10:49

patch is in the base-devel group, so it should not be listed among build dependencies.

Anonymous comment on 2011-08-12 00:32

needs patch as build dependency :)

fettouhi commented on 2011-07-30 14:04

2.4.6 is out in [extra]!

Anonymous comment on 2011-07-27 04:04

You don't need other packages. You might need to recompile firefox 5 by yourself for it to use the system freetype2 lib.

Anonymous comment on 2011-07-20 11:20

Maybe better to create fontconfig-infinality package with ?

And what other packages must be installed with freetype2-infinality for excellent result? (Like freetype2-ubuntu, fontconfig-ubuntu, libxft-ubuntu, cairo-ubuntu)

In my case, after installing freetype2-infinality and fontconfig, libxft, cairo in Firefox 5 fonts are ugly :(

Anonymous comment on 2011-07-14 05:11

Hi folks, I'm away and can't test the new version yet. I'll upload a new version as soon as I get back to my computer next week.

mschmoelzer commented on 2011-06-11 15:55

I just uploaded a package that builds freetype2 from git with the latest infinality patch [1]. It is based upon Case's PKGBUILD and the PKGBUILD for this package. A lib32 version is also available [2].


Anonymous comment on 2011-06-10 01:40

I'm no expert on PKBUILDs, but here's a quick PKGBUILD for the latest Infinality patch that seems to work for me just fine:

Try on your own risk, of course. If somebody wants to make it into separate AUR package, go ahead, I'd do that but I would suck at maintaining it ;)

Anonymous comment on 2011-06-10 00:00

I'd like to make this package in sync with extra (or testing, if new feature requires), but git is just too risky for daily use. Since the current patch is for git only, I don't want to take the risk. Let's just wait for the next version of freetype. The other problem is I might not have time to maintain it. If you have a workable PKGBUILD for git version of this package, feel free to upload to AUR for others to try and report problems.

Marcel_K commented on 2011-06-07 15:36

@Hilinus: can you please share your changes or PKGBUILD with us? Or upload a GIT version to the AUR?

Hilinus commented on 2011-06-05 15:43

Hi. I have made a dirty hack on this PKGBUILD, making it fetch freetype from git and, as for now, the only patch that fails is the one for the null pointer. Other ones work fine, but, as you said, you'll never know when a commit breaks something. Definitely, doing a -git version of this package seems a good idea, and remember to include the updated infinality-settings, as it fixes the problem with dots and commas while using different locales.

Keep up the good work :P

Anonymous comment on 2011-06-05 14:41

I'm afraid it's a little bit unmanageable as a patch to git repository. If the git repo changes in some way that breaks the patch, we'll have a hard time fixing it or waiting for infinality to fix it. Either way, we will have a lot more complaints from our users here. I can try to make a git package specifically for the repo status on the 4th of June. If anybody wants to try on the bleeding edge, I'll try to make a PKGBUILD soon when I have time.

Anonymous comment on 2011-06-05 14:05

Technically this package isn't out of date.

But Infinality has updated his patches for freetype-git. Please see

Marcel_K commented on 2011-04-05 11:47

Interesting; I'm trying to reproduce your issue using [1], but on my screen the font looks quite different [2]. It looks like a hinting problem.

Just to be sure, did you install fontconfig-lcd? And which settings did you enable in /etc/fonts/conf.d? Mine looks like [3]. And do you have anything in local.conf and/or ~/.fonts.conf?


ushimitsudoki commented on 2011-04-05 01:21

Sorry, I should clarify that I have in my environment, and the settings seem to be what the discussion recommended:

11e-2 22e-2 38e-2 22e-2 11e-2

I still observe the strange "e" with Trebuchet MS.

ushimitsudoki commented on 2011-04-04 22:39

Here is a comparison of the font issues[1]:

Note the strange looking "e" in the middle line of text. This is the default font size on many web sites. Note that one size up and one size down look fine.

Here is the developer addressing the issue upstream[2], where he asserts the aforementioned patch is the solution.


Marcel_K commented on 2011-04-04 20:36

BTW, what's the problem with the 'e' in Trebuchet MS? I don't perceive a problem with that font.

Anonymous comment on 2011-04-04 19:09

The patch "freetype-filter-envvar-fix-20101117-1.patch" has nothing to do with 'the strange "e" in MS Trebuchet font'. As discussed before (previous comments), if you use the bundled in this pkg and INFINALITY_FT_FILTER_PARAMS="11e-2 22e-2 38e-2 22e-2 11e-2" is correctly set using this scientific notation of floating numbers, you won't need the patch to cover up or toss away the wrongly parsed INFINALITY_FT_FILTER_PARAMS. However, you should report 'the strange "e" in MS Trebuchet font' upstream if it is not known.

ushimitsudoki commented on 2011-04-03 22:51

This needs to be updated to add in some more recent patches:

This fixes the strange "e" in MS Trebuchet font.

SanskritFritz commented on 2011-01-21 06:50

firefox-pgo: Well, I've tried it once, but it didn't feel snappier. Probably some long operations would finish faster. YMMV, just try it, it works flawlessly.

memeplex commented on 2011-01-21 06:33

Thanks SanskritFritz, I was just doing that (and it's 3:30 AM here). I'm in my way to becoming an expert on the subject for a couple of days and that completely against my will. Do you know if pgo performance is notoriously better?

SanskritFritz commented on 2011-01-21 06:28

Stock Firefox package is compiled without --system_cairo. You need to compile firefox-pgo, or xulrunner-system-cairo from the AUR.

memeplex commented on 2011-01-21 02:41

Update: the problem happens just with firefox, not matter what font I configure. Other apps honour INFINALITY_FT_FILTER_PARAMS. I'm lost here.

memeplex commented on 2011-01-21 01:32

I can't get INFINALITY_FT_FILTER_PARAMS working. I've tried every configuration imaginable. Sourcing, exporting, even restarting X from an adecuate environment. But the rendering is always exactly the same (compared dot by dot with help from xmag). Also, using the infinality local.conf or not is irrelevant to the point. Any clue?

thestinger commented on 2010-12-16 03:44

@tinhtruong, base-devel is supposed to be installed to build any package, so stuff in that group doesn't go in makedepends

tinhtruong commented on 2010-12-16 03:27

Please add 'make' as makedepends.

Alibloke commented on 2010-12-15 11:19

I'm gobsmacked at the difference these patches make to freetype. Thanks jxy!

Anonymous comment on 2010-12-12 15:42

If any clyde users receive the following errors, use `rm -rf /tmp/clyde-$(whoami)/freetype2-infinality/` to clear clyde's cached copy and try again.

patching file src/truetype/ttinterp.h
patching file src/truetype/ttobjs.h
The next patch would create the file src/truetype/ttsubpixel.c,
which already exists! Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file src/truetype/ttsubpixel.h,
which already exists! Skipping patch.
1 out of 1 hunk ignored
error: Build failed

Anonymous comment on 2010-12-12 02:58

Added a patch proposed by goddesse. Please see

gborzi commented on 2010-12-11 16:27

Jib's PKGBUILD works fine for me too. Thanks Jib.

Jib commented on 2010-12-11 13:17

Try this PKGBUILD:
Works fine for me with PDFs and Libreoffice.

Jib commented on 2010-12-11 07:39

Here is a PKGBUILD with freetype-2.4.3 and the patches brebs mentionned in thread
Works OK with pdf and Libreoffice

Jib commented on 2010-12-11 07:38

Here is a PKGBUILD with freetype-2.4.3 and the patches brebs mentionned in thread

frabjous commented on 2010-12-10 16:30

This still seems to create segfaults in poppler-based PDF viewers. Any chance of trying to implement the suggestion given in this thread, jxy?

Anonymous comment on 2010-12-10 15:36

Please report bugs you've found to Thanks.

pablox commented on 2010-12-10 15:03

Yup, that's true. Libreoffice crashes when you make a font bold :S.

Anonymous comment on 2010-12-10 06:39

This package cause libreoffice crash!

kvasthval commented on 2010-12-03 12:01

Stringman, you are my hero!

Anonymous comment on 2010-12-02 16:59

@stringman, a BRILLIANT idea! Thanks.

Anonymous comment on 2010-12-02 16:21

I managed to fixed the missing fonts by applying a workaround - changing the float values to scienific notation, ie:
export INFINALITY_FT_FILTER_PARAMS="11e-2 22e-2 38e-2 22e-2 11e-2"

While this is not very pretty, it seems to do the trick.

Anonymous comment on 2010-12-01 04:41

@kvasthval, it is actually not that simple. If you read the patch, which is really short, you'll know it only deals with INFINALITY_FT_FILTER_PARAMS. Any unreasonable value for INFINALITY_FT_PSEUDO_GAMMA has already been dealt with in the main infinality patch set. Inconsistency will rise, because not all of your programs use the same locale, which is why some people see the fonts on a certain set of programs but not others. After the patch, those programs that have been displaying fonts will display fonts as before, while those other programs that have been not showing fonts will display fonts as if INFINALITY_FT_FILTER_PARAMS and INFINALITY_FT_PSEUDO_GAMMA been set as default values.

I'm actually not sure what is the best for you guys suffering from the bug. Let's hope Infinality will make a new sets of patch available soon. However, if more people believe it is better with the 20101117 patch, I can include it in the PKGBUILD.

kvasthval commented on 2010-12-01 01:27

Oh, Australia, Asia and United Kingdom are using it too - I didn't know that. However, we are (hopefully) just talking about a few weeks at max before Infinality gets it fixed once and for all.

@jxe: That sounds great. I thought the patch had the same effect as unsetting these two variables for everyone -- no fonts versus two malfunctioning variables, I think I know what to choose. Anyway, thanks in advance for helping us poor Europeans out.

thestinger commented on 2010-11-30 22:10

@kvasthval, the US is hardly the only english speaking nation and plenty of other countries that use different languages also use a point as the decimal marker - lets wait for a proper solution as people have been working out already

thestinger commented on 2010-11-30 22:10

@kvasthval, the US is hardly the only english speaking nation and plenty of other countries use a point as the decimal marker - lets wait for a proper solution as people have been working out already

Anonymous comment on 2010-11-30 22:08

One fact I really want to make it known---though most of you don't want to read comments even if you are using AUR packages, which is already risky and irresponsible for yourself---that the 20101117 patch will not affect whoever are SEEING the fonts. It will show a little uglier fonts for YOU who cannot see the fonts without the patch, because INFINALITY_FT_FILTER_PARAMS will be Freetype's default, and INFINALITY_FT_PSEUDO_GAMMA will default to no gamma correction.

@kvasthval, I've not been selfish by not applying the patch, because the patch does not affect me at all. All I wanted was preventing some irresponsible users from popping up and claiming the two variables not giving them the expected or consistent behavior. And it is not only the Americans who use '.' for decimal mark.

Nevertheless, I'll put the 20101117 patch in the PKGBUILD tonight when I have time, if nobody objects.

kvasthval commented on 2010-11-30 21:55

Alright, you're using another patching method than I thought, however the following is a working example of my solution:

kvasthval commented on 2010-11-30 21:28

I'm well aware of the current solutions, but at the moment you're breaking the whole graphical interface for every single non-American (way more than 50% of all Arch users, I suppose) unless they check these package comments, which IMHO is pretty damn selfish.
Adding the patch would fix it for everyone at the expense of a little uglier fonts for you - an extremely simple solution would be to add a variable like _I_USE_DOT_DELIMITERS="n" in the PKGBUILD which easily could be changed to "y" for Americans, in which case the 20101117 patch file could be deleted before the patching loop.

I have been waiting for an update to this package ever since the fix/hack was released on November 17th, but haven't got around to comment before receiving my ~10th "my fonts are gone" phone call yesterday.

Anonymous comment on 2010-11-30 00:14

@kvasthval, please read the comments before yours here and everything in If you still thinks it is good with that, you can put the patch at the end of source array in PKGBUILD, and then add the md5sum.

I don't really consider the patch is a fix, because it is equivalent to unset INFINALITY_FT_FILTER_PARAMS for you guys who do not use '.' as the standard decimal mark. In addition, the patch does not filter out INFINALITY_FT_PSEUDO_GAMMA.

Four choices for you who have the issue of invisible fonts.

1. Add "" to the source array in PKGBUILD and add the md5sum to the md5sum array, then recompile.

2. Uncomment INFINALITY_FT_PSEUDO_GAMMA and INFINALITY_FT_FILTER_PARAMS lines in the file /etc/profile.d/

3. Change your system locale, and the language settings of all the individual programs, to use a locale that use '.' as the decimal mark.

4. Try to put "LC_NUMERIC=C" in the file /etc/profile.d/ (It may or may not work, depend on your other settings.)

kvasthval commented on 2010-11-29 15:46

Fix released:

Anonymous comment on 2010-11-20 01:25

If you want to just get things to appear in all programs, try this:

# Comment these out, and unset them:

I think that should get things at least tolerable until I release an updated version!

Anonymous comment on 2010-11-20 00:39

Oh, i just removed /etc/profile.d/, and everything works, but it's ugly solution (

Jib commented on 2010-11-19 14:46

Just replacing the dot with a comma in not enough: still no fonts in Rhythmbox.

Jib commented on 2010-11-19 14:21

Just changing the point to comma is not enough: still no fonts in Rhythmbox.

TemplarGR commented on 2010-11-19 05:43

I believe simply changing the floating point values to integer, multiplied by 10 or 100, then turned inside the code to floating point again(or simply handling them as integers) could also do the trick(as jxy mentioned). It depends on what is less work.

tomprogrammer commented on 2010-11-18 22:37

first, excuse me for posting everytime the same, that was not my mind.

I prepared a patch making the parsing locale-independent, i fact only the two sscanf() statements must be replaced with the locale editions (sscanf_l) and as locale i use C which on every system results in a dot (locale independent).

At the moment i have a build error because i am not familar with the sources, but i think i can provide a patch tomorrow (18:00 CET +0001).

tomprogrammer commented on 2010-11-18 22:36

first, excuse me for posting everytime the same, that was not my mind.

I prepared a patch making the parsing locale-independent, i fact only the two sscanf() statements must be replaced with the locale editions (sscanf_l) and as locale i use C which on every system results in a dot (locale independent).

At the moment i have a build error because i am not familar with the sources, but i think i can provide a patch tomorrow (18:00 CET +0002).

bratmaxe commented on 2010-11-18 21:10

I think I can confirm what jxy says. I use de_DE (german) locale and when I change the dots to commas, the apps that had invisivble fonts are OK again, but the other apps (like urxvt,conky) which were not affected before change to render fonts invisible.

Marcel_K commented on 2010-11-18 17:07

@tomprogrammer: yes, I think we got the message, but please don't post this four times.

Anonymous comment on 2010-11-18 15:54

It is conceivable that simply changing dot '.' to comma ',' will not solve all the problems, because app like chromium has its own mind. Different apps can set different locales for their own. In shell scripts and for environment variables, it is better to use integers instead of floating point. That's partially the reason why bash does not support floating point arithmetic. Broken shell scripts because of locale is very bad. I would use integers in the INFINALITY_ variables and convert them to floating point in the program.

tomprogrammer commented on 2010-11-18 14:30

mh, i disagree with this.
My peferred way is, to make the config-parsing locale-independent and use the dot anywhere on the world.

TemplarGR commented on 2010-11-18 14:29

On my netbook after having changed all dots to commas, chromium shows fonts in menu and bookmarks, but misses some letters...

tomprogrammer commented on 2010-11-18 14:08

mh, i disagree with this.
My peferred way is, to make the config-parsing locale-independent and use the dot anywhere on the world.

TemplarGR commented on 2010-11-18 13:50

There is another problem. If i modify this to use commas instead of dots, i have still invisible fonts in chromium. I can see web pages but the menu and the bookmarks aren't shown.

tomprogrammer commented on 2010-11-18 13:22

mh, i disagree with this.
My peferred way is, to make the config-parsing locale-independent and use the dot anywhere on the world.

TemplarGR commented on 2010-11-18 13:06


This is propably more work.

tomprogrammer commented on 2010-11-18 13:04

mh, i disagree with this.
My peferred way is, to make the config-parsing locale-independent and use the dot anywhere on the world.

TemplarGR commented on 2010-11-18 12:51

It seems this package could be modified to switch to commas in infinality-settings when using a locale that uses commas as decimal separator. It could simply parse /etc/rc.conf , check the locale, and if a locale with commas is found switching the infinality-settings file used. If this seems too much work, we need a variation of this PKGBUILD with the modified infinality-settings file. Of course we could do this manually, but it could lead to trouble for unsuspecting users(plus it is not fair we comma people have rights too :P )

tomprogrammer commented on 2010-11-18 12:10

Even the INFINALITY_FT_PSEUDO_GAMMA variable uses delemiters, i guess its also affected?
And another hint: The patch (2010-11-17) not solve this problem. But i think i doesn't have to say it, you know it already ;)

TemplarGR commented on 2010-11-18 11:32

I have already reported it in the forum.

tomprogrammer commented on 2010-11-18 11:19

Even the INFINALITY_FT_PSEUDO_GAMMA variable uses delemiters, i guess its also affected?
And another hint: The patch (2010-11-17) not solve this problem. But i think i doesn't have to say it, you know it already ;)

tomprogrammer commented on 2010-11-18 11:02

Thanks thiagoc, the error is found :)
Great that so many people have contributed and helped to solve the problem.
So we can report this issue upstream, i think in the forum?
Although Infinality also looked here yesterday ;)

thiagoc commented on 2010-11-18 10:54

Good morning :)

@tomprogrammer: I have just tested it and works. I'm using pt_BR locale, I changed the dots through commas and works like a charm.

export INFINALITY_FT_FILTER_PARAMS="0,11 0,22 0,38 0,22 0,11"

tomprogrammer commented on 2010-11-18 10:00

I am using the German locale, we use the comma (,) here. As a workaround it should be possible to exchange the dots through commas, right?
Can someone test this? I am at work and have no archlinux here for tests :(

TemplarGR commented on 2010-11-18 07:54

After switching to en_US locale everything works correctly. It seems that was the problem.

TemplarGR commented on 2010-11-18 07:50

@jxy running LC_ALL=C gtk-demo confirmed what you say, i will use en_US too to see what happens.

Anonymous comment on 2010-11-18 05:19

@TemplarGR, if the decimal is the problem, the patch he proposed will just ignore the settings, which I believe you would not want. Can you try with a different locale like en_US or simply C? Just run "LC_ALL=C gtk-demo" in a term would tell. If it is the culprit, please report it back to him. I don't have other locale generated, but if no one here tries until tomorrow night, I'll find some time to test it. I'll not update the pkg before this is verified.

TemplarGR commented on 2010-11-18 04:32

I flagged this out of date cause it seems infinality updated its packages with a patch that might solve this problem. See its blog.

TemplarGR commented on 2010-11-18 04:26

If the decimal '.' is the problem, we should report this to upstream for a fix i think. I will test this shortly

Anonymous comment on 2010-11-18 02:47

@Infinality, I think it might be the locale. Any locale that does not use point `.' as the decimal separator would break the parsing of the floating point.

I bet most of the people that have the problem are sleeping, now. Just like thiagoc.

thiagoc commented on 2010-11-18 01:58

@Infinality: well, so I need some sleep :)

With INFINALITY_FT_PSEUDO_GAMMA="100 .2" the fonts looks the same, I don't see difference.

Anonymous comment on 2010-11-18 01:52

@thiagoc: To me they all look the same. Setting this would tell me for sure:

What I am guessing is that for some reason the environment variables are not being picked up properly under some unknown circumstances. I'd like to figure out what those circumstances are.

thiagoc commented on 2010-11-18 01:43

@Infinality: yes, I think so:

From top to bottom:


2. All variables with values true/false defined as false


Tell me if you want a different value in some variable.

Anonymous comment on 2010-11-18 01:19

It’s working! I just wonder, why only chromium was affected.

Anonymous comment on 2010-11-18 00:55

thiagoc: Do you notice any differences in font rendering if you change any of the other environment variables to other valid values?

Anonymous comment on 2010-11-18 00:54

Nice :)

thiagoc commented on 2010-11-18 00:46

The patch works.

thiagoc commented on 2010-11-18 00:45

@Infinality: it works! Thanks :)

Anonymous comment on 2010-11-18 00:37

Another thing to try temporarily is either commenting out:


...prior to launching anything.

Anonymous comment on 2010-11-18 00:35

I've posted a patch here to do more checking on the input for INFINALITY_FT_FILTER_PARAMS. I'd like to see if it fixes the problems on those who are having issues. I think perhaps my code for grabbing environment variables needs some cleanup and better checking.

thiagoc commented on 2010-11-18 00:34

@Mr.Tao: unsetting "Xft.lcdfilter: lcddefault" doesn't work for me.

Anonymous comment on 2010-11-18 00:13

@ jxy: This is screenshot of chromium window. Left upper triangle is without and lower right is with subpixel hinting enabled:
@ thiagoc: In gnome I fixed this easily (see my older posts).

thiagoc commented on 2010-11-18 00:00

Now in Gnome:

Anonymous comment on 2010-11-17 23:42

@ jxy: I hoped that I made clear that I already tried running X as blank user with no custom config. I also already found connection between fonts incorrectly rendered in gnome and hintstyle and how to bring them back in gnome. What I do not know is how to make them visible in chromium.

Anonymous comment on 2010-11-17 23:42

I erased my ~/.fonts.conf and everything works now, only slightly ugly :S *puzzled*

Anonymous comment on 2010-11-17 23:42

same happened here when using TWM

thiagoc commented on 2010-11-17 23:34

@jxy: ok, I'm running twm. With INFINALITY_FT_FILTER_PARAMS the fonts are invisible, look:

Anonymous comment on 2010-11-17 23:14

By the way, if the invisible fonts problem makes it impossible for you to launch any new X programs, you can always go back to the true console (Alt-Ctrl-F1) and set the display variable (export DISPLAY=:0, and dbus related envs but we don't really need that) and start your X programs.

DON'T PANIC, before your kernel does so. You are stronger than a machine. And good luck.

Anonymous comment on 2010-11-17 23:08

I don't want to repeat myself, but why can't you guys try twm as I said. It is the simplest thing to do and will not fiddle with your config files at all---assume you have the correct config files. I would actually strongly suggest a clean user and twm. Thanks for your time. It's a beta software and please help debug it, instead of simply complaining. I would avoid launching whole gnome/kde environment, since they might change your configs---gnome actually controls fontconfig settings, and kde would change ~/.fonts.conf if you didn't stop it from doing that---("chattr +i" is your friend). It is frustrating when something doesn't work as expected, but please be patient and always start with an environment as clean as possible. Since most of you reporting xterm works, you should be able to start it in your invisible font environment and start checking all the possible variables and fiddling around. From the xterm, you are able to change the environment variables of the current shell, and you can tweak the conf files, and then you can start a clean xorg server with a single client like I have said "xinit /path/to/the/x/client -- /usr/bin/X :1"---it does not have to be a WM. PLEASE try it with a couple of different X clients and see what works.

For the record, I have testings repo enabled, and fully updated x86_64 system. I use the proprietary nvidia driver, stock cairo 1.10.0-2, and fontconfig 2.8.0-1. I have tried both libxft-lcd from AUR and libxft from extra, my fonts are perfectly normal with either of them. Since the only apps using libxft are emacs and xterm, it is expected that libxft shouldn't matter any way. I also tried full KDE, xmonad, twm, and everything works for me. I am really puzzled, because I cannot reproduce any of your issues. I have tested different INFINALITY_* settings, and the only thing that is close to invisible fonts is caused by INFINALITY_FT_PSEUDO_GAMMA="24 10", where the number "10" is for lighten up the glyph, which is expected behavior.

Actually, can someone show me a picture/screenshot of the invisible fonts you are talking about?

thestinger commented on 2010-11-17 23:04

Also, here's the local.conf I use, which is just infinality's stripped down a bit (one of the things I've removed might cause chromium to break)

thiagoc commented on 2010-11-17 23:04

@thestinger: I tried that, but it has no effect.

thiagoc commented on 2010-11-17 23:03

Ok. Just commented out the INFINALITY_FT_FILTER_PARAMS variable, now my fonts are back. Chromium is ok too.

thestinger commented on 2010-11-17 22:59

Try moving ~/.fonts.conf to /etc/fonts/local.conf

thestinger commented on 2010-11-17 22:59

Try moving ~/.fonts.conf to /etc/fonts/local.conf

Anonymous comment on 2010-11-17 21:54

I have tried cairo-xcb 1.10.0-2 and chromium-dev 9.0.576.0-1 with no effect.

thiagoc commented on 2010-11-17 21:31

What I have:

cairo 1.10.0-2
freetype2-infinality 2.4.3-7
libxft-lcd 2.1.14-1
fontconfig 2.8.0-1
xf86-video-intel 2.12.0-3

With ~/.fonts.conf from infinality all the fonts are invisible. Without it it's visible but the fonts looks ugly.

thestinger commented on 2010-11-17 20:30

Also, can you try with startx (assuming you're using gdm) and maybe something like openbox?

thestinger commented on 2010-11-17 20:28

libxft-lcd works fine here by the way

another variable - I use [testing], and there's an xorg rebuild of some sort in there right now

testing/xorg-server 1.9.2-2
extra/xorg-server 1.9.2-1

thestinger commented on 2010-11-17 20:28

libxft-lcd works fine here by the way

another variable - I use [testing], and there's an xorg rebuild of some sort in there right now

testing/xorg-server 1.9.2-2
extra/xorg-server 1.9.2-1

Anonymous comment on 2010-11-17 20:23

Now this is getting interesting. From completely blank user I launched X with .xinitrc containing nothing but 'exec ck-launch-session gnome-session' and I got exactly the same results like before: fonts are visible except in chromium. I use nouveau drivers, freetype2-infinality 2.4.3-7, cairo 1.10.0-2, libxft-cleartype 2.1.14-1 and fontconfig 2.8.0-1. Realizing that libxft is only aur package in chain I have updated it to plain libxft 2.2.0-1 – and still there are no fonts visible in chromium with subpixel rendering enabled.
(nouveau-dri 7.8.2-3, xf86-video-nouveau 0.0.16_git20100819-1, xorg-server 1.9.2-1).

gborzi commented on 2010-11-17 20:20

I don't have cairo-xcb and I can see fonts. Both with proprietary catalyst and nvidia drivers. Still, I've the problem with evince that crashes when opening some files.
I'm using gnome+compiz and the -lcd packages.

thestinger commented on 2010-11-17 20:03

another thing is that I use cairo-xcb for awesomewm, but I really doubt that xcb is required for the infinality patches to work... worth a try though I guess

thestinger commented on 2010-11-17 19:49

I just tried installing chromium and the fonts work fine for me. We just need to figure out what's different between our systems. Also, it might have to do with your configuration, because you don't have the same global config as I do.

It's not jxy's fault, because there are other people with the problem on fedora (using infinality's own packages)

Here's some things that could be wrong:

KDE/GNOME might override the global font configuration (see
Video driver (I use nouveau on my desktop and the standard intel drivers on my laptop, perhaps a bug in the proprietary drivers?)
Also, make sure to install local.conf globally in /etc/fonts (user specific configuration might not work if you use a DE)

Anonymous comment on 2010-11-17 19:27

@thestinger: I had to create new user to discover Xft.lcdfilter connection so this problem with chromium (Or webkit? Because bookmarks as well as addressbar renders correctly.) is not related to any of my configuration files.

thestinger commented on 2010-11-17 19:22

@ Mr. Tao - are you using infinality's local.conf? try deleting the .Xresources stuff

Anonymous comment on 2010-11-17 19:14

After installing update to this package I couldn’t see any fonts with subpixel rendering enabled. Then I figured that by unsetting Xft.lcdfilter: lcddefault I can bring them back. Unfortunately this does not seem to fix chromium fonts, which remain invisible.

falconindy commented on 2010-11-17 18:29

Fair enough. I hadn't considered patch order. Just my OCD kicking in, really. I don't like seeing "magic" numbers, and I thought this might be easier to maintain. Carry on, nothing to see here.

Anonymous comment on 2010-11-17 16:12

@klingger, have you tried to change INFINALITY_FT_PSEUDO_GAMMA? I can make my fonts barely visible if I use "20 10", so I wonder if there is a bug in the pseudo gamma correction.

Anonymous comment on 2010-11-17 16:09

@falconindy, I'm not sure if it is the case here, but sometimes order of the patches are important. It is easier to maintain the order with the source array. Nevertheless, why don't you like the way it is now? What is it bother you that I have overlooked?

falconindy commented on 2010-11-17 15:41

If you'd like to dynamically find and apply patches, can I suggest a solution that isn't dependent on source array order and path chopping?

Anonymous comment on 2010-11-17 07:42


no, not work with any values, work only when this variable is not declared

silenc3r commented on 2010-11-16 23:56

I can't see fonts in gtk apps and I use:
cairo 1.10.0-2
libxft-lcd 2.2.0-1

heres grep|export INFINALITY output:
declare -x INFINALITY_FT_FILTER_PARAMS="0.11 0.22 0.38 0.22 0.11"

thestinger commented on 2010-11-16 23:10


does it work with an unchanged

the default is
export INFINALITY_FT_FILTER_PARAMS="0.11 0.22 0.38 0.22 0.11"

Anonymous comment on 2010-11-16 22:56

didn't work for me...
I'll try that jxy as soon as I can ;)
I didn't know how to use twm :p

Anonymous comment on 2010-11-16 22:12

Work for me, if i comment line 43

export INFINALITY_FT_FILTER_PARAMS="0.00 0.35 0.35 0.35 0.00"

changed to

#export INFINALITY_FT_FILTER_PARAMS="0.00 0.35 0.35 0.35 0.00"

Anonymous comment on 2010-11-16 21:33

To everyone who are not seeing any font, what version of cairo and libxft do you use?

@elmariachi, for part d, you know how to use twm, do you?

Please do the following in twm (after "xinit /usr/bin/twm -- /usr/bin/X :1"): Press left mouse button anywhere you should see a menu, from where you should be able to launch xterm. In the xterm, check the environment variables (export|grep INFINALITY), xrdb (xrdb -q, ~/.Xresources, ~/.Xdefaults), and font conf files (~/.fonts.conf, /etc/fonts), and make sure they are what they should be. To test QT apps, please run qtconfig in that xterm; and to test GTK+ apps, please run gtk-demo.

t3ddy commented on 2010-11-16 21:22

I have the kde issue too.
Here on firefox fonts are perfect, chrome shows me no fonts at all.
Also plasmoids and notification has fonts hardly visible, although lancelot fonts are perfectly readable.

Anonymous comment on 2010-11-16 20:09

forgot to say it works in pekwm (window titles and menus) and in tint2

tomprogrammer commented on 2010-11-16 20:01

Its interesting that font rendering works in KDM, but when i logged in and KDE appears, there are no fonts...
I started twm as you suggested and the fonts are rendered in the xterm. But i am not sure, i thought that the rendering was not improved.
I also checked if in KDE there are the INFINALITY_* environment variables set. They are defined...

I hope this problem could be fixed, i am using this package since a week and would not miss it ;)

Anonymous comment on 2010-11-16 18:32

a) PekWM started by .xinitrc
b) xterm works fine, all GTK apps don't
c) Droid Sans 9pt and changing it has no effect whatsoever (no fonts showing)
d) didn't work (black screen)

sorry for having posted 3 times, something went wrong with chromium and I can't delete them..

Anonymous comment on 2010-11-16 18:03

It would be easier, if you can provide the following---a) DE/WM and how you start it; b) Does xterm work fine? What about emacs, firefox, konsole, gnome-terminal, gimp? c) What font do you set for your DE? Can you try several different fonts? d) Please run "xinit /usr/bin/twm -- /usr/bin/X :1" without quotes in a term and see how things work out for you with twm?

Anonymous comment on 2010-11-16 17:47

@thestinger I still can't see any fonts, even with the new PKGBUILD and both /etc/fonts/local.conf and /etc/fonts/conf.d/91-local.conf

Anonymous comment on 2010-11-16 17:45

@thestinger I still can't see any fonts, even with the new PKGBUILD and both /etc/fonts/local.conf and /etc/fonts/conf.d/91-local.conf

Anonymous comment on 2010-11-16 17:42

@thestinger I still can't see any fonts, even with the new PKGBUILD and both /etc/fonts/local.conf and /etc/fonts/conf.d/91-local.conf

thestinger commented on 2010-11-16 17:17

@tdebruyn, try putting it at /etc/fonts/local.conf (51-local.conf points to that), I doubt it will fix anything, but it's worth a try.


The fonts appear thinner now by default. Font appearance is very subjective/personal, so try changing settings in /etc/profile.d/, you might like one of the other lcd filter types better, etc.

Also, make sure your monitor's DPI is set properly (96 is NOT a standard).

You should report bugs to infinality, the forum might be a good place:

thestinger commented on 2010-11-16 17:14

The fonts appear thinner now by default. Font appearance is very subjective/personal, so try changing settings in /etc/profile.d/, you might like one of the other lcd filter types better, etc.

Also, make sure your monitor's DPI is set properly (96 is NOT a standard).

tdebruyn commented on 2010-11-16 17:06

That new PKGBUILD doesn't solve the problem for me.
I am using "" as "91-local.conf" in /etc/fonts/conf.d (which was working fine until yesterday)

I am using stock cairo and libxft-lcd. The font I use is Segoe, from Windows 7.

Any idea how to get debugs for that?

gborzi commented on 2010-11-16 16:50

I can see fonts, but using the new local.conf file from infinality makes fonts much smaller. Another problem is that evince crashes when opening some pdf files, this didn't happen with -5 version.

Anonymous comment on 2010-11-16 16:28

I believe I caught at least one bug in my PKGBUILD. There is a parameter expansion in the script I forgot to quote properly, so for some of you, the patches might not be applied properly. However, it is still a mystery why you cannot see any fonts. Please try the new PKGBUILD and see if it solves your problem.

thestinger commented on 2010-11-16 16:14

For the people who this isn't working for, do you have the local.conf installed globally? Also, are you using other patched packages? You should probably use stock cairo and if you use xft, libxft-lcd.

If qt/kde isn't working, you may want to check near the bottom of the local.conf where it says something "breaks qt".

Anonymous comment on 2010-11-16 16:10

I am using x86_64, and I tried KDE and xmonad, but I cannot reproduce any of your problems. Please do some debugging and provide more information. Otherwise, I cannot help.

eazy commented on 2010-11-16 11:01

I do not see any font either. Used the configuration files from Infinality blog. Had to revert to stock freetype2.

tdebruyn commented on 2010-11-16 09:32

Same problem here. All KDE applications have the problem (konsole, plasma, amarok, ...). Firefox, Thunderbird or xterm have fonts displayed properly. Reverting to stock for now too.

TemplarGR commented on 2010-11-16 06:41

I use Kwin and my results are those mentioned earlier. I didn't make any changes except installing this package. When i installed it all worked fine, but after update there were problems. Maybe i need to change some settings, i will try it later based onf Infinality blog and see what happens.

jskier commented on 2010-11-16 01:49

Fonts seem slightly skinnier with a lightly tweaked and basic local.conf (my own that I've always used- haven't had good luck with the new suggested one). I myself think it is very usable and am happy with the new version, but obviously things are different. I'm using LXDE / Metacity, and no login manager or anything fancy.

thestinger commented on 2010-11-16 00:08

works fine for me with no display manager (autologin to X via inittab/xinit), zsh, awesome wm, heavily tweaked/stripped down local.conf, no Xresources font settings :\

thestinger commented on 2010-11-16 00:06

works fine for me with no display manager (autologin to X via inittab/xinit), zsh, awesome wm, heavily tweaked/stripped down local.conf, no Xresources font settings :\

Anonymous comment on 2010-11-15 21:30

Don't flag out-of-date, if it is not out-of-date.

I have tested it on my machine, and it works fine for me. I need more information. First, please make sure you used exactly the same Xresources and fontconfig settings as recommended on the infinality weblog, before you make tweaks for yourself; then check if the environment variables are correctly set. When in doubt, use twm and launch applications from your term where the shell has exported those environment variables correctly.

By the way, what DE/WM do you all use?

Anonymous comment on 2010-11-15 18:53

Same problem here. Fonts disappeared.

silenc3r commented on 2010-11-15 18:46

@TemplarGR: I got the same problem. Everything was sweet until reboot...

TemplarGR commented on 2010-11-15 18:33

It may be a problem of configuration. On my desktop, i could see no fonts at all after update, on my netbook, i could barely see them when i looked from an angle. I don't know what the problem is and since i got work to do i have no time to mess with configurations so it is ubuntu patches for me at the moment. I hope eventualy to come back to infinality patches, they are amazing.

silenc3r commented on 2010-11-15 18:27

@TemplarGR: I got the same problem. Everything was sweet until reboot...

TemplarGR commented on 2010-11-15 17:40

After update i cannot see any fonts at all. Anyone else with the same problem? Reverting to stock for now...

Anonymous comment on 2010-11-15 17:04

Updated to 2010-11-14. The Bourne shell script "infinality-settings" is installed system-wide. Modify it to your need, if you use csh alike. You are advised to use the improved local.conf (

thestinger commented on 2010-10-26 21:17

@jt512, you should either start with the infinality local.conf and delete all the font replacements etc., or copy the important stuff into your own local.conf

the infinality patches are supposed to have full normal (byte-code interpreter) hinting for fonts with good hinting instructions and hintslight autohinting for fonts with bad hinting instructions

jt512 commented on 2010-10-26 21:13

@jxy: I wasn't using the local.conf file on the blog site, so I tried it, and it totally messed up the display of terminus font in rxvt-unicode. I also wasn't crazy about the fonts it chose for firefox.

machoo02 commented on 2010-10-26 18:06

Problem solved...cleared build directory and tried again. Yay for nice fonts \o/!

thestinger commented on 2010-10-26 18:02

it works fine here (no errors during patching)

machoo02 commented on 2010-10-26 17:33

One of the patches (freetype-add-subpixel-hinting-infinality) looks like it does not apply correctly.

==> Starting build()...
patching file modules.cfg
patching file include/freetype/config/ftoption.h
patching file include/freetype/internal/ftobjs.h
patching file src/truetype/
patching file src/truetype/truetype.c
patching file src/truetype/ttgload.c
patching file src/truetype/ttinterp.c
patching file src/truetype/ttinterp.h
patching file src/truetype/ttobjs.h
The next patch would create the file src/truetype/ttsubpixel.c,
which already exists! Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file src/truetype/ttsubpixel.h,
which already exists! Skipping patch.
1 out of 1 hunk ignored
ERROR: makepkg exited with an error (512)

Anonymous comment on 2010-10-26 06:10

gav616, I'm not sure where in the PKGBUILD I should put the url, so I left a comment below -- if you read the first comment I left. What is the common practice?

jt512, TiZ, are you using the local.conf suggested in the blogsite, or incorporate it in your own configs? Problems may occur if the font you are using is not tuned properly (autohint on/off, full/slight hinting, etc.).

Anonymous comment on 2010-10-26 04:20

please can you mention the creators website, it has patch information and a forum for any problems people are having.

jt512 commented on 2010-10-26 03:38

I'm not seeing the problem reported by TiZ, but the upgrade to 2.4.3-5 seems to mess up the horizontal spacing of letters in Firefox 3.11. The problem is not resolved by commenting out the autohinting enhancement patch.

Anonymous comment on 2010-10-25 14:34

If anyone has their i's dots connecting to their stems, the culprit is the autohint enhancement patch. Not to rip on the hard and excellent work here, but to let people know in case I'm not the only one with problems. If you don't want it, all you have to do is comment it out when building.

Anonymous comment on 2010-10-24 15:48

Thanks for the heads-up, wor. I only read through the text and didn't notice the change in the link. I'm just too lazy to keep track of the change of file names in the git repo I'm using. I'll learn to use 'git mv' next time, and retain their original file names, so it'll be easier for people to spot my oversight.

Anonymous comment on 2010-10-24 07:31

freetype-add-subpixel-hinting-infinality.patch is still not the newest one:

Why not use patches with orginal names?

Anonymous comment on 2010-10-23 02:15

This package is *NOT* made to work with only 'ttf-ms-fonts'. Thanks.

Anonymous comment on 2010-10-21 22:04

information regarding using the correct '.Xresources' and '.fonts.conf' to use with this package needs to be added to the wiki.

Also, this package is made to work with 'ttf-ms-fonts' and could be a dependency ?

Anonymous comment on 2010-10-19 21:23

Added new autohint enhancement patch. Better readability but worse shape. You are advised to use hintslight, now.

No longer provide -ubuntu, do it yourself if you need it.

Anonymous comment on 2010-10-18 23:43

please update

new patches have been added.

machoo02 commented on 2010-10-11 01:27

I agree with flamelab...perhaps people should ask the maintainers of the {cairo, libxft, fontconfig}-ubuntu packages to not hardcode a dependency on freetype2-ubuntu

Anonymous comment on 2010-10-10 21:12

I admit it's a not so beautiful hack for this package to satisfy requirement of other -ubuntu packages as some of the users want. However, I have read the arch packaging standards wiki page, and I don't really think it violates the standard, because the standard does not forbid doing so.

flamelab commented on 2010-10-10 16:22

Well, that's an -ubuntu packages' "problem", it should not be -infinality's problem, nor vanilla freetype2's.

Anonymous comment on 2010-10-10 16:01

@flamelab: My guess is that the included freetype2-ubuntu in the provides array is there in order to make it possible
for the rest of the -ubuntu family of packages (cairo, libxft, fontconfig) to work with this package.
All of these packages depend on freetype2-ubuntu, and the current PKGBUILD allows freetype2-infinality
to be used as a replacement.

flamelab commented on 2010-10-10 10:09

Well, there is. The provides array is in order to provide either an existing official package or a pre-existing package that was replaced.

Look here:

"...Additionally the provides=('screen') PKGBUILD array should be used in order to avoid conflicts with the official package..." <- official package (from repos), not on AUR.

freetype2-ubuntu provides freetype2 as I can see: provides=("freetype2=$pkgver")

So there is no need for providing *that* package within -infinality.

Anonymous comment on 2010-10-10 03:55

@flamelab: I think it's ok. I don't see any problem in freetype2-ubuntu in provides.

flamelab commented on 2010-10-09 22:40

hmm, freetype2-ubuntu provides in not correct.

freetype2-ubuntu should provide freetype2
freetype2-infinality should provice freetype2

but both patched freetype2 packages should not provide each other.

Jib commented on 2010-10-09 08:31

A new patch is now available. Please update the package.

Anonymous comment on 2010-10-07 16:25

estevao: I'm not sure if that's the best way to do, but I'll add it in the next version.

Jib: Looks like poppler only crashes on some of the pdf files. Maybe the patch breaks poppler's splash backend. Can you report it upstream?

Jib commented on 2010-10-07 13:48

The new version (2.4.3-1) makes pdf readers crash when opening some pdf.

Anonymous comment on 2010-10-06 17:16

Suggestion: add "freetype2-ubuntu=$pkgver" in provides=(... ) to make this package compatible with Ubuntu patched packages. Thanks.

PS. Sorry for the edits.

Anonymous comment on 2010-09-24 14:44

local.conf given by the infinality website has too many tunings and font substitutions. And /etc/fonts/local.conf is not meant to be changed by the package, but has to be maintained by the sys admin or you. If I need to add a conf to the package, it should go into /etc/fonts/conf.avail. But one file would not suit everyone. I recommend you actually read the local.conf and pick what you like, and put it either in your /etc/fonts/local.conf or just in ~/.fonts.conf. For your own and only login name, they don't have any differences. And I won't make a font package to be a dependency of this package. Infinality's local.conf has tunings for many different fonts. I don't think it's appropriate to add all the fonts to the dependencies list. And ttf-ms-fonts would not be the special case. People have different tastes and thus love different fonts. So just do it by yourself. I don't want to enforce a special font package to use with this package.

Anonymous comment on 2010-09-22 00:01

I've tried this package with success, my fonts look fantastic, here's what I did:

Installed 'freetype2-infinality'
Copied the 'local.conf' @ to my '/etc/fonts/' | which should be in this package, I think.
Backed up my current '~/.fonts.conf'
Created a new '.fonts.conf' in my home directory and added a blank config e.g. | a comment in this package might be helpful.
Installed 'ttf-ms-fonts' | which should be a dependency, I think.
Installed 'cairo-cleartype' and 'libxft-cleartype' (LCD FIR filtering) | a comment in this package might be helpful.
Added the recommended X font config to my '~/.Xdefaults' e.g. | a comment in this package might be helpful.

mikes commented on 2010-09-19 10:03

it seems that there are 3 patches of our interest now.

dikei commented on 2010-09-19 05:57

New patch is out

Anonymous comment on 2010-08-29 01:07

Is there someone using this with {cairo,fontconfig,libxft}-ubuntu packages? Can someone post his fonts.conf? Thanks

Anonymous comment on 2010-08-26 01:47

Enlightened by multilib repo, here is the lib32 version

Anonymous comment on 2010-08-10 15:36

So the question is where can we host the i686 binary and who is going to make it. I can make the binary if you trust me. But then, I guess I can just make the lib32 pkg available somewhere. So where can I put it?

gborzi commented on 2010-08-09 00:41

To have a lib32 version of this package someone should provide webspace to hold an i686 binary (compiled without processor-specific optimisations). After this is available, a PKGBUILD like the one for lib32-freetype2-ubuntu is easily done.

Anonymous comment on 2010-08-08 18:05

I'm not sure how a custom made binary can be distributed via AUR system. I'd love to do it, if someone here can give me a guide.

fettouhi commented on 2010-08-08 10:40

coyuld we see a lib32 version of this package at some point maybe?

lp76 commented on 2010-07-21 05:58

Thanks jxy!

Anonymous comment on 2010-07-21 02:11

I use KDE, so mostly Qt is doing the hard work. I found the stock cairo works poorly with this patched freetype2, so I use cairo-lcd, which gives clearly much better results. I don't have experiences with -cleartype or -ubuntu. Maybe you can just try and see which one works best for you and share your result with others in the forum. And just for the record, I use hintslight and lcddefault with autohint set to false.

lp76 commented on 2010-07-20 20:51

Hi jxy,
thanks for the package. One question: which type of cairo and libxft package do you recommend? -cleartype, -ubuntu or -lcd?

Anonymous comment on 2010-07-14 19:48

FYI, this is from and links within. Please see for rendering pictures.

Yegorius commented on 2007-01-01 01:32

~/.Xresources is not needed any more.