You are not logged in.

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

likytau
Member
Registered: 2012-09-02
Posts: 142

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

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.

Offline

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

Malody
Member
Registered: 2015-09-21
Posts: 2

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

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.

Offline

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

bohoomil
Member
Registered: 2010-09-04
Posts: 2,376
Website

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

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


:: Registered Linux User No. 223384

:: github
:: infinality-bundle+fonts: good looking fonts made easy

Offline

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

likytau
Member
Registered: 2012-09-02
Posts: 142

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

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)

Offline

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

bohoomil
Member
Registered: 2010-09-04
Posts: 2,376
Website

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

@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)


:: Registered Linux User No. 223384

:: github
:: infinality-bundle+fonts: good looking fonts made easy

Offline

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

likytau
Member
Registered: 2012-09-02
Posts: 142

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

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)

Offline

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

bohoomil
Member
Registered: 2010-09-04
Posts: 2,376
Website

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

Oh yes, that makes sense now.


:: Registered Linux User No. 223384

:: github
:: infinality-bundle+fonts: good looking fonts made easy

Offline

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

Earnestly
Member
Registered: 2011-08-18
Posts: 805

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

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.

Offline

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

likytau
Member
Registered: 2012-09-02
Posts: 142

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

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

Offline

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

Malody
Member
Registered: 2015-09-21
Posts: 2

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

@bohoomil
Thank you! Your work is beautiful!

Offline

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

ozky
Member
From: Finland
Registered: 2013-08-01
Posts: 11

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

@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 ?.


Arch linux x64 lxqt acer aspire e1-571

Offline

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

likytau
Member
Registered: 2012-09-02
Posts: 142

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

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.

Offline

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

bohoomil
Member
Registered: 2010-09-04
Posts: 2,376
Website

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

@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.


:: Registered Linux User No. 223384

:: github
:: infinality-bundle+fonts: good looking fonts made easy

Offline

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

ozky
Member
From: Finland
Registered: 2013-08-01
Posts: 11

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

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)


Arch linux x64 lxqt acer aspire e1-571

Offline

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

Irseq
Member
Registered: 2015-09-30
Posts: 2

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

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

Offline

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

ozky
Member
From: Finland
Registered: 2013-08-01
Posts: 11

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

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


Arch linux x64 lxqt acer aspire e1-571

Offline

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

Irseq
Member
Registered: 2015-09-30
Posts: 2

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

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)

Offline

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

Jristz
Member
From: America/Santiago
Registered: 2011-06-11
Posts: 1,022

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

@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.


Well, I suppose that this is somekind of signature, no?

Offline

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

sano
Member
Registered: 2012-02-11
Posts: 114

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

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?

Offline

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

keepitsimpleengineer
Member
From: San Joaquin Valley, CA
Registered: 2012-06-25
Posts: 379

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

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)


Al Einstein: "Man soll die Dinge so einfach machen wie möglich ~ aber nicht einfacher." (Things should be as simple as possible ~ but not too simple.) ~ Al (Einstein) war ein Cousin von Albert, "Al" ist die Abkürzung für Aloysius

Offline

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

eduncan911
Member
Registered: 2015-05-02
Posts: 93
Website

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

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

Offline

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

reportados
Member
Registered: 2012-12-14
Posts: 20

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

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

4nt6nbm.png

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)

Offline

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

Ropid
Member
Registered: 2015-03-09
Posts: 1,069

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

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>

Offline

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

reportados
Member
Registered: 2012-12-14
Posts: 20

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

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
gtIlvgn.png

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)

Offline

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

bohoomil
Member
Registered: 2010-09-04
Posts: 2,376
Website

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

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


:: Registered Linux User No. 223384

:: github
:: infinality-bundle+fonts: good looking fonts made easy

Offline

Board footer

Powered by FluxBB