You are not logged in.
I wasn't blaming symbola, just saying that it was the font that caused the symbols to change. Thanks, I didn't realize I had been using the old vim-powerline symbols for everything (or that they existed).
You say the second section is in the range of certain math symbols; do they appear as math symbols for you? At least for me, they're fine even with symbola, so I'm not going to worry about it for now. The first section isn't the same or the right size, so I'd rather use the standard powerline symbols.
Edit: It looks like there's overlap with some uushi symbols as well
Last edited by angelic_sedition (2014-10-23 22:50:58)
Offline
Yes, you're right: it's not math symbols, but Private Use Area:
By the way, the characters in the screenshot come from Linux Libertine O, although Droid Sans provides them, too. The difference is that in Droid Sans they are located in the Latin Extended-A Unicode range, while in Linux Libertine O(penType) they appear both in the Latin Extended-A and Private Use Area. Hence you find some symbols overlapping now because the new Powerline symbols' location is quite as unfortunate as the old one… (Of course, in your case the family providing the overlapping characters doesn't have to be Linux Libertine.)
The first section isn't the same or the right size, so I'd rather use the standard powerline symbols.
The first section is the only safe one. As far as the contents is concerned, if you can do without a nifty padlock and replace it with a different Unicode symbol, then stick with standards. It's safer to use a properly coded font which won't interfere with other families than a super-duper unique one which out of the sudden will replace a common character you need with a sexy pictograph. You will be better off with a customized vim config file than a non-standard font family that will dominate the others. You know, standards make sense although/because they are boring and predictable.
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
Does somebody have bad looking fonts on github.com?
I'm having it since last update I think.
Offline
Does somebody have bad looking fonts on github.com?
I'm having it since last update I think.
They look OK to me.
Have you tried https://wiki.archlinux.org/index.php/Fo … tmap_fonts ?
Offline
@duud Could you please share a link to a screenshot? It's hard to tell which fonts are involved (there are quite a few different used on GitHub).
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
Here the github screenshot
I mean especially the font on the buttons. They look on the jpeg (due to compression) somewhat better then on my screen.
If I zoom in or out in firefox the fonts start to look better.
Offline
Thanks. There are a few things: first of all, check if the libraries (freetype2-iu and fontconfig-iu; cairo-iu should be v.1.14.0-1) were installed properly. For freetype, issue the commands below and compare the output:
$ grep Xft <(xrdb -q)
Xft.antialias: 1
Xft.autohint: 0
Xft.dpi: 96
Xft.hinting: 1
Xft.hintstyle: hintfull
Xft.lcdfilter: lcddefault
Xft.rgba: rgb
$ grep INFINALITY <(env)
INFINALITY_FT_FRINGE_FILTER_STRENGTH=50
INFINALITY_FT_USE_VARIOUS_TWEAKS=true
INFINALITY_FT_FILTER_PARAMS=06 22 36 22 06
INFINALITY_FT_CHROMEOS_STYLE_SHARPENING_STRENGTH=20
If yours is exactly the same --- you can procede. If not, reinstall freetype2-iu (v.2.5.3-13) and make sure that infinality-settings.sh in /etc/profile.d is executable and gets sourced when you log in to your X environment.
With fontconfig-iu it's best to backup your current configuration
# pwd
/etc
# mv fonts{,.bkp}
--- and re-install the library, in case your current settings are in any way non-functional. Do the same with your local fontconfig configuration:
$ cd ~/.config
$ mv fontconfig{,.bkp}
Next, you should use at least the very minimal font collection (in the ib repo it's `ibfonts-meta-base`, but you'd really benefit if you got a more complete one, 'ibfonts-meta-extended'). The fonts you need are outline, not bitmap fonts (one that dominates in your screenshot isn't suitable for rendering website content). Install them with
pacman -S ibfonts-meta-extended
Finally, the missing GitHub pictographs. The most likely reason for this to happen is messy Firefox cache. GitHub uses its own font family, Octicons, to display graphical symbols, which is dynamically loaded when you refresh the page. If you can't see it, it probably isn't accessible for the browser or can't be read from the cache.
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
Many thanks bohoomil.
Fonts are looking really good now. Here is what I did:
I had ibfonts-meta-base/ibfonts-meta-extended not installed so I installed ibfonts-meta-base. This fixed the github.com problem.
Then I thought it's a good idea to recreate /etc/fonts (I have no ~/.config/fontconfig ) so I renamed the folder and reinstalled fontconfig-iu, ibfonts-meta-base with all dependencies. After that the github problem appeared again. So I deleted /etc/fonts, removed all ib packages (installed the required dependencies: arch's freetype2 etc.) and installed infinality-bundle, ibfonts-meta-extended. Everything is looking great now.
One more thing. I don't use a loginmanager, this is currently required if you want a rootless X. In this case /etc/profile.d/infinality-settings.sh gets sourced without a running X-server so the xrdb-merge call has no effect. Currently I have to execute infinality-settings.sh in my xinitrc. Maybe there is a way for ib to set things up after the start of an X-server.
Offline
Well, I re-execute the entire /etc/profile.d via .xinitrc:
if [ -d /etc/profile.d/ ]; then
for profile in /etc/profile.d/*.sh; do
[ -r "$profile" ] && . "$profile"
done
unset profile
fi
This is IMO a safe approach if you don't use a login manager (I don't use any either).
We can also consider moving the file to /etc/X11/xinit/xinitrc.d (after all, this is where mandatory X-specific bits should belong). However, before we do this, I'd like to make sure there are no potential side effects of such a transition. As always, feedback is most welcome.
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
Well, I re-execute the entire /etc/profile.d via .xinitrc:
if [ -d /etc/profile.d/ ]; then for profile in /etc/profile.d/*.sh; do [ -r "$profile" ] && . "$profile" done unset profile fi
This is IMO a safe approach if you don't use a login manager (I don't use any either).
We can also consider moving the file to /etc/X11/xinit/xinitrc.d (after all, this is where mandatory X-specific bits should belong). However, before we do this, I'd like to make sure there are no potential side effects of such a transition. As always, feedback is most welcome.
You are executing the scripts twice. You can't assume that executing the scripts in profile.d twice is safe. I think xinitrc.d is a more natural place for X-specific settings.
Offline
If I do
pacman -S infinality-bundle
cairo-infinality-ultimate gets not installed. Is this behavior correct?
Offline
You can't assume that executing the scripts in profile.d twice is safe.
Thank you for the tip: I didn't think about it in this way.
Is this behavior correct?
No. For some reason cairo's PKGBUILD has been missing 'groups' array. Thanks for reporting.
I'm going to test the new location of infinality-settings for a while. If nothing unexpected happens, I'll upload updated freetype2-iu and cairo-iu to the repository.
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
@bohoomil
The latest update moved /etc/profile.d/infinality-settings.sh to /etc/profile.d/infinality-settings.sh.pacsave without creating a new /etc/profile.d/infinality-settings.sh.
Is this intended? If yes, where are custom settings now to be defined?
Packages (5): cairo-infinality-ultimate-1.14.0-2
fontconfig-infinality-ultimate-2.11.1-22
freetype2-infinality-ultimate-2.5.3-14
lib32-cairo-infinality-ultimate-1.14.0-2
lib32-freetype2-infinality-ultimate-2.5.3-14
Offline
@bohoomil
The latest update moved /etc/profile.d/infinality-settings.sh to /etc/profile.d/infinality-settings.sh.pacsave without creating a new /etc/profile.d/infinality-settings.sh.
Is this intended? If yes, where are custom settings now to be defined?
It's under /etc/X11/xinit/xinitrc.d/ now, I still have to add the script to kde startup though. Otherwise it doesn't work.
Offline
@Kaan That's odd. If you have the stock .xinitrc and .xsession in your home directory, then KDM should source files stored in /etc/X11/xinit/xinitrc.d on KDE startup. If you don't have any, copy it from /etc/skel. See xprofile for details.
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
I just put those files like you asked, but neither kdm or sddm sourced those files for some reason, weird.
Offline
@Kaan In my case I have to change infinality-settings in infinality-settings.sh into /etc/X11/xinit/xinitrc.d. What's your case?
Offline
Two issues I wanted to ask about.
1) The first is that fc-presets doesn't seem to be "saving" my actions. E.g., I show as having no preset selected even right after reseting and then selecting one:
$ sudo fc-presets set
1) combi
2) free
3) ms
4) reset
5) quit
Enter your choice... 4
Removing current preset...
Done. Now select a new preset...
Enter your choice... 2
[ free ] preset chosen...
Done.
$ sudo fc-presets check
[ combi ] is not set
:: Run <fc-presets help> for more information.
[ free ] is not set
:: Run <fc-presets help> for more information.
[ ms ] is not set
:: Run <fc-presets help> for more information.
I know I'm not the first to have this problem, but unlike the others, uninstalling and reinstalling fontconfig-infinality-ultimate does not help.
Now, I'm not aware of any resulting misbehavior in terms of what actual font selections are made, but nonetheless, I thought it worth mentioning.
2)
At certain font sizes (not all), the lowercase g on Gelasio looks simply awful. Here's a sample.
I'm probably being picky, as it is just one letter in one font, and I don't know for sure whether it's an infinality thing, or a Gelasio thing, but I thought I'd mention it.
Offline
@frabjous So here we go.
Ad 1) Could you please check the output of 'ls -lh' for any broken links and share the listing (via pastebin or a similar service: the output is going to be a bit long and messy)?
Ad 2) Install the updated ttf-gelasio-ib: it's now rendering correctly.
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
Is there a way to use infctl with this Infinality Bundle?
Offline
@pezzonovante No. The concept behind infctl and the 'old' Infinality is completely different.
BTW, I'm currently re-working fc-presets and fontconfig installer to make them 1) distro agnostic and 2) simpler and more robust. With this done, building fontconfig-iu for distros other than Arch should involve as little as applying a patchset and running the compiler.
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
@bohoomil: Yeah I thought that would be the case. It's a shame though, because on my system `infctl setstyle infinality` has always given me the best looking fonts.
Offline
@pezzonovante With a bit of work on your side, it can be recreated. What you need to do (mandatory): use the old infinality-settings.sh in place of mine and set 'infinality' style manually in it. What you may need to do (you should check first if it's really necessary, though): modify a bunch of config files and use them as the 'combi' style (ib is using mostly light hinting where the 'old' Infinality was using full, etc.). That's it. Just note that freetype2 has changed, so fonts will look different than a year or more ago, even with Infinality patchset.
:: Registered Linux User No. 223384
:: github
:: infinality-bundle+fonts: good looking fonts made easy
Offline
@bohoomil: Thank you. I will need to study more about these things before attempting those steps. But I will try it in future.
Offline
@bohoomil: The Gelasio problem seems to be solved with the new update. Thanks! You are the man.
As for the other problem, here is the output of ls -lh for /etc/fonts/conf.d (I assume that's where you meant; if you need anything else, let me know!):
Last edited by frabjous (2014-11-04 18:18:21)
Offline