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

Earnestly · 2015-07-02 13:47:44

Perhaps you should look into patching freetype2 to expose a configuration instead of bloating the environ for every child process on the system after those are loaded.

wildfowl · 2015-07-02 18:26:05

Those are enviornment variables which apply the Infinality settings globally. They don't bloat every process just as not setting any values (or default settings rather) to those variables doesn't bloat the environment for each process.

Earnestly · 2015-07-02 18:44:39

Wildfowl, where do you set them? In your shell's profile ("export")? Do you see them when you run the 'env' command?

Last edited by Earnestly (2015-07-02 18:48:03)

wildfowl · 2015-07-02 19:04:30

I actually set them in Xsession.d (it's a Debian thing).
But it's not relevant to your last post.

Earnestly · 2015-07-02 19:05:48

Wildfowl, sorry but can you answer the last question? Do they show up in the output of the 'env' command?

wildfowl · 2015-07-02 19:48:18

Yes the variables do show up with:

$ env

wildfowl · 2015-07-02 21:01:11

@brebs

Thanks, not quite what I was after but a worthwhile contribution none the less.

Earnestly · 2015-07-02 21:20:24

Wildfowl, right, so it does bloat the environment for every child process of, in your case, the X server. That means for every character you put into the environment, each process inherits that number of bytes, regardless of whether or not they use it.

See environ(7) (and environ(3p) for the POSIX definition).

wildfowl · 2015-07-02 22:55:18

Earnestly wrote:

Wildfowl, right, so it does bloat the environment for every child process of, in your case, the X server. That means for every character you put into the environment, each process inherits that number of bytes, regardless of whether or not they use it.
See environ(7) (and environ(3p) for the POSIX definition).

To add some more background info to this. /etc/profile is read during login shells. I have settings there which apply to the console only.
I also have separate settings as part of the Xorg configuration which apply only to the xserver. Running env shows only the environment variables applied to the console. The xserver has its own environment variables.

Regardless. I don't understand why (perhaps it is) the environment is copied for each process. The entire notion of an env is that you don't copy (recreate) anything but use and reuse the data which is already present. It's the Infinality/FT libraries which are simply being executed using the data from the env. It makes no difference if you hardcode these values into the libraries directly or save for the conveninece of changing them on the fly through the env.

Earnestly · 2015-07-03 00:37:15

Regardless. I don't understand why (perhaps it is) the environment is copied for each process.

Because of how fork() and exec*() work on UNIX (and Linux). You can read the respective manuals; fork(2), execve(2) and perhaps clone(2). Of course if the environment wasn't copied in then anything which changes it will become extremely racy. Programs would also need to restore any changes (avoiding race conditions at the same time). Many programs also clear out the environment for security reasons such as sudo which will override PATH with an admin configured secure_path along with env_reset. Needless to say, the opposite could be done for malicious intent.

It makes no difference if you hardcode these values into the libraries directly or save for the conveninece of changing them on the fly through the env.

It does make a difference if you use the environment rather than a configuration file as every process will inherit the environment. It makes no sense that every subsequent 'cat', 'sed' and 'ls' calls contains the added environment variables when only freetype requires the information.

The TLPI (The Linux Programming Interface) is worthwhile if you can get hold of a copy.

Last edited by Earnestly (2015-07-03 00:56:04)

wildfowl · 2015-07-03 23:28:49

It's the first time I've heard the statement of "bloating the envionment" TBH.

EDIT. Yes I see now, you are referring to the Process Locality of Environment Variables. The enviornment is inherited by each process and sub processes but the inheritance is local with respect to each process. Right so on that note I've understood what you mean by bloating the environment.

https://help.ubuntu.com/community/EnvironmentVariables

Last edited by wildfowl (2015-07-05 23:58:55)

haiarch · 2015-07-08 07:05:46

i got problem with Linux WPS Office , so i remove conflicted fontconfig-infinality-ultimate-2.11.1-28
the WPS cannot load the font properly

and how to repair fontconfig to support WPS office ?

Last edited by haiarch (2015-07-08 07:07:02)

bohoomil · 2015-07-09 01:43:28

@haiarch I believe fontconfig-iu-comp may be what you're looking for.

AaronBP · 2015-07-09 03:49:53

wildfowl wrote:

It's the first time I've heard the statement of "bloating the envionment" TBH.

I don't think an extra 1kb per process is *really* relevant in 2015 anyway.

reportados · 2015-07-10 15:46:25

Hi, after updating Adobe Source Han Sans CJK families to version 1.003, the fonts got messed up in my terminal. If I downgrade to 1.001-2, it's works fine again.

This is what it should look like:
version1

This is what happened after I updated to 1.003
version2

My terminal is rxvt-unicode-patched from the AUR, and my .Xresources file is this:

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, \
	       xft:Source Han Sans:style=Regular:antialias=true

URxvt.font           : normal
URxvt.boldFont       : normal
URxvt.italicFont     : normal
URxvt.bolditalicFont : normal

URxvt*background     : #223355
URxvt*foreground     : #FBFEFF

URxvt*color0         : #2F3969
URxvt*color1         : #556699
URxvt*color2         : #7788BB
URxvt*color3         : #99AACC
URxvt*color4         : #8BB3D9
URxvt*color5         : #A5867B
URxvt*color6         : #805F6B
URxvt*color7         : #F6F9FA

URxvt*color8         : #425094
URxvt*color9         : #7188cc
URxvt*color10        : #97aced
URxvt*color11        : #bfd4ff
URxvt*color12        : #b3daff
URxvt*color13        : #cc907a
URxvt*color14        : #b38495
URxvt*color15        : #fbfeff

bohoomil · 2015-07-12 06:30:32

Hi reportados, I guess I forgot to modify the naming convention for updated Han families in 90-foo-han.conf files. I'll fix it soon. If this doesn't work, then I can't see anything else on my side.

BTW, were I you, I'd install ttf-noto-sans-*-ib families, simplify your .Xresources (leave only the basic entry for DejaVu Sans Mono) and let fontconfig do the rest of the job. Noto families for non-Latin scripts, including CJK sets, render much better than Adobe's Han even at smaller sizes.

reportados · 2015-07-12 13:49:00

bohoomil wrote:

Hi reportados, I guess I forgot to modify the naming convention for updated Han families in 90-foo-han.conf files. I'll fix it soon. If this doesn't work, then I can't see anything else on my side.
BTW, were I you, I'd install ttf-noto-sans-*-ib families, simplify your .Xresources (leave only the basic entry for DejaVu Sans Mono) and let fontconfig do the rest of the job. Noto families for non-Latin scripts, including CJK sets, render much better than Adobe's Han even at smaller sizes.

Hey thanks for the recommendation, I tried the Noto CJK font and it looks really nice!

Jristz · 2015-07-12 23:43:46

There is a way to know when you add a new font to the repo?
I want keep all the font in the repo installed (one type for each one)

bohoomil · 2015-07-13 01:17:19

@Jristz, all commits to the ib repository are listed in the Changelog. If you want to be notified about updates, you can subscribe to the RSS channel. There's also a dedicated G+ page available. As far as font packages are concerned, check out the complete list with previews (for most families) and a brief description. ;-)

masque · 2015-07-14 08:33:18

masque wrote:

From today, when I try to do a pacman -Sy, I get errors about infinality-bundle signature.
pacman -Syy
error: infinality-bundle: signature from "bohoomil (dev key) <bohoomil@zoho.com>" is invalid
[...]

Problema solved. My repo was corrupted. I cleaned it by commenting the entry from pacman.conf, then pacman -Sc to remove unused repositories. Uncommented the entries; pacman -Sy... and it worked.

Earnestly · 2015-07-14 13:07:45

The use of -Sy (and -Syy) without -u is not supported on Arch Linux.

masque · 2015-07-14 13:18:42

Earnestly wrote:

The use of -Sy (and -Syy) without -u is not supported on Arch Linux.

Don't worry. I didn't want to do a partial upgrade, but just to syncronize my local repository.

Earnestly · 2015-07-14 20:36:29

If you use -Sy(y) and then -S without running -u, you will be doing a partial upgrade. In fact, that is the whole problem, updating the sync databases and not the local database.

There is almost never a valid reason to use -Sy or -Syy on Arch Linux (-yy is also never needed either) outside of initial installation.

Last edited by Earnestly (2015-07-14 20:37:26)

jasonwryan · 2015-07-22 07:19:24

bohoomil: this may not be related to the bundle, but I figured you might have some helpful insights: any idea why a small subset of the Indic glyphs would not be rendered in one browser (Vimb) while they are all fine in another (Chromium)?

Screenshot on the Vimb issue tracker: https://github.com/fanglingsu/vimb/issues/231

bohoomil · 2015-07-25 19:05:30

Hi Jason,

I'm afraid I really can't help you out much with this... Combined Indic glyphs are the only that don't render correctly in several Webkit2 browsers, including Midori and Epiphany. I was using dwb myself, which was affected as well, so I'm aware of the problem but I've never managed to find a working solution to it. The font they all use to render Indic scripts is selected correctly (in my case it's Noto Sans Devanagari) which makes me believe that it isn't a fontconfig related issue. It doesn't seem to be a problem with a particular font family, too, as long as the one you're using offers all the necessary glyphs for a particular language (be it Noto Sans, Lohit or Free Sans).

There are two possibilities I can think of, though: it's either the difference in Webkit flavour(s) used in mainstream browsers (Chrome and Opera engines may differently deal with non-Latin scripts) or something about the Infinality patchset (assuming that stock freetype2 and Webkit2 work correctly together). In either case, the solution would mean dropping one of the two: either vimb (or any browser using vanilla Webkit2 for that matter) or freetype2-infinality.

Sorry...

Arch Linux

#1676 2015-07-02 13:47:44

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

#1677 2015-07-02 18:26:05

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

#1678 2015-07-02 18:44:39

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

#1679 2015-07-02 19:04:30

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

#1680 2015-07-02 19:05:48

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

#1681 2015-07-02 19:48:18

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

#1682 2015-07-02 21:01:11

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

#1683 2015-07-02 21:20:24

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

#1684 2015-07-02 22:55:18

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

#1685 2015-07-03 00:37:15

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

#1686 2015-07-03 23:28:49

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

#1687 2015-07-08 07:05:46

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

#1688 2015-07-09 01:43:28

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

#1689 2015-07-09 03:49:53

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

#1690 2015-07-10 15:46:25

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

#1691 2015-07-12 06:30:32

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

#1692 2015-07-12 13:49:00

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

#1693 2015-07-12 23:43:46

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

#1694 2015-07-13 01:17:19

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

#1695 2015-07-14 08:33:18

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

#1696 2015-07-14 13:07:45

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

#1697 2015-07-14 13:18:42

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

#1698 2015-07-14 20:36:29

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

#1699 2015-07-22 07:19:24

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

#1700 2015-07-25 19:05:30

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

Board footer