infinality-bundle: good looking fonts made (even) easier

bohoomil · 2013-06-24 10:14:57

I must have put the cat among the pigeons… Instead of letting my OCD speak, I am going to describe my approach and its benefits.

I maintain fonts manually because this way

I can avoid installation of multiple copies of the same family in different versions and formats (one of the most common reasons for rendering issues),
I can avoid relying on huge and cryptic local font sources which possibly contain 5 families I need and 55 I don't need (TeX Live & 09-texlive-fonts.conf, random font collections),
I can avoid rendering issues because my fontconfig settings were tuned to a different format but the one installed in my system,
I can quickly verify which format is present in the system and available for applications,
I can use exactly the same version of a font in all applications, including TeX related software,
when I upgrade a single font, the upgrade is going to be valid for all applications I use (including TeX software),
I can quickly enable / disable a particular family if necessary because I know where it can be found,
I don't need to worry about redundant /etc/fonts/conf.avail/nn-foo.conf fontconfig files, potentially conflicting with my infinality settings,
I don't need sophisticated and heavy font management applications because I can quickly--visually--verify which fonts are available by inspecting the content of a single directory, and in order to check a particular font (the variants it offers and rendering quality), all I need is a simple gtk2fontsel tool.

In practical terms, there are at least a few ways to achieve this which, if necessary, can be adopted by a typical package manager. The one I like best would separate font source directories (let's call them font.avail) from a directory containing symbolic links to the families in use (/usr/share/fonts). That's how I do it:

I use an obvious directory naming convention:

<ttf|otf|t1>-<optional_global_group_or_foundry_name>-<font_family_name>

The fonts I install manually are located in /usr/share/fonts.avail

/usr/share/fonts.avail/ttf-liberation
/usr/share/fonts.avail/ttf-ms-arial
/usr/share/fonts.avail/otf-heuristica

I don't touch TeX Live font directories to avoid issues with LaTeX software.Instead, in my /usr/share/fonts I create symlinks to fonts I really want to use (for convenience, I use MC, but this is up to you how you are going to perform this step). The final result:

$ ls /usr/share/fonts

ttf-liberation        -> ../fonts.avail/ttf-liberation
ttf-ms-arial          -> ../fonts.avail/ttf-ms-arial
otf-heuristica        -> ../fonts.avail/otf-heuristica
otf-texlive-tex-gyre  -> /opt/texlive/texmf-dist/fonts/opentype/public/tex-gyre
...

Last but not least, I run the usual:

# fc-cache && mkfontscale && mkfontdir

A similar approach can be found in TeX Live article, but it's way simpler and describes a per-user scenario rather than a global implementation.

The only font package I install is ttf-dejavu since it is often required as a dependency. However, it can be easily adopted in the above model by creating a custom package -- that's the matter of a few minutes.

Last edited by bohoomil (2013-06-24 12:03:26)

WonderWoofy · 2013-06-24 15:00:48

Wow, that is a fantastic way of doing it! This is so much more of an answer than I expected to get when i asked a few posts back. In fact, my expectation was to get a general idea of which packages you had installed, but this is oh so much better.

StR@ng3r · 2013-06-25 02:36:32

Can anybody tell me why my fonts look totally different on xfce depending on when I use (A) slim to login and start xfce as opposed to (B) starting xfce without a display manager just entering startx?

Ok, after posting, I found that it might not really belong in here... so: https://bbs.archlinux.org/viewtopic.php … 1#p1292141

However, what exactly happened to /etc/fonts/infinality/infinality.conf ?

Did you remove that one from your bundle or is it just me? Given that is it gone, where to it go? More precisely: where do I specify the dpi setting now? There is something in the wiki about it and I was wondering if the dpi setting might have something to do with it.

//Edit: Ok gathering from: http://bohoomil.github.io/ib.html all those settings have been moved to: /etc/fonts/infinality/infinality.conf
Still could u point me to the one containing the DPI-Stuff please?

Last edited by StR@ng3r (2013-06-25 03:31:24)

ngoonee · 2013-06-25 07:16:14

Would this repo be compatible with [testing]? Guess not?

bohoomil · 2013-06-25 08:56:59

@StR@ng3r, infinality.conf was simply an extension for /etc/fonts/fonts.conf which was needed for a generic infinality configuration. Now that the fontconfig-infinality-ultimate is tightly integrated with infinality, it doesn't need anything but a regular /etc/fonts/fonts.conf. The DPI section was removed, but can be easily implemented on a per-user basis: just paste in your local $HOME/.config/fontconfig/fonts.conf the following code

<match target="pattern">
    <edit name="dpi" mode="assign">
      <double>72</double>
    </edit>
</match>

and you should be able to get what you want.

@ngoonee, I didn't check whether the libraries work with [testing] enabled, but I believe they do. If they don't, simply rebuild source packages (to be updated soon: freetype2 to 2.5.0.1 and fontconfig to 2.10.93).

By the way, the update is waiting to be tested: check Dropbox for freshly built binaries. If no disaster happens, they will soon land in a repository.

Thank you.

WonderWoofy · 2013-06-25 14:45:06

@ngoonee, I have not had any issue as of yet with using [testing] and the infinality-bundle. I think that karol is also using this combination as well. If I do have issues, you can be sure that I would report it here to bohoomil.

@bohoomil, things seem great with the new packages. Thanks.

ngoonee · 2013-06-25 23:52:20

bohoomil wrote:

@ngoonee, I didn't check whether the libraries work with [testing] enabled, but I believe they do. If they don't, simply rebuild source packages (to be updated soon: freetype2 to 2.5.0.1 and fontconfig to 2.10.93).

WonderWoofy wrote:

@ngoonee, I have not had any issue as of yet with using [testing] and the infinality-bundle. I think that karol is also using this combination as well. If I do have issues, you can be sure that I would report it here to bohoomil.

Thanks, actually I wouldn't expect problems *most* of the time, but if (for example) something related to fonts gets rebuilt or updated in [testing] this could potentially break for the amount of time it remains in [testing]. Such as the examples bohoomil gave above? In any case, probably trivial to deal with.

WonderWoofy · 2013-06-26 00:02:39

@ngoonee, Well, there is certainly the chance that this could happen, but at least fontconfig and freetrype2 don't really depend on much. Fontconfig depends on expat and freetype2, and freetype2 depends on zlib, bzip, and sh. So amongst them all there is a glib depndency. Cairo on the other hand is built against much more.

bohoomil · 2013-06-26 01:46:44

I guess zlib, bzip or sh are not as substantial for freetype2 as gcc, which is the only thing it really needs to be built. That's a pretty easy to handle library and so is fontconfig, to be honest. Thus the problem is not those two, but the infinality patches and the time I need to adjust fontconfig configs, my own patches and freetype2 runtime settings. That's usually the matter of a couple of days, although I'd rather not hurry up because it's always wise to revise a visual configuration the next day or even week. So, the more time I can spend with the libraries at the beginning, the least minor releases with bug fixes will follow.

If for a reason I can't think of at the moment freetype2/fontconfig from the bundle repository indeed breaks the system, we can always quickly reinstall them from the official [extra]/[testing]. However, this is something that has never happened to me yet, so I believe that the possibility of things going that bad is probably pretty low.

Last edited by bohoomil (2013-06-26 02:26:06)

bohoomil · 2013-06-26 15:17:23

So, here we go again. The packages can be installed using the new repository:

[infinality-bundle]
Server = http://ibn.net63.net/infinality-bundle/$arch

[infinality-bundle-multilib]
Server = http://ibn.net63.net/infinality-bundle-multilib/$arch

[infinality-bundle-any]
Server = http://ibn.net63.net/infinality-bundle-any

The new host seems to be faster and more robust, so maybe we can finally forget about all the headaches we were experiencing previously.

The first post in this thread as well as the Wiki article have been updated to reflect technical changes. To learn more about the new release, please check the CHANGELOG.

For your convenience, the old binaries can be found in infinality-bundle-archive, if for some reason the recent ones should cease to work correctly for you. Please note that they are not maintained anymore, so use them only in case of emergency and install a current release ASAP.

Personally, I like this release and I hope you are going to enjoy it, too.

Thank you.

Perfect Gentleman · 2013-06-26 15:32:08

warning: fontconfig-infinality-ultimate: local (1:2.10.92-12) is newer than infinality-bundle (2.10.93-4)

WonderWoofy · 2013-06-26 15:34:36

Yeah, that was annoying. It is because of the difference in versioning. You should be updating to the 2.10.93-4 though.

Perfect Gentleman · 2013-06-26 15:35:57

WonderWoofy wrote:

Yeah, that was annoying. It is because of the difference in versioning. You should be updating to the 2.10.93-4 though.

roger that

karol · 2013-06-26 15:38:03

:: Starting full system upgrade...
warning: fontconfig-infinality-ultimate: local (1:2.10.92-12) is newer than infinality-bundle (2.10.93-4)
resolving dependencies...
looking for inter-conflicts...

Packages (2):

Name                                             Old Version  New Version  Net Change  Download Size

infinality-bundle/cairo-infinality-ultimate      1.12.14-8    1.12.14-9    0,00 MiB         0,68 MiB
infinality-bundle/freetype2-infinality-ultimate  2.4.11-4     2.5.0.1-3    -0,11 MiB        0,55 MiB

What to do with fontconfig-infinality-ultimate?

Edit: Please disregard. I should have updated the page before posting.

Last edited by karol (2013-06-26 15:39:36)

bohoomil · 2013-06-26 17:13:37

I know I must have forgotten about something…

I mentioned it somewhere earlier in this thread that due to my mistake in versioning (git vs the repo), the new package must be 'downgraded' during installation, which will replace the incorrectly numbered old one (using 'epoch' variable) with the new one. So just for the record: install whatever is new in the repository.

I'm sorry for the incovenience.

anonymous_user · 2013-06-26 19:32:25

I am still having trouble with the server:

~ > sudo pacman -Syyu
:: Synchronizing package databases...
 core                                                                                                  102.8 KiB   212K/s 00:00 [#############################################################################] 100%
 extra                                                                                                1505.5 KiB   159K/s 00:09 [#############################################################################] 100%
 community                                                                                            1959.9 KiB   271K/s 00:07 [#############################################################################] 100%
 repo-ck                                                                                                42.8 KiB   304K/s 00:00 [#############################################################################] 100%
error: failed retrieving file 'infinality-bundle.db' from ibn.net63.net : Connection timed out after 10072 milliseconds
error: failed to update infinality-bundle (download library error)
:: Starting full system upgrade...
 there is nothing to do

~ > ping -c 5 ibn.net63.net 
PING ibn.net63.net (31.170.162.143) 56(84) bytes of data.

--- ibn.net63.net ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

~ > traceroute ibn.net63.net
traceroute to ibn.net63.net (31.170.162.143), 30 hops max, 60 byte packets
 1  homeportal (192.168.1.254)  8.619 ms  8.590 ms  8.585 ms
 2  162-195-56-3.lightspeed.irvnca.sbcglobal.net (162.195.56.3)  35.455 ms  35.467 ms  35.461 ms
 3  * * *
 4  12.83.38.177 (12.83.38.177)  37.084 ms  36.027 ms  37.056 ms
 5  ded3-g4-3-0.sfldmi.ameritech.net (151.164.40.106)  88.423 ms  88.369 ms *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Last edited by anonymous_user (2013-06-26 19:34:01)

bohoomil · 2013-06-26 21:16:29

Here's mine, for reference: click. Would you mind checking what this site says about it? Can it be the issue with your ISP's cache for instance?

cfr · 2013-06-26 22:39:41

Wonderful! Working fine here - thank you for all your work on this.

cfr · 2013-06-26 22:42:32

bohoomil wrote:

I must have put the cat among the pigeons… Instead of letting my OCD speak, I am going to describe my approach and its benefits.
I maintain fonts manually because this way
I can avoid installation of multiple copies of the same family in different versions and formats (one of the most common reasons for rendering issues),
I can avoid relying on huge and cryptic local font sources which possibly contain 5 families I need and 55 I don't need (TeX Live & 09-texlive-fonts.conf, random font collections),
I can avoid rendering issues because my fontconfig settings were tuned to a different format but the one installed in my system,
I can quickly verify which format is present in the system and available for applications,
I can use exactly the same version of a font in all applications, including TeX related software,
when I upgrade a single font, the upgrade is going to be valid for all applications I use (including TeX software),
I can quickly enable / disable a particular family if necessary because I know where it can be found,
I don't need to worry about redundant /etc/fonts/conf.avail/nn-foo.conf fontconfig files, potentially conflicting with my infinality settings,
I don't need sophisticated and heavy font management applications because I can quickly--visually--verify which fonts are available by inspecting the content of a single directory, and in order to check a particular font (the variants it offers and rendering quality), all I need is a simple gtk2fontsel tool.
In practical terms, there are at least a few ways to achieve this which, if necessary, can be adopted by a typical package manager. The one I like best would separate font source directories (let's call them font.avail) from a directory containing symbolic links to the families in use (/usr/share/fonts). That's how I do it:
I use an obvious directory naming convention:
<ttf|otf|t1>-<optional_global_group_or_foundry_name>-<font_family_name>
The fonts I install manually are located in /usr/share/fonts.avail
/usr/share/fonts.avail/ttf-liberation
/usr/share/fonts.avail/ttf-ms-arial
/usr/share/fonts.avail/otf-heuristica
I don't touch TeX Live font directories to avoid issues with LaTeX software.Instead, in my /usr/share/fonts I create symlinks to fonts I really want to use (for convenience, I use MC, but this is up to you how you are going to perform this step). The final result:
$ ls /usr/share/fonts

ttf-liberation        -> ../fonts.avail/ttf-liberation
ttf-ms-arial          -> ../fonts.avail/ttf-ms-arial
otf-heuristica        -> ../fonts.avail/otf-heuristica
otf-texlive-tex-gyre  -> /opt/texlive/texmf-dist/fonts/opentype/public/tex-gyre
...
Last but not least, I run the usual:
# fc-cache && mkfontscale && mkfontdir
A similar approach can be found in TeX Live article, but it's way simpler and describes a per-user scenario rather than a global implementation.
The only font package I install is ttf-dejavu since it is often required as a dependency. However, it can be easily adopted in the above model by creating a custom package -- that's the matter of a few minutes.

This is brilliant. I am going to work on setting something similar up as soon as I can. This should be in the wiki, I think.

anonymous_user · 2013-06-27 02:41:51

bohoomil wrote:

Here's mine, for reference: click. Would you mind checking what this site says about it? Can it be the issue with your ISP's cache for instance?

If the problem is my ISP then I suppose I would have to contact them to resolve the issue? Grrrr!

flipper T · 2013-06-27 05:40:15

I have just updated pacman.conf in line with the the wiki & now when updating i get this

iinfinality-bundle                                                7.0 KiB  6.81M/s 00:00 [###################################################] 100%
 infinality-bundle.sig                                          287.0   B  0.00B/s 00:00 [###################################################] 100%
 infinality-bundle-multilib                                       2.5 KiB  0.00B/s 00:00 [###################################################] 100%
 infinality-bundle-multilib.sig                                 287.0   B  0.00B/s 00:00 [###################################################] 100%

I have no idea what the ".sig" things are. Is this ok?

Everything "seems" to be working ok.

ps I blindly added the multilib repos without actually knowing whether i need them or not. I recognize that this is a little bit silly. How can i tell whether or not I actually need them ?

Last edited by flipper T (2013-06-27 05:51:07)

ngoonee · 2013-06-27 06:22:59

flipper T wrote:

ps I blindly added the multilib repos without actually knowing whether i need them or not. I recognize that this is a little bit silly. How can i tell whether or not I actually need them ?

Uh.... what's your arch? Do you know what multilib is?

flipper T · 2013-06-27 06:27:21

64 bit.

I thought that multilib added support for 32 bit apps run in a 64 bit environment (?)

Is this is correct ?

edit: afaik, the only application i have installed that needs 32bit support is wine, through which i run a number of old 32 bit applications. If i do not need multlib repos enabled for these, that's fine with me.

Last edited by flipper T (2013-06-27 06:53:25)

ngoonee · 2013-06-27 07:20:27

flipper T wrote:

64 bit.
I thought that multilib added support for 32 bit apps run in a 64 bit environment (?)
Is this is correct ?
edit: afaik, the only application i have installed that needs 32bit support is wine, through which i run a number of old 32 bit applications. If i do not need multlib repos enabled for these, that's fine with me.

Yes that's what multilib does, and if any of the multilib apps you run need fonts, that's where they're from .

flipper T · 2013-06-27 07:49:58

re: my ".sig" query...found answer here : https://bbs.archlinux.org/viewtopic.php?id=152196

google search is a wonderful thing

Arch Linux

#401 2013-06-24 10:14:57

Re: infinality-bundle: good looking fonts made (even) easier

#402 2013-06-24 15:00:48

Re: infinality-bundle: good looking fonts made (even) easier

#403 2013-06-25 02:36:32

Re: infinality-bundle: good looking fonts made (even) easier

#404 2013-06-25 07:16:14

Re: infinality-bundle: good looking fonts made (even) easier

#405 2013-06-25 08:56:59

Re: infinality-bundle: good looking fonts made (even) easier

#406 2013-06-25 14:45:06

Re: infinality-bundle: good looking fonts made (even) easier

#407 2013-06-25 23:52:20

Re: infinality-bundle: good looking fonts made (even) easier

#408 2013-06-26 00:02:39

Re: infinality-bundle: good looking fonts made (even) easier

#409 2013-06-26 01:46:44

Re: infinality-bundle: good looking fonts made (even) easier

#410 2013-06-26 15:17:23

Re: infinality-bundle: good looking fonts made (even) easier

#411 2013-06-26 15:32:08

Re: infinality-bundle: good looking fonts made (even) easier

#412 2013-06-26 15:34:36

Re: infinality-bundle: good looking fonts made (even) easier

#413 2013-06-26 15:35:57

Re: infinality-bundle: good looking fonts made (even) easier

#414 2013-06-26 15:38:03

Re: infinality-bundle: good looking fonts made (even) easier

#415 2013-06-26 17:13:37

Re: infinality-bundle: good looking fonts made (even) easier

#416 2013-06-26 19:32:25

Re: infinality-bundle: good looking fonts made (even) easier

#417 2013-06-26 21:16:29

Re: infinality-bundle: good looking fonts made (even) easier

#418 2013-06-26 22:39:41

Re: infinality-bundle: good looking fonts made (even) easier

#419 2013-06-26 22:42:32

Re: infinality-bundle: good looking fonts made (even) easier

#420 2013-06-27 02:41:51

Re: infinality-bundle: good looking fonts made (even) easier

#421 2013-06-27 05:40:15

Re: infinality-bundle: good looking fonts made (even) easier

#422 2013-06-27 06:22:59

Re: infinality-bundle: good looking fonts made (even) easier

#423 2013-06-27 06:27:21

Re: infinality-bundle: good looking fonts made (even) easier

#424 2013-06-27 07:20:27

Re: infinality-bundle: good looking fonts made (even) easier

#425 2013-06-27 07:49:58

Re: infinality-bundle: good looking fonts made (even) easier

Board footer