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

psychoticmeow · 2014-04-11 19:22:59

I'm having some trouble with Source Sans Pro as installed:

infinality-bundle-fonts/t1-source-sans-pro-ibx 2.3-2 (infinality-bundle-fonts-extra) [installed]
    A set of OpenType fonts designed for user interfaces. Type 1 version.

There's some strange spacing happening before the letter t at some sizes:

Last edited by psychoticmeow (2014-04-11 19:23:29)

gondsman · 2014-04-11 20:19:25

BTW, I've installed "t1-source-sans-pro-ibx" and now the font rendering in wine is flawless. Thank you very much!

bohoomil · 2014-04-11 21:45:53

@doggone Nimbus Sans L is not a good one for UI, IMO. This is a free alternative to Helvetica and/or Arial from URW (gsfonts in [extra], t1-urw-fonts-ib in the [ib-fonts] repository: otherwise Nimbus family is a terribly pricey, commercial typeface) and it was not created with a user interface as its target application in mind. (By the way, the original Helvetica and its free equivalent, TeX Gyre Heros, behave in a similar manner and in quite a few aspects they all lack proper optimization for screen.) Nimbus and its relatives share similar features by design and it is generally not possible to manipulate font's internal structure via an interpreter or rendering engine (we can modify the behaviour of freetype's components of course, but this means affecting rendering of multiple fonts, for instance all using PostScript or TrueType instructions). The best you can do is choose a family that is better suited for screen work: check out Droid Sans for instance, or Source Sans Pro (I have been successfully using it for a long time; there are dozens of other options, though).

@Hspasta This is definitely not what you shoud see with an out-of-the-box ib setup:

MalgunGothic & FF

Are you sure the settings are correct? No broken symlinks, no forgotten tweaks @ your $HOME/.config/fontconfig, infinality-settings.sh v.0.4.7.4 using style 1, nothing surprising in .Xresources (check it with 'xrdb -q | grep Xft')? If you compare both shots you will notice differences in rendering. I am quite baffled, to be honest, as nothing like this should happen…

@TiZ

make my fonts look like they did on Xubuntu

Well, this is totally against what I am trying to do. If I wanted to copy Ubuntu's look and feel, I would stick with Ubuntu's freetype in the first place, right? The $SHELL rule of mine is:

Infinality-bundle != original Infinality != Ubuntu != Windows != OS X

More or less. :-)

so I removed it and used the standard repo ttf version

Oh well. You should simply install the TTF version from the infinality-bundle-fonts repository (the package is available as ttf-dejavu-ibx: it includes separate settings for the TT variant of the font to be used with Infinality-bundle).

As regards DPI (as well as other settings), this is actually up to the end user what value is set. 96 has been a standard value we stick with, but a user is by no means forced to accept it. For example, avid Chrome/Chromium users should check out 72 dpi instead

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

(to be set in $XDG_CONFIG_HOME/fontconfig/fonts.conf), as advised by the Infinality patchset's author, because this should improve Chromium's conversion of pixels to points and the overall user experience. Briefly, ib comes with default settings that should work for most users, but it is virtually impossible to assume that they will not need to be tweaked under particular circumstances. Sadly (or not): I can try and standardize a few numbers and expect that this way a similar experience can be reproduced, but it is far beyond my skills to standardize user's physiology of seeing. Hence, screens owners still have to do their job, too, if necessary. ;-)

@psychoticmeow I hate to respond with 'I cannot reproduce it' or 'Everything is fine', but sometimes that's how it is. :-) Could you please check your DE font settings? I am not using any DE, so I set everything Gtk3-related in ~/.gtk-3.0/settings.ini. This is what it reads for the relevant part:

gtk-xft-antialias=1
gtk-xft-hinting=1
gtk-xft-hintstyle=hintfull
gtk-xft-rgba=rgb

The global Xft (as per /etc/profile/infinality-settings.sh) values are standard, i.e.

Xft.antialias:  1
Xft.autohint:   0
Xft.dpi:        96
Xft.hinting:    1
Xft.hintstyle:  hintfull
Xft.lcdfilter:  lcddefault
Xft.rgba:       rgb

@gondsman I am really glad to read this! Thanks for the good news!

Last edited by bohoomil (2014-04-11 21:50:51)

psychoticmeow · 2014-04-11 22:13:29

I'm using Gnome 3, so I'm not actually sure were the settings are stored, but in the tweak tool it says:

Hinting: Full
Antialiasing: RGBA

Otherwise I'm using the default settings from infinality-settings.sh, but with style 4 "darker & smoother #2".

bohoomil · 2014-04-11 22:33:57

Do you have any active fontconfig settings @ $XDG_CONFIG_HOME/fontconfig, e.g. in fonts.conf file or conf.d subdirectory (if present)?

psychoticmeow · 2014-04-11 22:45:07

↪ sudo locate fonts.conf
/etc/fonts/fonts.conf
/etc/fonts/conf.avail/10-scale-bitmap-fonts.conf
/etc/fonts/conf.avail.infinality/10-scale-bitmap-fonts.conf
/etc/fonts/conf.avail.infinality/90-non-tt-fonts.conf
/etc/fonts/conf.avail.infinality/90-tt-fonts.conf
/etc/fonts/conf.d/90-non-tt-fonts.conf
/etc/fonts/conf.d/90-tt-fonts.conf
/usr/lib/vmware/libconf/etc/fonts/fonts.conf
/usr/lib/vmware-installer/2.1.0/lib/libconf/etc/fonts/fonts.conf
/usr/share/doc/fontconfig-infinality-ultimate/fontconfig/fonts.conf
/usr/share/doc/fontconfig-infinality-ultimate/fontconfig/conf.avail/91-tt-monospace-fonts.conf

I don't even ... what should and shouldn't be there?

bohoomil · 2014-04-11 22:52:48

The only redundant ones are '10-scale-bitmap-fonts.conf', you may want to remove them and check if it fixes the issue. Besides, I have just uploaded the TTF version of the same font package, so please install it (it is 'ttf-source-sans-pro-ibx') and see if it changes anything.

TiZ · 2014-04-12 07:52:20

bohoomil wrote:

Well, this is totally against what I am trying to do. If I wanted to copy Ubuntu's look and feel, I would stick with Ubuntu's freetype in the first place, right?

No, no, not vanilla Xubuntu. Xubuntu with the Infinality packages, from a PPA. Specifically, this one: https://launchpad.net/~no1wantdthisname/+archive/ppa

Oh well. You should simply install the TTF version from the infinality-bundle-fonts repository (the package is available as ttf-dejavu-ibx: it includes separate settings for the TT variant of the font to be used with Infinality-bundle).

Mayhaps I will in the future, when I feel more confident about what's going on.

As regards DPI (as well as other settings), this is actually up to the end user what value is set. 96 has been a standard value we stick with, but a user is by no means forced to accept it. [...] Sadly (or not): I can try and standardize a few numbers and expect that this way a similar experience can be reproduced, but it is far beyond my skills to standardize user's physiology of seeing. Hence, screens owners still have to do their job, too, if necessary. ;-)

I'm not sure that this answers my question. What I'm trying to understand is why I had to increase my DPI by 2 in order for Arch to look like Xubuntu did. They both were using Infinality packages, so that shouldn't have been necessary, right? The only thing I could think was that there was a newer set of patches (2013-05-15 is the version used on Ubuntu's PPA) that changed something in regards to DPI handling, or there is some sort of configuration that is different here than it is over there.

doggone · 2014-04-12 12:10:36

bohoomil wrote:

@doggone Nimbus Sans L is not a good one for UI, IMO. This is a free alternative to Helvetica and/or Arial from URW (gsfonts in [extra], t1-urw-fonts-ib in the [ib-fonts] repository: otherwise Nimbus family is a terribly pricey, commercial typeface) and it was not created with a user interface as its target application in mind. (By the way, the original Helvetica and its free equivalent, TeX Gyre Heros, behave in a similar manner and in quite a few aspects they all lack proper optimization for screen.) Nimbus and its relatives share similar features by design and it is generally not possible to manipulate font's internal structure via an interpreter or rendering engine (we can modify the behaviour of freetype's components of course, but this means affecting rendering of multiple fonts, for instance all using PostScript or TrueType instructions). The best you can do is choose a family that is better suited for screen work: check out Droid Sans for instance, or Source Sans Pro (I have been successfully using it for a long time; there are dozens of other options, though).

Alright, thanks for the information!

psychoticmeow · 2014-04-12 15:15:37

bohoomil wrote:

The only redundant ones are '10-scale-bitmap-fonts.conf', you may want to remove them and check if it fixes the issue. Besides, I have just uploaded the TTF version of the same font package, so please install it (it is 'ttf-source-sans-pro-ibx') and see if it changes anything.

I ended up completely removing /etc/fonts and reinstalling, the difference is light and day, I think you'll agree:

It's amazing how subtle the difference from obviously broken to just right is.

Last edited by psychoticmeow (2014-04-12 15:19:26)

bohoomil · 2014-04-13 01:23:21

@Hspasta I got it. It is Chromium, again… This happens because ArchWiki does not change language to Korean for the main content section. As Chromium is unable to pick the right font for the script from 65-non-latin.conf, it just grabs WenQuanYi Micro Hei to render the entire non-Latin content. What's more, we cannot even change the fontface in the advanced settings because this only works when the language of the site has been correctly set.

What you can do with it:

Kill Chromium, it deserves it.
Use an extension that would let you modify font settings per-site (this one does it for example; there is a side effect, however: NanumGothic will be set a default sans-serif for the entire www.archilinux.org).

@psychoticmeow So I guess everything is fine again. Great!

Last edited by bohoomil (2014-04-13 01:24:50)

Hspasta · 2014-04-13 01:34:57

I see...would there be a way for me to make it fallback to nanum instead of wenquanyi for non-latin content?

brebs · 2014-04-13 10:30:57

bohoomil wrote:

As regards DPI (as well as other settings), this is actually up to the end user what value is set. 96 has been a standard value we stick with, but a user is by no means forced to accept it. For example, avid Chrome/Chromium users should check out 72 dpi instead

What's the rationale for that? It's nuts, compared to my screen - the physical reality:

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

I must have posted that hundreds of times. Its TWO numbers, horizontal and vertical - they both affect the font-rendering calculation, as well they should, when trying to draw e.g. a circle on a variety of monitors.

Here's a roundup of DPI threads (and xorg bugzilla arguments).

bohoomil · 2014-04-13 21:49:07

@Hspasta There is still the old workaround we do not use by default any more. Just put this in /etc/fonts/conf.d/:

$ cat /etc/fonts/conf.d/65-override-ko.conf

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>

  <match target="pattern">
    <test qual="any" name="family">
      <string>sans-serif</string>
    </test>
    <edit name="family" mode="prepend" binding="strong">
      <string>Noto Sans</string>
      <string>Liberation Sans</string>
      <string>NanumGothic</string> <!-- ko -->
    </edit>
  </match>

</fontconfig>

Beware that this affects not only anything Korean, unfortunately.

@brebs Of course, I know about it. However, we still use .Xdefaults and this is the only DPI value I was talking about (and the only one that I force in infinality-settings.sh).

As we can remember, the 72 dpi workaround in fontconfig settings came originally in infinality.conf by infinality.net:

  <!-- Set DPI.  dpi should be set in ~/.Xresources to 96 -->
  <!-- Setting to 72 here makes the px to pt conversions work better (Chrome) -->
  <!-- Some may need to set this to 96 though -->
  <match target="pattern">
    <edit name="dpi" mode="assign">
      <double>96</double>
    </edit>
  </match>

In my fontconfig, I do not set any numbers in fonts.conf at all: it has been left as a possible solution merely for those who may find it handy (there was at least one case mentioned in this thread--orschiro's, IIRC--where setting it to 72 fixed an issue with dialogue boxes in Chrome). Other than that, I leave it up to the user to set the values if/as necessary, which I believe is a sane approach.

RibShark · 2014-04-14 18:11:27

When viewing https://extensions.gnome.org/, and some other websites in Epiphany, the fonts look REALLY bad:

Any fix for this?

Last edited by RibShark (2014-04-14 18:29:52)

brebs · 2014-04-14 19:42:21

bohoomil wrote:

the 72 dpi workaround in fontconfig settings came originally in infinality.conf by infinality.net

Doesn't matter where it came from. Judge it on its mathematical merits. It's an obvious ludicrous hack, and should be labelled as a hack to be *avoided* and bugs filed upstream, rather than as a reasonable setting. We want fonts to look their best, not *deformed* by having the calculations assume 72x72 or 96x96 DPI rather than the physical reality of e.g. 131x119 or 106x108.

bohoomil wrote:

setting it to 72 fixed an issue with dialogue boxes in Chrome

Er, let me explain it better with a car analogy...

A Ford model has a loose boot door, because it was manufactured too small. So the government steps in and decrees that all boot doors must be exactly 96cm in both width and height, effective immediately, and this applies to all cars, from minis to camper vans.

Make sense? I thought not

bohoomil · 2014-04-14 19:46:31

@RibShark A quick answer: no. I have been trying to do something about WebKit3 browsers (Epiphany and Midori), but even with stock freetype2 they did not look much better. (I tested the browsers with and without Gnome 3: in both cases results were equally bad.) I am almost sure the problem lies in the WebKit3 engine, not in freetype2 library (clean or patched) or Gtk3 toolkit (which otherwise works fine).

bohoomil · 2014-04-14 23:23:33

brebs wrote:

It's an obvious ludicrous hack, and should be labelled as a hack to be *avoided* and bugs filed upstream, rather than as a reasonable setting.

This makes me think of Google's approach to web browsing (in Linux at least: I physically have not got access to anything non-*nix to verify my cheap theories). As I do not believe in logic behind discrimination and monopoly, I simply did not want to conclude the headaches Chromium has been producing by its being a piece of worthless crap that just sucks. Besides, even if I cannot accept Google politics in every respect, I still highly respect many of their projects in technical terms. That is why, stating that Chromium was nothing but a misconception made popular--because it did not work the way I wanted it to--seemed both deeply unfair and not true: saying so I would merely voice my frustration and ignorance, let alone disrespect towards all Chromium users out here who have been kind enough to start using my packages. (Those guys also pushed plenty of valuable testing data right in front of my nose, so not making use of it in order to reconsider my private assumptions and possibly correct myself seemed terribly stupid at best.)

All in all, I think I have come a bit closer to the reason for Chromium being what it is and why it has been making my desperate efforts to reshape its text rendering capabilities helpless. It is not because Chromium is so bad: on the contrary, it is because of its being so good. It seems to have been devised upon the most legitimate premise that if a website has been correctly coded, there is no way for Chromium not to render it correctly, too. Ergo: if the output you get is invalid, validate the input and reload the page. Of course, the obvious cumbersomeness behind the generally perfect thinking is the number of lines of code that should be revised to make the Web the best of all virtual worlds.

brebs wrote:

let me explain it better with a car analogy

I like analogies and I have one, too. It is different of course because our backgrounds differ. Besides, as I simply owe too much to all your great texts and pieces of code you have generously contributed and I have benefited from, I have no reason to either neglect your reasoning or otherwise disclose its weak points. Hence, it is roughly my way of dealing with too small car doors whose imperfectness I consider to be tightly bound to their constructors' human condition:

jumpthecurve.net wrote:

[…] it is worth unlearning perfection and, instead, embrace the habit of practicing imperfection. To better understand this concept, consider the practice of Persian Rug weavers who intentionally include imperfections in their rugs. Their purpose is two-fold. First, the habit keeps the weavers humble and reminds them that while true perfection can be pursued it can rarely be attained. Second, the habit makes it easier for them to ship a product to market because they don't needlessly worry about creating the perfect product. As a result, they end up producing more rugs and getting progressively better with each one they create.
Amish quilt-makers and Navajo artisans employ similar policies with regard to their wares but an old Persian proverb best captures the essence of practicing imperfection: "A Persian Rug is perfectly imperfect, and precisely imprecise."
The best way to get better is to stop worrying about perfection and, counter-intuitively, begin practicing imperfection because it will actually get you closer to the goal of perfection.

Makes sense? I think so.

Earnestly · 2014-04-15 09:22:42

It doesn't make sense at all to me. What is essentially a mathematical function is not comparable to Persian rug weavers in the slightest. The notion is simple, that we should stop worrying and practice instead, but this is about mathematics, you don't introduce errors "to keep one humble", it's absurd!

(PS: I realise that hinting is a hack due to fact we can't properly convert analogue fonts to digital due to a tiny sampling size (pixel density), so a lot of it is pretty subjective, but we can at least get the math model right…)

bohoomil · 2014-04-15 15:44:43

We do not even need to intentionally introduce errors and, as a matter of fact, most of us do not do it: an error is already there, in anything we do, although it is always elsewhere than we expect it to be (in this case it is in the uncompromising pursuit of perfectness). It is misplaced by nature, so it is impossible to predict its position and, as a result, secure one's work against it in advance. This way, an intentional "injection" of an error would be a manifesto of the creator's consent to this unpredictability, a deliberate rejection of any model that intends to protect a piece of work against imperfectness or impurity. Paradoxically, such a self-conscious act of marking one's work imperfect by design opens it to further improvement and greater flexibility, it makes it better fit in the world as it is rather than the one it should be. Hence, I accept a limited number of hacks whenever I am unable to introduce a "clean" solution. The bottom line is the nth release of the packages which hopefully make a few guys' lives easier. With this last thing in mind, I consider preaching math and condemning workarounds to be merely a waste of time (and HDD space).

And a brief note on my browsing example: a better web browser would be the one which assumes that it is still possible to render a website correctly even if it is missing a tag or two where a coding codex states it should not. If Chromium cannot calculate the language of the content properly while half a dozen of other browsers using the same typeface and fontconfig settings can do this, it means that its following strictly the "should be" model of a correctly coded website simply fails. What makes it even more puzzling to me is the fact that the font in question (from Nanum family) is the one being promoted by Google itself…

It doesn't make sense at all

Actually it does once you share my background and/or make an attempt to fix things as they are in the real world.

martindemello · 2014-04-15 18:55:24

I just uninstalled and reinstalled infinality (wanted to see what the standard arch rendering looked like these days), and noticed there was a fonts metapackage too, so I installed that. All works well, except for one problem (that I was definitely not having before) - the spacing between lines in my terminal is slightly too large. Any idea what has changed around that?

bohoomil · 2014-04-16 00:38:58

@martindemello Could you please write which terminal emulator and font are you using? May I ask for a screenshot, too?

martindemello · 2014-04-17 04:56:12

@bohoomil terminator, nominal font Deja Vu Sans Mono 10 (which size it does not appear to be honouring). on further experimenting, it seems to be a problem with DejaVu Sans Mono rather than the terminal. Here's a screenshot comparing Liberation Mono (top) with DejaVu Sans Mono (bottom).

http://imgur.com/wQb5GvL

fonts:

infinality-bundle-fonts/t1-dejavu-ib 2.34-5 (infinality-bundle-fonts) [installed]
infinality-bundle-fonts/ttf-liberastika-ib 1.1.3-3 (infinality-bundle-fonts)

(I'm guessing it's a type1 versus ttf issue but I don't know what to do about that)

bohoomil · 2014-04-17 07:17:51

This:

# pacman -R ibfonts-meta-base ibfonts-meta-extended
# pacman -S ttf-dejavu-ibx

BTW, the TT version will be set default again.

Vixus · 2014-04-17 14:06:19

A couple of questions:

I'm having a recent issue where bitmap fonts with unicode symbols have the symbols oddly truncated (like a few pixels are cut off on the right). Could this have something to do with infinality? The font in question is phallus' lemon font: http://github.com/phallus/fonts.git
I removed my /etc/fonts directory and reinstalled infinality-bundle and ibfonts-meta-base and now the default font everywhere (Firefox, Adobe Flash) is the first font (alphabetically) in my ~/.fonts/TTF directory. Is there any way of fixing this?

Arch Linux

#1051 2014-04-11 19:22:59

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

#1052 2014-04-11 20:19:25

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

#1053 2014-04-11 21:45:53

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

#1054 2014-04-11 22:13:29

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

#1055 2014-04-11 22:33:57

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

#1056 2014-04-11 22:45:07

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

#1057 2014-04-11 22:52:48

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

#1058 2014-04-12 07:52:20

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

#1059 2014-04-12 12:10:36

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

#1060 2014-04-12 15:15:37

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

#1061 2014-04-13 01:23:21

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

#1062 2014-04-13 01:34:57

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

#1063 2014-04-13 10:30:57

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

#1064 2014-04-13 21:49:07

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

#1065 2014-04-14 18:11:27

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

#1066 2014-04-14 19:42:21

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

#1067 2014-04-14 19:46:31

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

#1068 2014-04-14 23:23:33

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

#1069 2014-04-15 09:22:42

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

#1070 2014-04-15 15:44:43

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

#1071 2014-04-15 18:55:24

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

#1072 2014-04-16 00:38:58

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

#1073 2014-04-17 04:56:12

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

#1074 2014-04-17 07:17:51

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

#1075 2014-04-17 14:06:19

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

Board footer