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

likytau · 2015-09-21 04:27:00

bohoomil wrote:

@likytau First of all, sorry for a bit late answer. As far as I can tell, Infinality shouldn't affect printing in any way. (I'm not a guru and can be wrong, so if anyone has a better knowledge on the subject feel free to correct me.) I've been creating mainly PDF documents with XeLaTeX so these days I'm using TTF and OTF fonts almost exclusively and the output looks OK both on paper and the screen. If you need a side by side comparison of all font formats, I'm afraid the only way is to install each and create a sample document. I believe there won't be huge differences, though. Personally, I'd get OTFs (if available) if the target medium is supposed to be paper. Most DTP / text processing applications will make use of extra features they offer which you may find quite handy.

Thanks for the answer. Maybe I need to rephrase the question, though: "Will the screen rendering of an OTF version of a font provided by infinality-bundle, differ from the screen rendering of the TTF version of that font?". I guess that could also be phrased as "Will infinality use different hinting for OTF and TTF versions of a font in a way that actually changes the final onscreen result?"
Since my main usage is for screen, and at small sizes, likely without aliasing, this is my main focus. Sorry if my mention of print was confusing -- print is a secondary concern that I want to give some consideration, but not a priority.

From what you have said above, it seems like the answer is "maybe". Oh well. After checking how many fonts I am interested in that actually have separate OTF and TTF versions (about 10 IIRC), this really isn't a big issue.

Malody · 2015-09-21 07:25:58

Hello everybody!

Tell me please. How do fonts thicker (fat) and lighter?
Where adjust smoothing?

PS I am not an English speaker, I find it difficult to understand the wiki. I was not Founded answer.

bohoomil · 2015-09-21 09:13:08

likytau wrote:

"Will the screen rendering of an OTF version of a font provided by infinality-bundle, differ from the screen rendering of the TTF version of that font?"
"Will infinality use different hinting for OTF and TTF versions of a font in a way that actually changes the final onscreen result?"

Put this way, the answer is yes, slightly. The differences aren't dramatic: simply put, TT hinter and autohinter work differently, hence there may be differences in the resulting picture. However, they are absolutely safe as they won't affect the overall "identity" of a typeface and the typographic layout.

Don't forget to embed the font(s) in your documents: having done that they will be truly portable and independent from font collections installed localy on other machines.

@Malody Please, read through the generic infinality-settings.sh: it's well-documented and self-explanatory, and will provide insight into available customization options:

https://github.com/bohoomil/fontconfig- … ettings.sh

likytau · 2015-09-21 11:28:22

bohoomil wrote:

likytau wrote:
"Will the screen rendering of an OTF version of a font provided by infinality-bundle, differ from the screen rendering of the TTF version of that font?"
"Will infinality use different hinting for OTF and TTF versions of a font in a way that actually changes the final onscreen result?"
Put this way, the answer is yes, slightly. The differences aren't dramatic: simply put, TT hinter and autohinter work differently, hence there may be differences in the resulting picture. However, they are absolutely safe as they won't affect the overall "identity" of a typeface and the typographic layout.

Thank you, that was exactly the .. hint.. I needed. I'd forgotten that OTF is autohinted for screen rendering. Because of that, it may be somewhat better than TTF for the small / aliased usages I'm intending..

Some quick tests with magra, linux biolinum|libertine, fanwood, bravo, lobstertwo, libre baskerville|caslon, ... (basically every single OTF font I've installed recently -- 22 in total) seem to confirm this, with aliased rendering being far cleaner, esp. down to tiny sizes (6-7 pt), than I've found elsewhere (eg overpass, hack, monoid, noticia). It's really remarkable.

Comparing the TTF variants of the same font to the OTF variants, they have inconsistent weighting (very common), broken lines (rare), and oscillating letter height(common at <=9pt, rare otherwise). More of their identity tends to be preserved, but in an ugly way. 'Light' and 'Semi-light' faces suffer least from these problems.

Conclusion: Manual TTF hinting is either hard to do right to begin with, or just generally not done in a way that works for aliased rendering, for whatever reason. Sinkin Sans was the only font family covered by my tests that had consistently good aliased rendering in both TTF and OTF.

I guess for each face, I want to force autohinting for the pixel sizes that the hinting fails at, and leave the hints alone at the pixel sizes that they succeed at. But only if antialiasing is off (hinting tends to do a better job with AA on). I think fontconfig can do that but not 100% sure yet. [1]

(btw, while running through those tests I noticed that the metrics on tehuti seem to be off -- it's 50-75% of the size of most other fonts at a given point size; Is that 'patchable' via fontconfig?)

[1] EDIT: I think the kind of thing I'm looking for is like

<match target="font">
  <test name="antialias" compare="eq">false</test>
  <!-- maybe should be fullname, instead, given how specific it is. -->
  <!-- for example FONTNAME='Andada Bold Italic' -->
  <test name="family" compare="eq">$FONTNAME</test>
  <test name="pixelsize" compare="eq">12</test>
  <edit name="autohint" mode="assign">true</edit>
</match>

(many such rules, autogenerated from a simple blacklist or whitelist.)

Last edited by likytau (2015-09-21 11:53:43)

bohoomil · 2015-09-22 05:55:45

@likytau I'm wondering, why is it actually so important to you? I mean, when you create a document, the way it's rendered on other machines doesn't depend on your rendering engine. Other OSs and applications (e.g. Acrobat) will actually make it look accordingly to their own technical capabilities. The rendering engine doesn't directly modify the physical structure of a font: all it does is reproduce its picture following the specs of the backend in use. Basically, it works just like any other reproducer (better yet: a decoder), be it audio or video. The document -- the source it uses on the input -- is "fixed" in all cases.

Last edited by bohoomil (2015-09-22 05:58:29)

likytau · 2015-09-22 06:32:09

Raster images is mainly what I'm talking about, and raster images don't have that issue; if a png I send to you has any different pixels when displayed on your machine than it does on my machine, that's a bug.

Infinality in this instance is a tool to make a good rendering, which can then be preserved or tweaked as needed.

Last edited by likytau (2015-09-22 06:34:15)

bohoomil · 2015-09-22 07:07:14

Oh yes, that makes sense now.

Earnestly · 2015-09-22 11:03:34

By the way the target screen's pixel density (DPI/PPI) can make a dramatic difference when viewing fonts even when they've been rasterised, therefore using rasterisation is not a universal mechanism for faithfully displaying the effects of anti-aliasing or subpixel metric hinting as you view them on your screen.

likytau · 2015-09-22 11:22:39

That's normally coped with by upscaling, nearest neighbour, by an integer factor.

Malody · 2015-09-22 15:32:51

@bohoomil
Thank you! Your work is beautiful!

ozky · 2015-09-27 12:29:33

@Bohoomil i get that issue is css side problem that sites forces font exact size to something like 16px and font scaling factor to 1.5em,what is huge size to small screen like 15,6" laptop i have.
Can those css font size forced with some own css hack ?.

likytau · 2015-09-27 23:50:58

ozky wrote:

@Bohoomil i get that issue is css side problem that sites forces font exact size to something like 16px and font scaling factor to 1.5em,what is huge size to small screen like 15,6" laptop i have.
Can those css font size forced with some own css hack ?.

If that is really the problem, then I suggest you look into Stylish, at least if you are running firefox or chrome.

bohoomil · 2015-09-28 01:59:06

@ozky Tweaking CSS files doesn't seem to be a good idea IMO: it fixes nothing, just masks the problem. For now, try the following:

1. Check out which fc-preset you are using, assuming you installed a font collection from the ib repository. Run 'fc-presets check' and see if the result is 'free'.
2. Don't you have any custom fontconfig settings in $XDG_CONFIG_HOME/fontconfig? If you do, please disable everything but the global configuration.
3. Check the font settings in your DE's control panel, especially the DPI (set it to 96). Basically, you should duplicate the settings found in infinality-settings.sh there.

ozky · 2015-09-28 14:35:44

I use ibfonts-meta-base and ibfonts-meta-extended and fc-presets-check says free is used.
I have followed that original infinality guide to lock local fontconfig settings file without any special configuration.
Lxqt set dpi by default to 96dpi by default to fontconfig but it's removed due to locked fonts.conf.
Edit:i use qupzilla not firefox.

Last edited by ozky (2015-09-28 14:36:51)

Irseq · 2015-09-30 17:34:04

Hello, I'm using the bundle and "Hack" typeface from the fonts collection. I would like to use it in URxvt, however the regular style seems to have problems with gaps. I'm not sure if it's due to fontconfig patches or the font as it is displayed correctly in gtk applications.
(Hack regular) http://i.imgur.com/1gkWVq6.png
(Hack bold) http://i.imgur.com/wr8kTNa.png

ozky · 2015-09-30 18:35:09

If that problem is fonts mapping try to use aur patched version fix those fonts problems. https://aur.archlinux.org/packages/rxvt … e-patched/

Irseq · 2015-09-30 18:55:09

I am using the patched version. I've also tried using st, the result is the same: http://imgur.com/a/SDGQQ

~~
I've fixed the problem by downloading the font from author's github (https://github.com/chrissimpkins/Hack). I don't know what is the problem with the version in ibfonts repo, but the upstream one works properly: http://i.imgur.com/Gk2driq.png

Last edited by Irseq (2015-10-04 17:30:40)

Jristz · 2015-10-24 04:01:51

@bohoomil maybe you want look the newest noto sans in comunity, I think you need a conflict here and there or try copy the distribution used to prevent confussion and chaos in the font namis or equivalency.

sano · 2015-10-29 14:13:06

The most recent update for the meta-packages gives following error:

:: Starting full system upgrade...
:: Replace ttf-noto-sans-ib with infinality-bundle-fonts/ttf-noto-fonts-ib? [Y/n] y
:: Replace ttf-noto-sans-multilang-ib with infinality-bundle-fonts/ttf-noto-fonts-nonlatin-ib? [Y/n] y
:: Replace ttf-noto-serif-ib with infinality-bundle-fonts/ttf-noto-fonts-ib? [Y/n] y
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: ttf-noto-serif-multilang-ib: requires ttf-noto-serif-ib

Did I overlook something?

keepitsimpleengineer · 2015-10-29 15:25:58

sano wrote:

The most recent update for the meta-packages gives following error:
:: Starting full system upgrade...
...
error: failed to prepare transaction (could not satisfy dependencies)
:: ttf-noto-serif-multilang-ib: requires ttf-noto-serif-ib
Did I overlook something?

Same here.

UPDATE

Ref: https://plus.google.com/+bohoomil-infin … R1K61viFm6

Two fonts need to be removed w/o dependency checks

$ yaourt -Rdd ttf-noto-sans-multilang-ib  ttf-noto-serif-multilang-ib
 -or-
# pacman -Rdd ttf-noto-sans-multilang-ib  ttf-noto-serif-multilang-ib

The -dd optionf forces no dependency checks, a single -d will trigger another.
Be sure to complete the update after removing the fonts... .. .

Last edited by keepitsimpleengineer (2015-10-29 16:05:57)

eduncan911 · 2015-10-30 13:31:19

I am not comfortable with removing packages and skipping dependency checking...

Do this instead:

sudo pacman -R ibfonts-meta-extended ttf-noto-serif-multilang-ib
sudo pacman -Syu ibfonts-meta-extended

And let the system update normally.

Sourced from this: https://bbs.archlinux.org/viewtopic.php?id=204450

reportados · 2015-11-04 03:41:43

Updating the noto fonts messed up my CJK fonts again in my terminal.

The CJK fonts should be bigger and not so far apart. I'm using rxvt-unicode-patched from the AUR.

ttf-noto-fonts-cjk-ib 1.004-1
ttf-noto-fonts-ib 20150929-1
ttf-noto-fonts-nonlatin-ib 20150929-1

my Xresources is

URxvt*termName : rxvt-256color
URxvt*loginShell : true
URxvt.perl-ext-common : default,matcher,clipboard
URxvt.url-launcher : /usr/bin/firefox
URxvt.matcher.button : 1
URxvt.scrollBar : false
Xft.antialias: 1
Xft.autohint: 0
Xft.dpi: 96
Xft.hinting: 1
Xft.hintstyle: hintfull
Xft.lcdfilter: lcddefault
Xft.rgba: rgb
#define normal xft:DejaVu Sans Mono:style=Book:size=8:antialias=true
URxvt.font : normal
URxvt.boldFont : normal
URxvt.italicFont : normal
URxvt.bolditalicFont : normal

Before, fontconfig would automatically use noto sans cjk jp. Now, I'm not sure, because even if I explicitly change my fonts in .Xresources to

#define normal xft:DejaVu Sans Mono:style=Book:size=8:antialias=true,xft:Noto Sans CJK JP:style=Regular:size=9:antialias=true

The same problem occurs.

Last edited by reportados (2015-11-04 03:44:24)

Ropid · 2015-11-04 14:01:53

I don't know what's going on with your "xft:DejaVu Sans Mono:style=Book:size=8:antialias=true,xft:Noto Sans CJK JP:style=Regular:size=9:antialias=true" list of fonts not working right.

About "DejaVu Sans Mono" changing, take a look at this:

$ fc-match -s "dejavu sans mono"

This is the order of how fonts are used when characters are missing in a font. That might help to find out what's going on.

I guess how things work is, DejaVu Sans Mono is aliased to the monospace name. Other fonts are as well aliased to monospace and that's where the order you see gets pulled from. You could take a look at monospace to see if that's what's happening:

$ fc-match -s "monospace"

You probably see the same order there except for "dejavu sans mono" perhaps not being in front.

To customize things, you could tweak what's going on with "monospace". You can look at the file "/etc/fonts/conf.d/60-latin.conf" to see how that works. You would put your own "monospace" definitions in a file that gets read earlier. I think this can be in your home as there's a "28-user.conf" that reads from "~/.config/fontconfig/conf.d/", or you could put it in a file like "/etc/fonts/conf.d/59-mono-aliases.conf".

Something else that's possible is changing what's going on with one specific font:

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

  <!-- Font fallbacks for Fantasque Sans Mono -->
  <alias>
    <family>Fantasque Sans Mono</family>
    <prefer>
      <family>Fantasque Sans Mono</family>
      <family>DejaVu Sans Mono</family>
      <family>M+ 2m</family>
      <family>Droid Sans Fallback</family>
    </prefer>
  </alias>

</fontconfig>

That's how I forced the order of fall-back fonts for the "fantasque sans mono" font I like to use in terminal windows. You could try this here:

  <alias>
    <family>DejaVu Sans Mono</family>
    <prefer>
      <family>DejaVu Sans Mono</family>
      <family>Noto Sans CJK JP</family>
    </prefer>
  </alias>

reportados · 2015-11-04 21:55:07

I tried creating a 28-user.conf in ~/.config/fontconfig/conf.d/ with this inside:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<alias>
<family>DejaVu Sans Mono</family>
<prefer>
<family>DejaVu Sans Mono</family>
<family>Noto Sans CJK JP</family>
</prefer>
</alias>
</fontconfig>

However, it did nothing for urxvt. What is weird is that using a terminal such as termite doesn't have this problem. I do notice that the font in termite still isn't as big as it was before in urxvt prior to the update. I'm not sure if there's a way or setting to make CJK fonts as big as they can to fit in the terminal?

Here's what it looks like under termite

Again, I feel that under termite, the CJK fonts aren't as big as they should be. I feel that the spacing between each character is still too large, and that the characters can be a bit bigger to fill in this unused space. In urxvt, before the update, I think they would automatically be as big as they can.

Last edited by reportados (2015-11-04 21:56:40)

bohoomil · 2015-11-04 22:29:08

@reportados Check otf-noto-fonts-cjk-ib instead of the default CJK package.

Arch Linux

#1751 2015-09-21 04:27:00

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

#1752 2015-09-21 07:25:58

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

#1753 2015-09-21 09:13:08

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

#1754 2015-09-21 11:28:22

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

#1755 2015-09-22 05:55:45

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

#1756 2015-09-22 06:32:09

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

#1757 2015-09-22 07:07:14

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

#1758 2015-09-22 11:03:34

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

#1759 2015-09-22 11:22:39

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

#1760 2015-09-22 15:32:51

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

#1761 2015-09-27 12:29:33

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

#1762 2015-09-27 23:50:58

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

#1763 2015-09-28 01:59:06

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

#1764 2015-09-28 14:35:44

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

#1765 2015-09-30 17:34:04

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

#1766 2015-09-30 18:35:09

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

#1767 2015-09-30 18:55:09

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

#1768 2015-10-24 04:01:51

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

#1769 2015-10-29 14:13:06

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

#1770 2015-10-29 15:25:58

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

#1771 2015-10-30 13:31:19

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

#1772 2015-11-04 03:41:43

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

#1773 2015-11-04 14:01:53

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

#1774 2015-11-04 21:55:07

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

#1775 2015-11-04 22:29:08

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

Board footer