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

WonderWoofy · 2013-05-16 06:12:40

Regarding your above post, it would seem that your package enables the 38-repl-tt-traced-bitmap.conf by default. Was this not intentional?

In any case, I turned bitmap fonts back on by doing what you described in that post. Things continue to look badass!

orschiro · 2013-05-16 06:57:16

bohoomil wrote:

Terminus TTF will look OK only at following sizes: 9px, 12px, 15px, 18px and 24px. These should work even without altering the default settings (they do in my case). However, you may want to take a look at this, especially the second box. Enabling 32-tt-traced-bitmap-rendering.conf and 38-repl-tt-traced-bitmap.conf may be a good idea.

Thanks.

The result now is acceptable: http://i.imgur.com/DIlwdGj.png

silenc3r · 2013-05-16 07:40:48

bohoomil wrote:

In the easiest possible way:
# mv /etc/fonts/conf.d{,.bkp}

Ok, after doing that fonts look like complete crap, they're almost unreadable. And my default system font changed to UnifrakturMaguntia (WTF?!)

karol · 2013-05-16 11:25:13

silenc3r wrote:

my default system font changed to UnifrakturMaguntia (WTF?!)

LOOOOOOL!

I think that's a sensible default - Arch is an elite Linux distribution and such settings would ensure that its userbase doesn't grow too large too quick.

bohoomil · 2013-05-16 12:30:27

silenc3r wrote:

fonts look like complete crap

That's great news: It means that fontconfig is working correctly.

(Speaking seriously: If duplicating the settings in your local fonts.conf works, keep doing so. However, don't change particular parameters there, like hintfull => hintslight: in fontconfig-infinality, this is done via selected rendering & font grouping, while global settings shouldn't be touched if you want to avoid problems with certain font families, characters, etc.)

bohoomil · 2013-05-16 12:41:24

WonderWoofy wrote:

Regarding your above post, it would seem that your package enables the 38-repl-tt-traced-bitmap.conf by default. Was this not intentional?

It was, indeed. Enabling 70-yes-bitmaps.conf adds full support for bitmap fonts. (Just wondering: Should I turn 70-yes-*.conf on by default?… It's not a problem, really, especially if it doesn't cause any side effects.)

silenc3r · 2013-05-16 12:50:40

bohoomil wrote:

(Speaking seriously: If duplicating the settings in your local fonts.conf works, keep doing so. However, don't change particular parameters there, like hintfull => hintslight: in fontconfig-infinality, this is done via selected rendering & font grouping, while global settings shouldn't be touched if you want to avoid problems with certain font families, characters, etc.)

I've tried stripping down my fonts.conf, here's minimal working file:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <match target="font">
        <edit mode="assign" name="rgba">
            <const>rgb</const>
        </edit>
    </match>
</fontconfig>

bohoomil · 2013-05-16 13:12:26

I know I'm going to sound like an ass, but is there really no forgotten / obsolete [dot] file that would stand between fontconfig and the screen?… If you have to do something similar with Ubuntu fontconfig as well, it seems to clearly indicate that the problem doesn't lie in one particular fontconfig package or another. Fontconfig does operate for sure ('crap' test be the proof) and installing it should be all you have to do (and most often is).

Yet another bit that makes me believe I may be right: I have intentionally changed the 'assign' mode to 'append' in 10-base-rendering.conf. This should let avoid issues in DEs (where you can usually set font settings independently of fontconfig), whilst in case you don't use any, the default settings should be applied. As you can see, the defaults are obviously being overridden…

silenc3r · 2013-05-16 14:18:46

bohoomil wrote:

I know I'm going to sound like an ass, but is there really no forgotten / obsolete [dot] file that would stand between fontconfig and the screen?… If you have to do something similar with Ubuntu fontconfig as well, it seems to clearly indicate that the problem doesn't lie in one particular fontconfig package or another. Fontconfig does operate for sure ('crap' test be the proof) and installing it should be all you have to do (and most often is).

here's list of dotfiles in $HOME:

$ ls -d1 .??*
.adobe
.bash_history
.bash_logout
.bash_profile
.bashrc
.bzr.log
.cache
.config
.dbus
.dotfiles
.elinks
.fonts
.gem
.gnupg
.gstreamer-0.10
.lesshst
.local
.macromedia
.mozilla
.mplayer
.nvpy
.nvpy.cfg
.octave_hist
.pki
.purple
.SpiderOak
.ssh
.subversion
.sxiv
.thumbnails
.vim
.vim-config
.viminfo
.vimrc
.Xauthority
.xinitrc
.xmonad
.xsel.log

WonderWoofy · 2013-05-16 15:02:29

bohoomil wrote:

WonderWoofy wrote:
Regarding your above post, it would seem that your package enables the 38-repl-tt-traced-bitmap.conf by default. Was this not intentional?
It was, indeed. Enabling 70-yes-bitmaps.conf adds full support for bitmap fonts. (Just wondering: Should I turn 70-yes-*.conf on by default?… It's not a problem, really, especially if it doesn't cause any side effects.)

Well, I personally would like this. I apparently do have quite a few bitmap fonts, a couple of which I use in my WM's UI. But it is also not a problem to simply make those quick changes and enable them with a whole two symlinks.

What does concerne me though is that the /etc/fonts/conf.d directory does not seem to be within pacman's "Backup files". So on update, I assume I will actually have 70-{no,yes}-bitmaps.conf in there. In this case it would seem okay, since I imagine they are read lexicographically, so the "yes" would likely undo the "no" file. But what about those that actually make some serious changes to their configurations?

I know that this is the case for the standard fontconfig package as well. I have always wondered in the past, but until I have started using your stuff and having you help me get my shit right, I have never really strayed from the defaults before, so I never really needed to worry about it (I just lived with crappy fonts).

vik_k · 2013-05-16 16:21:50

connection to your repo is timing out

WonderWoofy · 2013-05-16 16:34:16

Worked fine here just now...

vik_k · 2013-05-16 17:01:02

ok, my bad was using old url. thanks.

bohoomil · 2013-05-16 17:48:16

WonderWoofy wrote:

what about those that actually make some serious changes to their configurations?

That's a good question, really. There are a couple of things we have to think about to clarify the matter:

1. The range of possible serious changes when using the bundle.

It is technically possible to change every aspect of the bundle's configuration just like you can do with any other application. However, this should not be necessary and needed once you have decided to use the bundle in favour of the regular fontconfig-infinality and the way it is 'nested' within the stock fontconfig tree. (Remember the /etc/fonts/conf.d/52-infinality.conf file?)

When you install freetype2-infinality and fontconfig-infinality from the AUR, you get a collection of presets that you have to arrange in a way you want. Either you want Windows style rendering, or Apple's, or Linux's, to name just a few aspects to start with. Something is too intense or not intense enough? You go and tweak it yourself. In the background, there are still stock fontconfig's configuration files in /etc/fonts/conf.d linked to /etc/fonts/conf.avail making the whole thing even more complicated and confusing. And yes, the third guy and its family lives in $HOME/.config/fontconfig that further overrides what has already been set.

The idea of the bundle is to strip this down as much as possible, offering a set of basic sane defaults that in majority of cases shouldn't be touched, plus a place to customize the defaults on a per-user basis (a.k.a files available in $HOME/.config/fontconfig; this is actually something that the regular fontconfig already does, but most users still force custom settings into the global /etc/fonts, turning it into hotbed of entropy). This way you start with a single working preset (as offered by the bundle) with three visual variants to choose from (as found in infinality-settings.conf) and plenty of free time to spend any way you want.

That is why, the answer to the question could be:

If you are going to use the bundle, you do so because you like the way it does the job. If you need to alter the defaults, you do so on your private ground using files located in $HOME. If this is still not enough and for some reason you have to change the defaults in /etc/fonts/conf.d, you do so by a) duplicating necessary files in /etc/fonts/conf.avail.infinality, b) renaming them (e.g. 65-non-latin.conf → 65a-non-latin.conf), c) modifying the copies, and d) recreating the corresponding symbolic link(s) in /etc/conf.d/ to point the new target(s):

# cd /etc/fonts/conf.d
# ln -s -f ../conf.avail.infinality/65a-non-latin.conf 65-non-latin.conf

This way all the necessary custom changes can be introduced while the core bundle structure is left intact (just like it should be).

And a disclaimer: I am not able to support heavily customized /etc/fonts/conf.d when, for example, the base rendering model is not the same as the one I created. Of course, not everyone is going to like and accept it, but that's actually the unique aspect of the bundle and my understanding of 'sane defaults' you wanted to use, didn't you? Once you leave it behind, you are back to a differently named fontconfig-infinality, which means: you are on your own. It has nothing to do with my self-esteem and the feeling of superiory, but is strictly practical, for the same reason we are reluctant to support Arch Linux spin-offs because we consider them to be new entities built upon a different comprehension of 'sane defaults'.

2. Updates, upgrades and symlinks.

The aim of creating a custom, infinality oriented fontconfig library, instead of using any sort of plugin-style configuration (like the one still offered by fontconfig-infinality-ultimate-git, which is soon going to end its life in its present form) was a natural consequence of the 'sane defaults' principle. If you are going to make something work out of the box, your intention is to eliminate possible obstacles which could get in the way of the robust operation of your application, right? In this case, the gain and loss balance of my approach seemed positive because a) the user gets a fully operational fontconfig, compatible with the rest of applications he/she may want to use, b) the defaults can be easily restored once user's intention to modify /etc/fonts appears to be non-operational, c) what should be disabled by default will not be accidentally activated, leaving the user with a mess on the screen and growing despair in his/her head. You may think of this as a more Ubuntu like than Arch approach, but when you dive into our Forums' archives and count all the posts on the oder of '!!!HELP ME WITH FONTS OR I WILL EAT MY GRANDMA ALIVE!!!' you start to ask yourself if there is a way to save grandmas.

With a huge help of pacman, you can even satisfy those who not only want to use the bundle, but also customize it for even more fun (or whatever reason). The only thing a user should remember is the correct way of introducing changes: a) on a per-user level (the recommended approach), or b) using renamed copies of relevant files in /etc/fonts/conf.avail.infinality (not nice, but acceptable). That's why even if you go the b) way and the upgrade reverts symlinks back to their original state, all you have to do is relink them.

In a single case of DejaVu family, which comes with 5 additional configuration files activated by default during installation, I decided to make use of the *.install file. During fontconfig-ultimate installation or upgrade, the links are removed from /etc/fonts/conf.d (if they are present), but when you remove fontconfig-ultimate, they are restored. Default fontconfig configuration will be restored anyway when you reinstall the stock package, so you should end up with a clean setup as designed by Arch developers.

Having written that, I hope that the bundle terror seems less scary now.

WonderWoofy · 2013-05-16 18:49:38

That was a great explanation there, thanks bohoomil.

I wasn't trying to say that I was going to modify the hell out of your package. But just that in the past, while using the original fontconfig packages and the regular infinality packages, how was maintaining configuration supposed to work during upgrades. As I ahve moved to your configurations, I have pretty much put all my fontconfig configuration and total trust that you know better than I into your hands. Even so, I wanted to re-enable bitmap fonts, ad your recommendation was to link in /etc/fonts/conf.d. So things will still get a bit jumbled during an update, since this directory is not tracked.

So you are saying that we should make changes in $HOME/.config/fontconfig. Is is acceptable to simply make links against /etc/fonts/conf.avail.infinality then? For example, I want to re-enable bitmap fonts, so would I "ln -s /etc/fonts/conf.avail.infinality/70-yes-bitmaps.conf $HOME/.config/fontconfig"? I assume from the numbering in the configurations that these are supposed to be parsed lexicographically, so are the settings in $HOME parsed as a part of a total of all configurations options, or is the user's home folder always done after the settings in /etc (and would it matter if so)?

That brings me to the issue of disabling 70-no-bitmaps.conf. If this is to be done in $HOME as well, does it work like systemd's /usr/lib vs /etc? If I were to create a $HOME/.config/fontconfig/70-no-bitmaps.conf linked to /dev/null (or blank), would that override what is in /etc/fonts/conf.d?

I honestly really would like to stick to the defaults if possible, but I came to the realization when you disabled them that I do actually use bitmap fonts in a few places. So in the spirit or Arch Linux, I would really like to do this the "correct" way, but unfortunately my knowledge of the fontconfig directory heirarchy is limited to whatever you have told me in the past.

bohoomil · 2013-05-16 19:28:34

I think it is really fine that we can clarify a few things right now.

WonderWoofy wrote:

Is it acceptable to simply make links against /etc/fonts/conf.avail.infinality then?

There is even a better solution (and IMO the correct one): just copy the content of /etc/fonts/conf.avail.infinality to $HOME/.config/fontconfig/conf.avail and create symlinks to available templates from $HOME/.config/fontconfig/conf.d:

$ cd ~/.config/fontconfig/conf.d
$ ln -s ../conf.avail/70-yes-bitmaps.conf .

This way you should be able to activate bitmap fonts for your account. (See /usr/share/doc/fontconfig-infinality-ultimate for examples and the way your local ~/.config/fontconfig directory should look.) What's more, this should also work for even deeper customizations, if they are really necessary for some reason. I believe this answers the next question:

WonderWoofy wrote:

That brings me to the issue of disabling 70-no-bitmaps.conf. If this is to be done in $HOME as well, does it work like systemd's /usr/lib vs /etc?

Assuming the above is working correctly (it should -- check it, please, on your own), no file has to be relinked / removed / modified in the global location and whatever the upgrade brings, your custom settings are safe and working because they will always override global ones. Further on, this should limit the number of cases when heavy modifications in /etc/fonts are the only way to go.

You may want to experiment a bit with various customizations using the above model. The more ridiculous, the better. Once you can't read a single letter, just remove the symlinks in ~/.config/fontconfig/conf.d and start from scratch.

WonderWoofy · 2013-05-16 20:04:28

Excellent... more great info. I have created the user config directories, then made it mirror what I had in /etc. Then I reverted the stuff in /etc back to the defaults (re-enabled 70-no-bitmaps.conf and moved the symlink to 32-tt-traced-bitmap-rendering.conf).

All seems well, as bitmaps are in use, and things seem normal. Thanks again bohoomil.

Oh yeah, and things seem to be working just fine, but should I also put a copy of fonts.conf in my $HOME as well? Or is it okay to only have the one in /etc?

bohoomil · 2013-05-16 20:22:15

WonderWoofy wrote:

should I also put a copy of fonts.conf in my $HOME as well? Or is it okay to only have the one in /etc?

No. The global one does exactly what it should, while everything else is our playground.

WonderWoofy · 2013-05-16 20:25:24

Excellent, then I have it all in order now. Thanks bohoomil.

wilfriedd · 2013-05-17 11:11:06

@silenc3r,bohoomil

Unfortunately I have the same problem with blurriness after the switch to the new config. The assignment of the rgba value in my fonts.conf as suggested by silenc3r fixed it for me.

I've been looking into the problem and another solution is changing the appends in 10-base-rendering.conf to assign.
So I guess my DE is overriding some of these default rendering settings (more specific the rgba parameter)? I'm using gnome shell.

jakobcreutzfeldt · 2013-05-17 11:29:02

Overall I'm really liking the bundle. Configuring fonts has been an exercise in frustration for me so it's nice to have a sane default to work from. I will note that, needless to say, everything looks way better on my home computer which has a dpi of 122 compared to my work computer which has a dpi of 92.

Most things (terminal, browser, emacs etc) look great. The work computer's crappy display quality has caused me to notice a couple of problems though. First of all, embedded fonts in PDFs look awful, regardless of which reader I'm using (I've tried Evince, mupdf and the built-in reader in Mendeley). They seem to be completely unaliased (angled edges of characters like A and V are very jagged) but they're sort of blurry. Overall it's really tough to read PDFs as a result.

[comparison of a PDF and the corresponding text in a web page]
[comparison of a PDF and the LibreOffice Writer document from which it was generated]

I'm also having problems with the fonts on some web pages. Check out this screen grab of Github for example. See how in the lower-case 's', the middle horizontal line is squashed out of existence.

edit: removed the part about some ugly serif font; turns out I had a Courier font from xorg-fonts-type1 that was being detected. I hated it so I removed that package. Now all is well in that department.

$ ls /etc/fonts/conf.d                                                                                          
10-base-rendering.conf      38-repl-tt-traced-bitmap.conf  73-ttf-as-bitmap.conf
15-tt-monospace-fonts.conf  39-repl-corrective.conf        74-force-autohint.conf
20-aliases-default.conf     40-nonlatin.conf               75-qt-subpixel-positioning.conf
20-fix-cantarell.conf       45-latin.conf                  76-forced-synthetic.conf
21-cantarell-hinting.conf   49-sansserif.conf              80-selective-rendering.conf
21-non-tt-rendering.conf    50-user.conf                   81-final-rendering.conf
21-tt-rendering.conf        51-local.conf                  82-final-lang-spec.conf
30-non-tt-fonts.conf        60-latin.conf                  90-no-synthetic.conf
30-tt-fonts.conf            65-non-latin.conf              95-reject.conf
31-cantarell.conf           66-override.conf               99pdftoopvp.conf
35-droid-sans-group.conf    67-aliases-wine.conf           README
35-droid-serif-group.conf   70-no-bitmaps.conf
37-repl-global.conf         72-embedded-bitmaps.conf

$ cat /etc/fonts/conf.d/20-aliases-default.conf                                                                 
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
  <!-- bohoomil -->
  <!-- In order to use your favourite sans-serif, serif and monospace
       fonts instead of generic ones:
       1. duplicate this file and save under a new name, e.g.
          20-aliases-default-droid.conf
       2. set your prefered fonts
       3. re-link the file (as root):
          $ cd /etc/fonts/conf.d
          $ sudo ln -f -s ../conf.avail.infinality/20-aliases-default-droid.
            conf ./20-aliases-default.conf -->
  <!-- ***************** ALIASES # USER-DEFINED ********************  -->
  <alias>
    <family>sans-serif</family>
    <prefer>
      <family>DejaVu Sans</family>
    </prefer>
  </alias>
  <alias>
    <family>serif</family>
    <prefer>
      <family>DejaVu Serif</family>
    </prefer>
  </alias>
  <alias>
    <family>monospace</family>
    <prefer>
      <family>DejaVu Sans Mono</family>
    </prefer>
  </alias>
</fontconfig>

I do not have anything in ~/.config/fontconfig (the directory does not exist).

$ cat /etc/profile.d/infinality-settings.sh                                                                     
### infinality environment variables for extra run-time options ###
### custom settings by bohoomil ###
### http://bohoomil.github.io/ib.html ###
SET_XFT_SETTINGS=true
XFT_SETTINGS="
Xft.antialias:  1
Xft.autohint:   0
Xft.dpi:        96
Xft.hinting:    1
Xft.hintstyle:  hintfull
Xft.lcdfilter:  lcddefault
Xft.rgba:       rgb
" 
if [ "$SET_XFT_SETTINGS" = "true" ]; then
  echo "$XFT_SETTINGS" | xrdb -merge > /dev/null 2>&1
fi
#export INFINALITY_FT_FILTER_PARAMS="11 22 38 22 11" # brighter & sharper
export INFINALITY_FT_FILTER_PARAMS="13 25 38 25 13" # darker & smoother
#export INFINALITY_FT_FILTER_PARAMS="13 25 36 25 13" # well balanced
export INFINALITY_FT_GRAYSCALE_FILTER_STRENGTH="0"
export INFINALITY_FT_FRINGE_FILTER_STRENGTH="0"
export INFINALITY_FT_AUTOHINT_HORIZONTAL_STEM_DARKEN_STRENGTH="10"
export INFINALITY_FT_AUTOHINT_VERTICAL_STEM_DARKEN_STRENGTH="25"
export INFINALITY_FT_WINDOWS_STYLE_SHARPENING_STRENGTH="5"
export INFINALITY_FT_CHROMEOS_STYLE_SHARPENING_STRENGTH="30"
export INFINALITY_FT_STEM_ALIGNMENT_STRENGTH="25"
export INFINALITY_FT_STEM_FITTING_STRENGTH="25"
export INFINALITY_FT_GAMMA_CORRECTION="0 100"
export INFINALITY_FT_BRIGHTNESS="20"
export INFINALITY_FT_CONTRAST="40"
export INFINALITY_FT_USE_VARIOUS_TWEAKS="true"
export INFINALITY_FT_AUTOHINT_INCREASE_GLYPH_HEIGHTS="true"
export INFINALITY_FT_AUTOHINT_SNAP_STEM_HEIGHT="50"
export INFINALITY_FT_STEM_SNAPPING_SLIDING_SCALE="30"
export INFINALITY_FT_USE_KNOWN_SETTINGS_ON_SELECTED_FONTS="true"
#export INFINALITY_FT_GLOBAL_EMBOLDEN_X_VALUE=0
#export INFINALITY_FT_GLOBAL_EMBOLDEN_Y_VALUE=0
#export INFINALITY_FT_BOLD_EMBOLDEN_X_VALUE=0
#export INFINALITY_FT_BOLD_EMBOLDEN_Y_VALUE=0

$ xrdb -q | grep Xft 
$

$ env | grep INFINALITY
INFINALITY_FT_AUTOHINT_HORIZONTAL_STEM_DARKEN_STRENGTH=10                                                       
INFINALITY_FT_AUTOHINT_VERTICAL_STEM_DARKEN_STRENGTH=25                                                         
INFINALITY_FT_CONTRAST=40                                                                                       
INFINALITY_FT_GRAYSCALE_FILTER_STRENGTH=0                                                                       
INFINALITY_FT_FRINGE_FILTER_STRENGTH=0                                                                          
INFINALITY_FT_BRIGHTNESS=20                                                                                     
INFINALITY_FT_USE_VARIOUS_TWEAKS=true                                                                           
INFINALITY_FT_GAMMA_CORRECTION=0 100                                                                            
INFINALITY_FT_FILTER_PARAMS=13 25 38 25 13                                                                      
INFINALITY_FT_STEM_SNAPPING_SLIDING_SCALE=30                                                                    
INFINALITY_FT_USE_KNOWN_SETTINGS_ON_SELECTED_FONTS=true                                                         
INFINALITY_FT_WINDOWS_STYLE_SHARPENING_STRENGTH=5                                                               
INFINALITY_FT_CHROMEOS_STYLE_SHARPENING_STRENGTH=30                                                             
INFINALITY_FT_STEM_ALIGNMENT_STRENGTH=25                                                                        
INFINALITY_FT_AUTOHINT_SNAP_STEM_HEIGHT=50                                                                      
INFINALITY_FT_STEM_FITTING_STRENGTH=25                                                                          
INFINALITY_FT_AUTOHINT_INCREASE_GLYPH_HEIGHTS=true

I've tried all three of the new INFINALITY_FT_FILTER_PARAMS presets and I've also tried setting Xft.dpi to 92, but none of them have helped.

Any ideas?

Thanks again for your work on the bundle!!

Last edited by jakobcreutzfeldt (2013-05-17 12:44:52)

brebs · 2013-05-17 12:04:21

jakobcreutzfeldt wrote:

See how in the lower-case 's', the middle horizontal line is squashed out of existence.

Common issue. First you need to find out which font it is, so it can be tweaked by name.

$ FC_DEBUG=1 firefox https://github.com/brandoninvergo/pacnanny | grep "font-face" &
family: "@font-face:github-octicons"

But that's a red herring, that web font is just for icons

So it's a process of elimination, with just that web page loaded in a fresh instance of firefox, and the output of:

lsof | grep firefox | grep -i fonts

Turn a filename into a font name, with e.g.:

$ fc-query /usr/share/fonts/liberation-fonts-ttf/LiberationSans-Italic.ttf | egrep "(family|foundry)"
	family: "Liberation Sans"(s)
	familylang: "en"(s)
	foundry: "unknown"(s)

To confirm which font it is, I like to add a fontconfig rule for it, to make it stand out by being ugly:

<edit mode="assign" name="antialias"><bool>false</bool></edit>

Then restart firefox, to make the fontconfig change take effect. (A page reload used to be sufficient, but no longer works.)

jakobcreutzfeldt · 2013-05-17 12:38:21

Thanks for the tips!

Based on the output of lsof, that font is almost certainly DejaVu Sans ExtraLight. Its family is both DejaVu Sans and DejaVu Sans Light. While any rules for DejaVu Sans should apply to it (I think), I tried making a special rule for DejaVu Sans Light anyway, but it didn't have any noticable effect. Since I generally want DejaVu Sans to be antialiased, I tried doing something similar to the 20-unhint-small-dejavu-sans.conf except for turning off antialiasing at small sizes. That didn't seem to have any effect either, which is fine because normal DejaVu Sans looks fine antialiased at that size. It might just be how the extra light looks...

Anyway, that problem is minor so I'm just going to live with it for now. If worst comes to worst, I can just change my default font, which looks like it solves that particular problem.

Last edited by jakobcreutzfeldt (2013-05-17 12:46:09)

bohoomil · 2013-05-17 13:43:46

jakobcreutzfeldt wrote:

$ ls /etc/fonts/conf.d                                                                                          
10-base-rendering.conf      38-repl-tt-traced-bitmap.conf  73-ttf-as-bitmap.conf
15-tt-monospace-fonts.conf  39-repl-corrective.conf        74-force-autohint.conf
20-aliases-default.conf     40-nonlatin.conf               75-qt-subpixel-positioning.conf
20-fix-cantarell.conf       45-latin.conf                  76-forced-synthetic.conf
21-cantarell-hinting.conf   49-sansserif.conf              80-selective-rendering.conf
21-non-tt-rendering.conf    50-user.conf                   81-final-rendering.conf
21-tt-rendering.conf        51-local.conf                  82-final-lang-spec.conf
30-non-tt-fonts.conf        60-latin.conf                  90-no-synthetic.conf
30-tt-fonts.conf            65-non-latin.conf              95-reject.conf
31-cantarell.conf           66-override.conf               99pdftoopvp.conf
35-droid-sans-group.conf    67-aliases-wine.conf           README
35-droid-serif-group.conf   70-no-bitmaps.conf
37-repl-global.conf         72-embedded-bitmaps.conf

$ cat /etc/fonts/conf.d/20-aliases-default.conf                                                                 
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
  <!-- bohoomil -->
  <!-- In order to use your favourite sans-serif, serif and monospace
       fonts instead of generic ones:
       1. duplicate this file and save under a new name, e.g.
          20-aliases-default-droid.conf
       2. set your prefered fonts
       3. re-link the file (as root):
          $ cd /etc/fonts/conf.d
          $ sudo ln -f -s ../conf.avail.infinality/20-aliases-default-droid.
            conf ./20-aliases-default.conf -->
  <!-- ***************** ALIASES # USER-DEFINED ********************  -->
  <alias>
    <family>sans-serif</family>
    <prefer>
      <family>DejaVu Sans</family>
    </prefer>
  </alias>
  <alias>
    <family>serif</family>
    <prefer>
      <family>DejaVu Serif</family>
    </prefer>
  </alias>
  <alias>
    <family>monospace</family>
    <prefer>
      <family>DejaVu Sans Mono</family>
    </prefer>
  </alias>
</fontconfig>

Any ideas?

Yes: you have a nice mess in your config files. This is what you should have in /etc/fonts/conf.d by default:

10-base-rendering.conf@         60-latin.conf@
15-tt-monospace-fonts.conf@     65-non-latin.conf@
20-fix-cantarell.conf@          66-override.conf@
21-non-tt-rendering.conf@       67-aliases-wine.conf@
21-tt-rendering.conf@           70-no-bitmaps.conf@
30-non-tt-fonts.conf@           72-embedded-bitmaps.conf@
30-tt-fonts.conf@               73-ttf-as-bitmap.conf@
35-droid-sans-group.conf@       74-force-autohint.conf@
35-droid-serif-group.conf@      75-qt-subpixel-positioning.conf@
37-repl-global.conf@            76-forced-synthetic.conf@
38-repl-tt-traced-bitmap.conf@  80-selective-rendering.conf@
39-repl-corrective.conf@        81-final-rendering.conf@
40-nonlatin.conf@               82-final-lang-spec.conf@
45-latin.conf@                  90-no-synthetic.conf@
49-sansserif.conf@              95-reject.conf@
50-user.conf@                  README 
51-local.conf@

For instance, 20-aliases-default.conf is not used anymore, 21-cantarell-hinting.conf and 31-cantarell.conf are not a part of the bundle, etc… Fix this first and then check the rendering again.

jakobcreutzfeldt · 2013-05-17 14:12:26

Done:

                                                                            
10-base-rendering.conf         39-repl-corrective.conf  72-embedded-bitmaps.conf
15-tt-monospace-fonts.conf     40-nonlatin.conf         73-ttf-as-bitmap.conf
20-fix-cantarell.conf          45-latin.conf            74-force-autohint.conf
21-non-tt-rendering.conf       49-sansserif.conf        75-qt-subpixel-positioning.conf
21-tt-rendering.conf           50-user.conf             76-forced-synthetic.conf
30-non-tt-fonts.conf           51-local.conf            80-selective-rendering.conf
30-tt-fonts.conf               60-latin.conf            81-final-rendering.conf
35-droid-sans-group.conf       65-non-latin.conf        82-final-lang-spec.conf
35-droid-serif-group.conf      66-override.conf         90-no-synthetic.conf
37-repl-global.conf            67-aliases-wine.conf     95-reject.conf
38-repl-tt-traced-bitmap.conf  70-no-bitmaps.conf       README

No apparent improvement in PDFs though.

Arch Linux

#201 2013-05-16 06:12:40

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

#202 2013-05-16 06:57:16

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

#203 2013-05-16 07:40:48

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

#204 2013-05-16 11:25:13

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

#205 2013-05-16 12:30:27

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

#206 2013-05-16 12:41:24

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

#207 2013-05-16 12:50:40

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

#208 2013-05-16 13:12:26

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

#209 2013-05-16 14:18:46

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

#210 2013-05-16 15:02:29

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

#211 2013-05-16 16:21:50

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

#212 2013-05-16 16:34:16

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

#213 2013-05-16 17:01:02

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

#214 2013-05-16 17:48:16

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

#215 2013-05-16 18:49:38

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

#216 2013-05-16 19:28:34

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

#217 2013-05-16 20:04:28

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

#218 2013-05-16 20:22:15

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

#219 2013-05-16 20:25:24

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

#220 2013-05-17 11:11:06

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

#221 2013-05-17 11:29:02

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

#222 2013-05-17 12:04:21

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

#223 2013-05-17 12:38:21

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

#224 2013-05-17 13:43:46

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

#225 2013-05-17 14:12:26

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

Board footer