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

bohoomil · 2014-03-24 08:50:31

@orschiro I do not think so: just go ahead and remove ttf-droid-ib.

orschiro · 2014-03-24 09:41:30

Thanks. It turns out that not only Droid is conflicting but also other fonts from even the meta-base package. To avoid any conflicts, can I also remove the entire ibfonts-meta-base and ibfonts-meta-extended packages?

Or how would you resolve the conflict in a better way?

bohoomil · 2014-03-24 11:34:44

Which font families from ttf-google-fonts-git do you really need? ttf-google-fonts-git is a cluttered blob and when you are using ibfonts-meta-extended, I would strongly discourage installation of the AUR package. This is mostly an 'either--or' question: you have to decide which collection is better for you and install it. The best practice is always the same: know what you need and install only what you need. If you need 3 families from ttf-google-fonts-git, do not install 203 in order to get the 3.

If you are going to stick with ttf-google-fonts-git instead of either the MS collection or the free one, than you should select 'combi' preset with 'fc-presets set' and manually edit all the files in /etc/fonts/conf.avail.infinality/combi so that fontconfig knows what to do with the fonts. Currently the combi preset, as stated in the CHANGELOG, is a combination of free fonts and MS families (for non-Latin scripts), so you are not going to start from scratch. Anyway, you will still need to revise the rendering of each font that has not been tested and commit changes to relevant configuration files (90-{non-}tt-fonts.conf & 92-selective-rendering.conf in the first place).

x33a · 2014-03-24 18:10:24

Well, I finally bit the bullet and decided to do something about my "not so attractive" fonts. I have always been lazy about configuring font rendering, and had been delaying doing something about it for ages. infinality-bundle gave me an install and forget solution. Thanks a lot bohoomil and everyone else who has contributed to this project!

After being used to sharp looking fonts for ages, I am having a bit of trouble adjusting to the new smooth look, but I like it so far.

One problem I am facing is with my conky config:

The yellow field (it's for memory, and using the symbol "⊟"), is not aligned properly with the others. Can anyone give a clue as to what is the cause?

frank604 · 2014-03-24 21:20:10

@x33a That is a strange anomaly. Does that happen when you remove glyph or change to different glyph such as the music notes?

sl1pkn07 · 2014-03-24 22:51:02

have the same problem like @x33a with fonts with kanji and normal character in the same line

see the bottom of the each line

x33a · 2014-03-25 05:48:22

frank604 wrote:

@x33a That is a strange anomaly. Does that happen when you remove glyph or change to different glyph such as the music notes?

It doesn't happen if I remove the glyph, or use a music note (which I am already using for the volume, see to the right of the memory indicator).

progandy · 2014-03-25 05:54:56

I guess the glyph is taken from another font with different spacing and that throws the positiong algorithm off its mark.

x33a · 2014-03-25 05:59:28

progandy wrote:

I guess the glyph is taken from another font with different spacing and that throws the positiong algorithm off its mark.

I am using droid sans for this. And before using infinality, it was rendering properly. Also, assuming that's the case, I suppose only that glyph should be misaligned, but in this case, the whole memory block is misaligned.

Here's the relevant part of the conkyrc:

{"full_text":"[ ⊟ ${memperc}% ]","color":${if_match ${memperc}>70}"\#ff0000"${else}"\#dbdb00"${endif},"separator":false,"separator_block_width":2},\

progandy · 2014-03-25 06:44:49

x33a wrote:

progandy wrote:
I guess the glyph is taken from another font with different spacing and that throws the positiong algorithm off its mark.
I am using droid sans for this. And before using infinality, it was rendering properly. Also, assuming that's the case, I suppose only that glyph should be misaligned, but in this case, the whole memory block is misaligned.

Sorry, but that is the problem. i3bar walks through all textblocks. Each textblock is measured with pango as a whole to fix its position and then drawn on the bar. As a result the whole text for the memory block is drawn wrong.
Most likely the infinality patches change the behaviour of the line spacing/height calculation when fonts are mixed or this is done in the configuration files.

Here is the code in i3bar: http://code.stapelberg.de/git/i3/tree/i … xcb.c#n176

Last edited by progandy (2014-03-25 07:02:44)

frank604 · 2014-03-25 06:46:52

Disclaimer: This is a wild guess
Not a font guy, but you can test the stem alignment settings in /etc/profile.d/infinality-settings.sh and run the script.

EDIT: Hehe, I was very off the mark on this one.

Last edited by frank604 (2014-03-25 14:50:16)

x33a · 2014-03-25 08:27:25

@ progandy, thanks, at least the problem is partially clear!

@ frank604, thanks for the suggestion. I tried playing around with the stem values, but nothing seems to have made a difference.

Edit: Well, apparently, it was because of t1-dejavu-ib. Replacing it with ttf-dejavu fixed the problem.

But unfortunately, I had many problems with font rendering in urxvt. I tried several other terminals (termite, st, lilyterm, terminator), in its place. But none could satisfy my requirements fully. So, I finally chose urxvt over infinality-bundle. Too bad, I really liked the font rendering inside Firefox

Last edited by x33a (2014-03-25 08:50:55)

wilfriedd · 2014-03-25 10:50:52

@bohoomil: Thanks again for this new release!

One quick question: I like to use custom default fonts (Arimo, Tinos, Cousine), and as I understand I now have to specify this preference in combi/60-latin-combi.conf and use fc-presets to set combi. After doing this, fc-match sans still returns meiryo (with lang=en).
After some research, it appears that combi/93-final-lang-spec-combi.conf is the culprit, as it does a prepend on sans with binding=strong, thus overriding the normal preferences.

My question is, how should I use these files and what is their purpose? Should I put my sans default font preference in both of them?

Thanks a lot!

bohoomil · 2014-03-25 14:03:45

@x33a

x33a wrote:

Edit: Well, apparently, it was because of t1-dejavu-ib. Replacing it with ttf-dejavu fixed the problem.
But unfortunately, I had many problems with font rendering in urxvt. I tried several other terminals (termite, st, lilyterm, terminator), in its place. But none could satisfy my requirements fully. So, I finally chose urxvt over infinality-bundle. Too bad, I really liked the font rendering inside Firefox

Well, you should have installed ttf-dejavu-ibx from infinality-bundle-fonts repository then. It comes with separate configuration files for the TrueType variant and is available in case the T1 does not perform well enough under certain conditions. This is one of the many questions that has been discussed in this thread, so for a few fonts a user has a choice between different formats of the same family. (There are less and less such situations, though.)

Besides, urxvt is a pretty popular terminal emulator and the one I use by default for more than 12 hours a day, so it does have to behave properly. Would you mind elaborating a bit more on those 'many problems' you had with it and infinality-bundle? Any screenshots to help me understand what was going wrong? Of course, it is always possible that a certain problem cannot be solved, but in most cases an issue crops up due to a little misconfiguration which can be fixed.

@sl1pkn07 It seems that you have answered the question yourself: this sort of things happen when the application does not handle different scripts' glyphs properly. Try increasing the height of Ubuntu Sans slightly or checkout a different font family. (BTW, may I ask what the application in the screenshot is?)

@wilfriedd Which font collection are you using by default? Free or MS? In both cases, you do not have to use combi because this preset is targeted at users who want to build their own font collection and need more freedom in order to customize fontconfig settings properly. Just set free or ms as your main preset and customize 35-repl-custom.conf which will do what you need. This is a relevant snippet from my 35-repl-custom.conf:

  <!-- Arial => TeX Gyre Heros -->
  <match target="font">
    <test name="family">
      <string>Arial</string>
    </test>
    <edit name="family" mode="assign">
      <string>TeX Gyre Heros</string>
    </edit>
  </match>
  <match target="pattern">
    <test name="family">
      <string>Arial</string>
    </test>
    <edit name="family" mode="prepend" binding="strong">
      <string>TeX Gyre Heros</string>
    </edit>
  </match>

  <!-- Arial Narrow => TeX Gyre Heros Cn -->
  <match target="font">
    <test name="family">
      <string>Arial Narrow</string>
    </test>
    <edit name="family" mode="assign">
      <string>TeX Gyre Heros Cn</string>
    </edit>
  </match>
  <match target="pattern">
    <test name="family">
      <string>Arial Narrow</string>
    </test>
    <edit name="family" mode="prepend" binding="strong">
      <string>TeX Gyre Heros Cn</string>
    </edit>
  </match>

  <!-- Helvetica => TeX Gyre Heros -->
  <match target="font">
    <test name="family">
      <string>Helvetica</string>
    </test>
    <edit name="family" mode="assign">
      <string>TeX Gyre Heros</string>
    </edit>
  </match>
  <match target="pattern">
    <test name="family">
      <string>Helvetica</string>
    </test>
    <edit name="family" mode="prepend" binding="strong">
      <string>TeX Gyre Heros</string>
    </edit>
  </match>

  <!-- Helvetica Narrow => TeX Gyre Heros Cn -->
  <match target="font">
    <test name="family">
      <string>Helvetica Narrow</string>
    </test>
    <edit name="family" mode="assign">
      <string>TeX Gyre Heros Cn</string>
    </edit>
  </match>
  <match target="pattern">
    <test name="family">
      <string>Helvetica Narrow</string>
    </test>
    <edit name="family" mode="prepend" binding="strong">
      <string>TeX Gyre Heros Cn</string>
    </edit>
  </match>

Doing the same for Tinos and Cousine should do the trick in your case.

gothmog.todi · 2014-03-25 15:19:26

I encountered a small problem: the settings in 60-latin-free.conf are somehow overwritten with Noto on my system. I was able to identify 93-final-lang-spec-free.conf as the culprit. When I remove it, fc-match returns the fonts according to 60-latin-free.conf. I'm not quite sure what 93-final-lang-spec-free.conf is supposed to do, so I don't know where the problem lies exactly.

x33a · 2014-03-25 16:21:23

bohoomil wrote:

@x33a
Well, you should have installed ttf-dejavu-ibx from infinality-bundle-fonts repository then. It comes with separate configuration files for the TrueType variant and is available in case the T1 does not perform well enough under certain conditions. This is one of the many questions that has been discussed in this thread, so for a few fonts a user has a choice between different formats of the same family. (There are less and less such situations, though.)

I had initially installed ttf-dejavu-ibx, but I think the T1 variant was pulled in as a dependency of some package. I am not sure. Will keep it in mind for the next time.

Besides, urxvt is a pretty popular terminal emulator and the one I use by default for more than 12 hours a day, so it does have to behave properly. Would you mind elaborating a bit more on those 'many problems' you had with it and infinality-bundle? Any screenshots to help me understand what was going wrong? Of course, it is always possible that a certain problem cannot be solved, but in most cases an issue crops up due to a little misconfiguration which can be fixed.

Basically, it was a spacing issue, setting

urxvt.letterSpace: -1

the situation improved a bit, but the alphabets still felt too spaced out. Setting

urxvt.letterSpace: -2

improved the situation more or less, but lowercase w was not being rendered properly.

gothmog.todi · 2014-03-25 16:42:08

x33a wrote:

Basically, it was a spacing issue, setting
urxvt.letterSpace: -1
the situation improved a bit, but the alphabets still felt too spaced out. Setting
urxvt.letterSpace: -2
improved the situation more or less, but lowercase w was not being rendered properly.

I was able to fix a very similar issue by using this version of urxvt: https://aur.archlinux.org/packages/rxvt … e-patched/

bohoomil · 2014-03-25 17:03:31

gothmog.todi wrote:

I'm not quite sure what 93-final-lang-spec-free.conf is supposed to do […]

The purpose of the file is to set the correct font to render non-Latin content. It is needed by certain scripts as it overrides 65-non-latin-foo.conf, the main configuration file for non-Latin languages. Once you disable it, sites in Japanese, Korean, Chinese and a few others will use one of the fonts specified in 65-non-latin-foo.conf, discarding language-specific nuances and forcing the 'strongest' (i.e. the highest in the hierarchy) font to display the content. Briefly, what it does, is narrow down the number of options fontconfig will use and thus reduces the probability of applying a random font for specified languages.

Prior to revision 2.11.0-21, fontconfig was configured to handle the problem a bit differently: when the language code was served in the site's header, a 'hard-wired' font family was picked to render it, like this:

  <match>
    <test name="lang" compare="contains">
      <string>zh</string>
    </test>
    <test name="family">
      <string>sans-serif</string>
    </test>
    <edit name="family" mode="prepend_first" binding="strong">
      <string>DejaVu Sans YuanTi</string>
    </edit>
  </match>

However, the solution was reported to have an unwanted impact on Chrome browser's UI and as a result was replaced by the one we have been using since. The new one is generally safer (hence it is the default method of overcoming issues with non-Latin content). Still, the weak side of it is that it still allows fontconfig to decide which font should be chosen, as opposed to the deprecated method which just ordered it to do what we wanted.

First and foremost, please describe the problem a bit further: it may be solvable once I know what application, what kind of content was involved, and which font--in your opinion--should render it instead of Noto. If you are using either Firefox or Chrome/Chromium, you can easily solve it yourself by modifying font settings for a particular group of languages (in Chrome you will need an extension to do this, though). This should still remain one of the best practices unless an application forces you to use only one font, leaving further decisions to fontconfig.

x33a · 2014-03-25 17:14:05

gothmog.todi wrote:

I was able to fix a very similar issue by using this version of urxvt: https://aur.archlinux.org/packages/rxvt … e-patched/

Thanks, will give it a try.

bohoomil · 2014-03-25 17:19:17

x33a wrote:

I had initially installed ttf-dejavu-ibx, but I think the T1 variant was pulled in as a dependency of some package. I am not sure. Will keep it in mind for the next time.

You are absolutely correct: it is a dependency for the meta package (ibfonts-meta-extended). The point was to offer a user a simple way to install the entire collection of fonts instead of multiple packages individually. However, you can reject a meta package in favour of the proper rendering. That is a perfectly correct approach.

Personally, I patch urxvt and set

URxvt*letterSpace:        -0.2

in .Xresources. This pretty much lets you fine tune the term as you wish.

Thanks for the feedback.

Edit I have not noticed gothmog.todi's response, so you have got two pieces of news in the price of one.

Last edited by bohoomil (2014-03-25 17:22:35)

x33a · 2014-03-25 19:00:53

Thanks for the reply. I'll give it another go soon and post an update.

lahwaacz · 2014-03-25 19:16:06

Speaking about ttf-dejavu-ibx vs. t1-dejavu-ib, here is the comparison for "DejaVu Sans Mono 9" on tinyterm (plain VTE terminal) -- it's ttf-dejavu-ibx on the left and t1-dejavu-ib on the right:

It's the 'combi' preset, and I did not modify anything except for selecting the font. The line spacing is obviously different for the two packages.

x33a · 2014-03-26 06:03:37

So, attempting again. This time using rxvt-unicode-patched. I hit the same ugly 'w' problem again.

Here's my .Xresources

! font rendering
xft.dpi: 84
xft.rgba: rgb
xft.autohint: false
xft.antialias: true
xft.lcdfilter: lcddefault
xft.hinting: true
xft.hintstyle: hintfull

! font settings
urxvt.font: xft:droid sans mono:pixelsize=14
urxvt.boldFont: xft:droid sans mono:bold:pixelsize=14

Here's what I get by default:

After, setting

# Using 0.1 to 0.9 didn't make any difference, i.e., the same as above
urxvt.letterSpace: 1

But, unfortunately, it is too spaced out.

I would also like to point that the ugly w doesn't show up all the time. For example, it shows up when using "ls", but not when using "find" or "ncdu" etc!

I am really out of ideas...

Edit: Well, I worked around this problem by switching to ubuntu mono. I had been using droid sans mono for a looong time, so I guess a change was warranted anyway

Last edited by x33a (2014-03-26 07:09:40)

MindfulMonk · 2014-03-26 13:36:26

Hi,

What is the default monospace font in the free preset? I want to replace all monospace fonts with PragmataPro can someone give me some hints how to do that?

progandy · 2014-03-26 13:54:03

MindfulMonk wrote:

Hi,
What is the default monospace font in the free preset? I want to replace all monospace fonts with PragmataPro can someone give me some hints how to do that?

$ fc-match monospace
LiberationMono-Regular.ttf: "Liberation Mono" "Regular"

I guess to change it do something like this in /etc/fonts/local.conf?

<alias>
    <family>monospace</family>
    <prefer>
      <family>PragmataPro</family>
    </prefer>
</alias>

Last edited by progandy (2014-03-26 13:56:21)

Arch Linux

#976 2014-03-24 08:50:31

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

#977 2014-03-24 09:41:30

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

#978 2014-03-24 11:34:44

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

#979 2014-03-24 18:10:24

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

#980 2014-03-24 21:20:10

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

#981 2014-03-24 22:51:02

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

#982 2014-03-25 05:48:22

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

#983 2014-03-25 05:54:56

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

#984 2014-03-25 05:59:28

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

#985 2014-03-25 06:44:49

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

#986 2014-03-25 06:46:52

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

#987 2014-03-25 08:27:25

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

#988 2014-03-25 10:50:52

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

#989 2014-03-25 14:03:45

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

#990 2014-03-25 15:19:26

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

#991 2014-03-25 16:21:23

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

#992 2014-03-25 16:42:08

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

#993 2014-03-25 17:03:31

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

#994 2014-03-25 17:14:05

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

#995 2014-03-25 17:19:17

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

#996 2014-03-25 19:00:53

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

#997 2014-03-25 19:16:06

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

#998 2014-03-26 06:03:37

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

#999 2014-03-26 13:36:26

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

#1000 2014-03-26 13:54:03

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

Board footer