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

earsplit · 2014-01-23 00:48:35

el mariachi wrote:

right.. it seems terminus is working, but none of the artwiz fonts are

Make sure 10-scale-bitmap-fonts.conf is removed from /etc/fonts/conf.d . Updates sometimes add this sneaky guy back in

bohoomil · 2014-01-23 01:44:16

@earsplit, the symlink will be removed in the next update.

Ledti · 2014-01-23 01:48:48

Thought this might be worth mentioning here:

I switched over to chromium-dev and noticed that the fonts are a LOT better now, especially in the tab area. I'm not sure if Chromium now follows the native fontconfig or if they've just changed the defaults, but I'm guessing it has something to do with the new Aura back-end. Either way it's much improved. Something to look forward to if you use that browser.

bohoomil · 2014-01-23 02:00:46

@Ledti, thank you for mentioning that. This is good news, really. I am not a Chromium user myself, but I hope that Aura back-end will eventually replace webkit in third-party web browsers (dwb for that matter). It seems to be a right way to go, as far as I can see.

smeghead · 2014-01-23 03:16:34

WonderWoofy wrote:

@smeghead, see the Note in this section of the Font Configuration wiki page.

Those instructions appear to apply to a single-monitor setup. What I am trying to do is have different subpixel rendering for each of my monitors since one is VRGB and the other is RGB.

Xinkai · 2014-01-29 12:40:05

Hello bohoomil

I think I found a bug. I'll try to put it like this: Firefox doesn't respect non-UTF8 pages' font-family when infinality-bundle-ultimate is installed.

Here's an simple example showing the difference between Chinese and Japanese fonts of the same character 化。

Steps to reproduce the bug:

1. install ttf-ms-win8 from AUR, install fonts for every language.
2. using Firefox visit UTF-8 page, and GBK page.
3. notice that in each page, characters are rendered with different fonts (correct, expected behavior).
4. install infinality-bundle-ultimate, fc-presets to 2.
5. refresh both pages in Firefox.
6. notice in the GBK version of the page, all 3 化's are rendered with Japanese fonts.

This issue cannot be reproduced in Chromium.

Any ideas? Is this a problem with infinality-bundle-ultimate, with Firefox, or something that I missed?

bohoomil · 2014-01-30 01:15:59

@Xinkai, thank you for the feedback. I think you may try commenting out the following rule in /etc/fonts/conf.d/93-final-lang-spec-ms.conf:

  <match>
    <test name="lang" compare="contains">
      <string>zh</string>
    </test>
    <test name="family">
      <string>sans-serif</string>
    </test>
    <edit name="family" mode="prepend_first" binding="strong">
      <string>Meiryo</string>
    </edit>
  </match>

Right now, when the MS collection is used, Meiryo is the default font for both Japanese and Chinese languages. When you disable the rule above, Firefox should pick the right family if it is available, or select one on the list in /etc/fonts/conf.d/65-non-latin-ms.conf. Please, check out if this helps. Any language specific settings can be changed in the next fontconfig-ib release.

Xinkai · 2014-01-30 04:43:30

bohoomil wrote:

@Xinkai, thank you for the feedback. I think you may try commenting out the following rule in /etc/fonts/conf.d/93-final-lang-spec-ms.conf:
  <match>
    <test name="lang" compare="contains">
      <string>zh</string>
    </test>
    <test name="family">
      <string>sans-serif</string>
    </test>
    <edit name="family" mode="prepend_first" binding="strong">
      <string>Meiryo</string>
    </edit>
  </match>
Right now, when the MS collection is used, Meiryo is the default font for both Japanese and Chinese languages. When you disable the rule above, Firefox should pick the right family if it is available, or select one on the list in /etc/fonts/conf.d/65-non-latin-ms.conf. Please, check out if this helps. Any language specific settings can be changed in the next fontconfig-ib release.

Although I don't understand why this setting only affects GBK charset pages, this fix works! Thank you.

Keep doing this amazing work.

rumpelsepp · 2014-02-02 20:15:04

In my opionion you should consider replacing lucida grande with deja vu sans instead of droid sans as default. Many webservices use lucida grande as a main font and droid sans is a bit too narrow for this... I even could not read my email subjects in roundcube properly because droid sans looks very strange at small sizes. This is just my opinion. (-> I have customized this on my machine via 35-repl-custom.conf and it looks quite better.)

Last edited by rumpelsepp (2014-02-02 20:25:10)

bohoomil · 2014-02-03 00:16:50

Frankly, I am not glad with Droid Sans as a replacement for Lucida, too. DejaVu Sans, on the other hand, is simply too wide and typographically a totally different cup of tea (last.fm has been my reference for testing Lucida replacements). The right font would be something in between the two in size and graphically a bit less "geometric": Lucida is not a plain Helvetica / Arial variant of sans typeface, it is a bit curvy here and there and this is what makes it look unique. For the time being, the 35-repl-custom.conf is the best way to customize the typography: the file will not be overwritten during fontconfig updates and in some way it can make all the defaults' controversies less painful. As soon as I find something suitable, I will certainly mention it here, though.

Šaran · 2014-02-10 14:40:35

Hello,

Is changing DPI proper way to make fonts bigger?
I have 17" 1080p screen and after changing DPI to 120 fonts look just as nice as with 96, but I'm not
sure if there is anything else to be done (apart from changing font sizes, of course)?

brebs · 2014-02-10 15:33:37

Šaran wrote:

Is changing DPI proper way to make fonts bigger?

Your DPI should reflect the *reality* of your monitor. Otherwise, shapes like e.g. a circle will be drawn badly.

$ xdpyinfo | grep reso
  resolution:    131x119 dots per inch

It's TWO numbers. It's bizarre that people choose to ignore this

Šaran · 2014-02-10 16:14:43

Thanks.
I thought only increasing font size is not enough since on Windows changing DPI is the way to go.
I have just went back to 95x96 with increased GTK font size and everything looks great.

likytau · 2014-02-11 00:35:44

@ brebs: You can, however, multiply/divide both numbers by a constant.

But in general I agree: using a DPI that isn't in line with what your monitor actually is, leads to sizing eccentricities. Unfortunately a few apps seem to have nonsensical DPI treatment built in (App A ignores DPI, App B doesn't. Consequently, '10 point' in App A is a different size from '10 point' in App B, even with the same font.)

brebs · 2014-02-11 09:51:07

likytau wrote:

multiply/divide both numbers by a constant.

How would that be helpful?

There's a conspiracy to make Linux crap, like Windows, so be on your guard

likytau · 2014-02-11 12:59:53

brebs wrote:

likytau wrote:
multiply/divide both numbers by a constant.
How would that be helpful?

If you want to make your fonts globally smaller/bigger and maintain correct aspect ratio of shapes, duh.

There still does not seem to be an actual alternative to this for increasing font size, I'm just glad I don't have to do it myself.

Last edited by likytau (2014-02-11 13:02:16)

brebs · 2014-02-11 13:09:06

It would make much more sense, to me, for apps to accept e.g. 11.25pt sizes

It *should* be regarded as nuts, to have to "lie" to the renderer, to get the desired effect.

Last edited by brebs (2014-02-11 13:26:49)

prettyvanilla · 2014-02-11 22:58:18

I'm having issues with the powerline symbols (and its corresponding fontconfig file) as provided here.
For one, 10-powerline-symbols.conf doesn't strike me as particularly robust in the general case (I had to add Terminus to the list for the symbols to actually be used), and the symbols themselves are not properly scaled/aligned:

(Terminus, 9pt - Konsole)

I played around with other fonts and proper alignment seems to be the exception rather than the rule. Is the font itself just broken or can it be otherwise helped?

bohoomil · 2014-02-11 23:34:39

@prettyvanilla, I think you should take a look at this post and scroll down.

prettyvanilla · 2014-02-12 01:12:03

Thanks, I already saw that post before and since I do not have the same issue I didn't think it was Konsole's fault (bi-directional text rendering was already turned off - seems I stumbled over a related problem once)
I compared the rendering to a vte-based terminal emulator (konsole on the left, xfce4-terminal on the right):

Seems Konsole computes its line blocks with a one pixel offset and cuts off the glyph at the top. xfce4-terminal shows the hole glyph - the line block and the glyph base align.
Though there still seems to be a problem where the symbol is one pixel higher than the line block (is there a better word?) - that might be correctable via infinality-settings?
I may play around some more tomorrow...

RibShark · 2014-02-21 20:51:47

I installed inconsolata from your repository but when I set IntelliJ IDEA to display files in that font, everything is using the bold version. Is there a way to get IntelliJ to recognise the normal version?

monodromy · 2014-02-22 22:17:58

Just wanted to add my thanks for this fantastic project! Text on my screen is now so beautiful ...

agahnim · 2014-02-24 13:41:55

I have an issue. I have just installed this two days ago and everything went without a hitch. I also used this on my older laptop. I have been setting up arch on a new machine, and while the install of ibfonts-meta-base(extended) went perfectly, it says that both packages or not found now that I have had to do a fresh install on the new machine just a day after I installed them the first time. The other infinality packages installed, but it insists that both ibfonts-meta packages are not found in the repo. I have refreshed the repos and reinstalled all of the infinality packages and nothing has worked. Any suggestions?

Last edited by agahnim (2014-02-24 13:42:12)

bohoomil · 2014-02-24 20:50:53

@agahnim, the content of the ib-fonts repository has not changed in the meantime: take a look at this, all the packages are there and all are downloadable. Maybe it was just a short time server downtime? Would you mind running 'pacman -Syy' to force refresh the database?

@monodromy, thank you very much, I appreciate it.

agahnim · 2014-02-24 21:26:52

bohoomil wrote:

@agahnim, the content of the ib-fonts repository has not changed in the meantime: take a look at this, all the packages are there and all are downloadable. Maybe it was just a short time server downtime? Would you mind running 'pacman -Syy' to force refresh the database?

Thanks, but I checked the server and downloaded the package manually and tried installing it with Pacman -U and it would not complete due to dependencies not being met. I know that it was a meta package and was meant to install a group of packages and I was not going to download every package on the repo and install them all manually so I hoped that I would find that it is as you said, a server downtime. Thank you for the feedback. I was going to be a bit worried if it was somehow just me having the problem which would have been very odd seeing as everything else in the repo installed.

Arch Linux

#876 2014-01-23 00:48:35

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

#877 2014-01-23 01:44:16

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

#878 2014-01-23 01:48:48

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

#879 2014-01-23 02:00:46

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

#880 2014-01-23 03:16:34

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

#881 2014-01-29 12:40:05

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

#882 2014-01-30 01:15:59

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

#883 2014-01-30 04:43:30

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

#884 2014-02-02 20:15:04

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

#885 2014-02-03 00:16:50

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

#886 2014-02-10 14:40:35

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

#887 2014-02-10 15:33:37

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

#888 2014-02-10 16:14:43

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

#889 2014-02-11 00:35:44

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

#890 2014-02-11 09:51:07

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

#891 2014-02-11 12:59:53

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

#892 2014-02-11 13:09:06

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

#893 2014-02-11 22:58:18

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

#894 2014-02-11 23:34:39

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

#895 2014-02-12 01:12:03

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

#896 2014-02-21 20:51:47

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

#897 2014-02-22 22:17:58

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

#898 2014-02-24 13:41:55

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

#899 2014-02-24 20:50:53

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

#900 2014-02-24 21:26:52

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

Board footer