You are not logged in.

#226 2013-05-17 14:19:02

wilfriedd
Member
Registered: 2013-05-08
Posts: 9

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

bohoomil,

I've finally had the time to read over your new config files in detail, and I still have some questions/remarks.
I've noticed that on several occasions the ordering of the files might be off, resulting in some specific font rendering settings not being applied.

E.g., in the file 30-tt-fonts.conf you assign several fonts font_type 'TT Instructed Font', but ONLY if force_autohint is false. The problem is non of these fonts get assigned this font_type because force_autohint=false is only applied much later in 74-force-autohint.conf.

Now assume this font_type did get assigned correctly in 30-tt-fonts, even then nothing would happen to any of the rendering parameters. These parameters are set in 21-tt-rendering.conf, which is parsed even before the assignment of the font_type.

I double checked my reasoning by running fc-match on some fonts with FC_DEBUG=4, where you can follow the matching process in detail.

Overall I'm quite happy with how my fonts are rendered right now, so no complaints on that front.
I'm just making sure that your default settings are getting applied the way you intended smile

Offline

#227 2013-05-17 16:18:20

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

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

@jakobcreutzfeldt, first and foremost: thank you very much for the feedback. If I haven't forgotten about something, here is a list of workarounds that should let you get rid of the issues (keep in mind that in some cases I know that a problem exists, but either my insufficient knowledge or simply a lack of available fixes has made me look for alternative ways to deal with them).

PDF & Linux… I'm not sure if this is going to be an excuse, but I have never managed to achieve really decent results with either poppler or mupdf… (However, I haven't used mupdf engine for quite a while, so the latter may reflect my historical knowledge -- I will verify its validity one day.) With or without infinality, the text has never been comparable to what a web browser could produce (despite obvious differences between various browsers). Take a loot at my examples:

1. A New York Times article, printable version displayed in dwb: click.

Now a side-by-side comparison of pdfs: zathura (poppler version) and evince.

Fonts used:

name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
LGJWVO+Arial-BoldMT                  TrueType          WinAnsi          yes yes yes      6  0
AHRBMZ+Georgia-Bold                  TrueType          WinAnsi          yes yes yes      7  0
OSXSRP+Arial-BoldItalicMT            TrueType          WinAnsi          yes yes yes      8  0
FJVTMG+Georgia                       TrueType          WinAnsi          yes yes yes      9  0
VMTLRC+ArialMT                       TrueType          WinAnsi          yes yes yes     15  0

2. 'The Art of Community', again in zathura and evince: click.

Fonts used:

name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
OHLMOK+BaileyQuadITC-Bold            Type 1C           WinAnsi          yes yes no    1798  0
OHLMPI+Meridien-Roman                Type 1C           MacRoman         yes yes no    1792  0
OHLMPO+Meridien-Italic               Type 1C           WinAnsi          yes yes no    1790  0
OHLNAL+BaileySansITC-Book            Type 1C           MacRoman         yes yes no    1796  0
Times-Roman                          Type 1            WinAnsi          no  no  no    1794  0
EEZXZA+ITCBaileySansCom-Book         CID TrueType      Identity-H       yes yes yes   1803  0
MKMDPE+Myriad-CnSemibold             Type 1C           MacRoman         yes yes no      30  0
MKMDPM+Myriad-Condensed              Type 1C           MacRoman         yes yes no      33  0
EEZXZA+ITCBaileySansCom-Bold         CID TrueType      Identity-H       yes yes yes   1814  0
EEZXZA+MeridienCom-Roman             CID TrueType      Identity-H       yes yes yes   1811  0
EEZXZA+ITCBaileyQuadCom-Bold         CID TrueType      Identity-H       yes yes yes   1823  0
EEZXZA+ITCBaileySansCom-BookItalic   CID TrueType      Identity-H       yes yes yes   1829  0
EEZXZA+TheSansMonoCd-W5Regular       Type 1C           Builtin          yes yes yes   1834  0
EEZXZA+ArialUnicodeMS                CID TrueType      Identity-H       yes yes yes   1836  0

As I am using PDF format on a daily basis, the only working solution for me was to move to an application that does the job very well: Adobe Acrobat. I'm using an old Windows version in Wine (Adobe Acrobat 8 Standard, v. 8.1.0), which is more and more often replaced by FF with its native PDF viewer these days. Zathura is mainly my previewer when I create LaTeX documents.

jakobcreutzfeldt wrote:

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.

No need to remove anything: just install Courier Prime as advised earlier in this thread and you should be fine.

As for the thinish 's', copy this file to ~/.config/fontconfig/conf.d. Should help in FF at least: click.

By the way, GitHub uses Helvetica. Try replacing it with a different family than DejaVu Sans which, at certain weights, doesn't render correctly. For example, check Arimo--click--which should do a better job. You will need to copy this file to ~/.config/fontconfig/conf.d.


:: Registered Linux User No. 223384

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

Offline

#228 2013-05-17 17:01:34

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

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

@wilfriedd, thank you for the feedback. This is a bit bigger case, so I will need to investigate it longer to see what is really happening.

wilfriedd wrote:

I've noticed that on several occasions the ordering of the files might be off, resulting in some specific font rendering settings not being applied.

E.g., in the file 30-tt-fonts.conf you assign several fonts font_type 'TT Instructed Font', but ONLY if force_autohint is false. The problem is none of these fonts get assigned this font_type because force_autohint=false is only applied much later in 74-force-autohint.conf.

OK, let's check one of the first on the TT Instructed Font list, Albany:

Add Subst match
	font any force_autohint Equal false
	font any family Equal "Albany"
edit
	Edit font_type Assign "TT Instructed Font";


Add Subst match
	pattern any family Equal(ignore blanks) "Albany"
edit
	Edit family AppendLast "sans-serif";


FcConfigSubstitute Pattern has 35 elts (size 48)
	family: "Albany"(s)
	familylang: "en"(s)
	style: "Regular"(w)
	stylelang: "en"(w)
	fullname: "Albany"(w)
	fullnamelang: "en"(w)
	slant: 0(i)(s)
	weight: 80(i)(s)
	width: 100(i)(s)
	size: 12(f)(s)
	pixelsize: 12.5(f)(s)
	foundry: "monotype"(s)
	hintstyle: 3(i)(s)
	hinting: True(s)
	verticallayout: False(s)
	autohint: False(s)
	globaladvance: True(s)
	file: "/usr/share/fonts/TTF-StarOffice7/Albany.ttf"(s)
	index: 0(i)(s)
	outline: True(s)
	scalable: True(s)
	dpi: 75(f)(s)
	scale: 1(f)(s)

-- which correctly applies the following

$ cat /etc/fonts/conf.d/21-tt-rendering.conf

  <!-- -->
  <match target="font">
    <test name="font_type">
      <string>TT Instructed Font</string>
    </test>
    <edit name="antialias" mode="assign">
      <bool>true</bool>
    </edit>
    <edit name="hintstyle" mode="assign">
      <const>hintfull</const>
    </edit>
    <edit name="autohint" mode="assign">
      <bool>false</bool>
    </edit>
  </match>
  <!-- -->

Modifying the latter rules makes the font render differently. I can't see anything being wrong with it.

What you have observed may be overriding default settings when more than one set of rules is applied. This in turn can result in fc-match returning incoherent output.

Last edited by bohoomil (2013-05-18 02:24:26)


:: Registered Linux User No. 223384

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

Offline

#229 2013-05-17 17:33:25

jakobcreutzfeldt
Member
Registered: 2011-05-12
Posts: 1,041

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

@bohoomil: thanks for the suggestions! The problem is on my work computer and I'm home now so I'll give everything a try after the weekend. It must be quite a burden to have to support many people on something that can be quite complicated and seems to have a lot of pitfalls. So, your help is greatly appreciated!

Offline

#230 2013-05-17 18:00:30

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

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

jakobcreutzfeldt wrote:

It must be quite a burden to have to support many people on something that can be quite complicated and seems to have a lot of pitfalls.

Well, for various reasons the thing is complicated indeed and I don't want to pretend that I'm able to do more (nor know more) than I actually can (or do)… For example, the unsatisfactory quality of Linux native PDF rendering solutions is a common knowledge, and I'm the first on the list who would like to experience some real progress there. However, as long as there is more than only one method of doing something, it is possible to find a solution that makes the problem suck less. Feed it with a dose of common sense and life can be quite tolerable again. wink

There is one thing I don't remember mentioning clearly which in many cases is the solution that works miracles: switching to (better) quality font families. Now that there are really dozens of free fonts available that look great, we can gradually try replacing the ones we are used to with modern alternatives. Some time ago I started completing a list of recommended faces that can dramatically improve the picture on the screen. Once the list is a bit longer than now, I will make it available so that people can start experimenting with their font collections on their own.


:: Registered Linux User No. 223384

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

Offline

#231 2013-05-18 01:17:30

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,148

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

I enabled the custom repos. It is not that I do not trust bohoomil - aside from anything else, I trust WonderWoofy's word on this - but I'm not terribly happy trusting unsigned packages on the grounds that it does not really matter how trustworthy somebody is if the package is not identical to the one they created! Maybe I am just paranoid but it goes against the grain to install software where I cannot verify it at all. (Though I admit there are non-free things I have to do that with.)

I think I have missed something, though, as my fonts look fairly crap at this point.

I moved the infinality-settings.sh file from /etc/profile.d out of the way. (I did not delete it in case I want to revert to the AUR package.) I also deleted the symlink 52-infinality.conf from /etc/fonts/conf.d. But I think I've obviously missed something. Fonts are extremely difficult to read in both Okular and Firefox.

I am wondering slightly if this option is not really a good one for me. I noticed that it is said to work best with MS fonts. I only have quite old versions of these fonts. (I have a licence for Windows 7 but I don't have copies of the fonts.) Apart from the ones you can download (legitimately) for free, I'm probably using fonts from Mac OS X 10.4 and maybe Windows 95. With the AUR package, I was using a tweaked version of the linux option and this seemed to work better than when I tried to use MS fonts.

Last edited by cfr (2013-05-18 01:19:45)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#232 2013-05-18 01:26:04

anonymous_user
Member
Registered: 2009-08-28
Posts: 3,059

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

Would you mind posting a screenshot of the crappy fonts?

Also how are the results if you uninstall the Microsoft fonts?

Offline

#233 2013-05-18 01:47:30

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,148

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

It is definitely not the MS fonts. Even Droid (which I was using before everything got set to ABeeZee for some reason) looks terrible. Also, in Okular, it is using (I hope) fonts embedded in the PDF so that is Latin Modern so again, not the MS fonts.

I expect I've not removed something I should have or I've not added something I should have or I've done something in the past which is screwing things up. But whatever it is, I don't think it is the choice of fonts per se which was my first thought.

Konsole looks fine - not the menus and stuff, but the actual content.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#234 2013-05-18 01:52:58

anonymous_user
Member
Registered: 2009-08-28
Posts: 3,059

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

Someone recently complained about the fonts in PDFs (scroll up or look back a page) though I would still like to see what your Firefox/web page fonts are like.

Offline

#235 2013-05-18 02:20:27

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

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

cfr wrote:

I enabled the custom repos. It is not that I do not trust bohoomil - aside from anything else, I trust WonderWoofy's word on this - but I'm not terribly happy trusting unsigned packages on the grounds that it does not really matter how trustworthy somebody is if the package is not identical to the one they created! Maybe I am just paranoid but it goes against the grain to install software where I cannot verify it at all. (Though I admit there are non-free things I have to do that with.)

Signed packages will be available soon. I am testing them at the moment so it's really a matter of days when everything should be ready to go. (By the way {1}, why don't you simply use source packages? It doesn't last forever to build them… By the way {2}, you are aware of the fact that my signature won't have the same value as any of the TUs', aren't you? wink )

Ad rem:

Please, create a list of all installed fonts and upload it somewhere (e.g. gist.github.com):

fc-list : file family | sort -u > fonts.txt

You can push the same way the listing of /etc/fonts/conf.d, /etc/fonts/conf.avail.infinality, cat infinality-settings.sh (just in case…), anything fontconfig related in your home directory (~/.config/fontconfig, ~/.fonts.conf, etc). The problem has probably very little to do with fonts you own (Apple fonts will do) and tidying up the environment should suffice.

Last edited by bohoomil (2013-05-18 03:23:47)


:: Registered Linux User No. 223384

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

Offline

#236 2013-05-18 02:41:16

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

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

At one point, I had some extraneous links in /etc/fonts/conf.d, and it was making my crap look all funky.  Maybe this is the case for you too cfr?  Try comparing what you have in /etc/fonts/conf.d with "pacman -Ql fontconfig-infinality-ultimate | grep conf.d" and see if they match.

The other thing is that I had the old windows font package as well, and it was not the greatest.  I went through the process of downloading a new windows install disc, using wimlib (I think thats what I needed) and then extracting the fonts manually and putting them in the directory with the PKGBUILD.  It took a few minutes to get it all good, but the end result was well worth it.

Offline

#237 2013-05-18 09:38:52

Alcasa
Member
Registered: 2013-05-18
Posts: 46

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

Has anyone else noticed colofringing when browsing Gnome-Extensions with the Epiphany browser. It doesn't occur on either firefox or chromium. What is epiphany doing differently?

Offline

#238 2013-05-18 11:46:18

nasedo
Member
Registered: 2012-02-16
Posts: 11

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

jakobcreutzfeldt wrote:

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.

Chrome's libpdf seems to work quite well.

Chromium vs Okular


Moderator edit: Redacted link

Edit: Thanks and sorry about that. My point was that libpdf honors fontconfig/infinality settings while Okular (poppler) does not (or does it poorly).

Last edited by nasedo (2013-05-18 19:32:10)

Offline

#239 2013-05-18 14:49:14

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 20,232

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

nasedo,
Welcome to Arch Linux.  Please consider our published Forum Etiquette rules before posting.  This thread is about a fine piece of software contributed by one of our more respected members.  Please do not highjack threads for totally (or even tangentially) unrelated topics.

Thanks.

Last edited by ewaller (2013-05-18 14:49:47)


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#240 2013-05-18 17:46:23

wilfriedd
Member
Registered: 2013-05-08
Posts: 9

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

@bohoomil,

I'm afraid that the fact that Albany matches the rendering settings defined in 21-tt-rendering.conf is merely a coincidence. Best way to test this is changing them, they won't change the output of fc-match. (At least not on my computer)

The "Add Subst match" entries you posted in your first listing do not prove anything, FC_DEBUG=4 will just print all parsed rules in the order they appear in the config files, and thus in the order they are applied in the matching process.

If you read a bit further in the (too cryptic) output fc-match gives you with debugging on, you can see these rules are skipped for the reasons I posted previously. The lines starting with "FcConfigSubstitute test pattern" will apply all the rules sequentially which have the xml property target="pattern". After that the pattern built is matched as closely as possible with one of the installed fonts. Next, you can see lines starting with "FcConfigSubstitute test font", where your rules with target="font" are applied. It is in this category your rules for tt font rendering parameters are defined, so here you can see they are clearly skipped because the force_autohint=false is applied too late.

The test fails for every font you have defined as a member of the TT Instructed Font group. The second test defined by those rules is skipped after the first one fails

RULES:

...
  <match target="font">
    <test name="force_autohint">
      <bool>false</bool>
    </test>
    <test name="family">
      <string>SimHei</string>
    </test>
    <edit name="font_type" mode="assign">
      <string>TT Instructed Font</string>
    </edit>
  </match>
  <match target="font">
    <test name="force_autohint">
      <bool>false</bool>
    </test>
    <test name="family">
      <string>SimSun</string>
    </test>
    <edit name="font_type" mode="assign">
      <string>TT Instructed Font</string>
    </edit>
  </match>
...


DEBUG OUTPUT:

...
FcConfigSubstitute test font any force_autohint Equal false
No match
FcConfigSubstitute test font any force_autohint Equal false
No match
FcConfigSubstitute test font any force_autohint Equal false
No match
FcConfigSubstitute test font any force_autohint Equal false
No match
FcConfigSubstitute test font any force_autohint Equal false
No match
FcConfigSubstitute test font any force_autohint Equal false
No match
FcConfigSubstitute test font any force_autohint Equal false
No match
FcConfigSubstitute test font any force_autohint Equal false
No match
...

Because all the files in conf.d are parsed alphabetically, you should first set force_autohint false, then assign the font_type and at last the rendering settings. This mistake is made both for tt-fonts and non-tt-fonts.

On an unrelated note, is there a reason the dpi is no longer forced to 72? This makes fonts look a bit better on my system. Just asking, I can set it just as well in my own font.conf smile

Thanks again for your efforts to bring nice font rendering in an easy package to arch linux!

Offline

#241 2013-05-18 22:25:57

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,148

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

Thanks boohoomil, WonderWoofy. For some reason, my fonts no longer look as bad now the laptop has had a sleep but they are still not great and Okular is not much improved, if at all. (It is crucial they be readable without giving me a headache in Okular, Kile, Konsole, Firefox and Thunderbird, at least. But some of these e.g. Konsole are fine.)

I would post a screenshot but the site I used last time I did this won't load for me now. (Firefox is giving me trouble although starting once in safe mode seems to have helped for some reason.)

I have 3 stray non-infinality links/files in /etc/fonts/conf.d. One belongs to cups-filters (99pdftoopvp.conf). One belongs to font-bh-ttf (42-luxi-mono.conf). The other adds font directories for texlive fonts (09-texlive-fonts) which I suspect I should disable or edit:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <dir>/usr/local/texlive/current/texmf-dist/fonts/opentype</dir>
  <dir>/usr/local/texlive/current/texmf-dist/fonts/truetype</dir>
  <dir>/usr/local/texlive/current/texmf-dist/fonts/type1</dir>
  <dir>/usr/local/texlive/texmf-local/fonts/opentype</dir>
  <dir>/usr/local/texlive/texmf-local/fonts/truetype</dir>
  <dir>/usr/local/texlive/texmf-local/fonts/type1</dir>
</fontconfig>

I think this is based on an arch package which enables texlive fonts systemwide but is not actually from that package as I'm using the TeX Live install of texlive rather than the official one.

I already removed the contents of ~/.config/fontconfig/ and ~/.fontconfig so these are just directories. I don't have ~/.fonts.config. (The only other font related stuff in ~/ and ~/.config are backups or disabled copies of the files I cleared away.

No /etc/conf.d/in* at all.

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

$ l /etc/fonts/conf.d
total 28K
drwxr-xr-x 2 root root 4.0K Mai  18 01:25 ./
drwxr-xr-x 6 root root 4.0K Mai  18 01:10 ../
lrwxrwxrwx 1 root root   35 Gor  25  2012 09-texlive-fonts.conf -> ../conf.avail/09-texlive-fonts.conf
lrwxrwxrwx 1 root root   55 Mai  15 14:50 10-base-rendering.conf -> /etc/fonts/conf.avail.infinality/10-base-rendering.conf
lrwxrwxrwx 1 root root   59 Mai  15 14:50 15-tt-monospace-fonts.conf -> /etc/fonts/conf.avail.infinality/15-tt-monospace-fonts.conf
lrwxrwxrwx 1 root root   54 Mai  15 14:50 20-fix-cantarell.conf -> /etc/fonts/conf.avail.infinality/20-fix-cantarell.conf
lrwxrwxrwx 1 root root   57 Mai  15 14:50 21-non-tt-rendering.conf -> /etc/fonts/conf.avail.infinality/21-non-tt-rendering.conf
lrwxrwxrwx 1 root root   53 Mai  15 14:50 21-tt-rendering.conf -> /etc/fonts/conf.avail.infinality/21-tt-rendering.conf
lrwxrwxrwx 1 root root   53 Mai  15 14:50 30-non-tt-fonts.conf -> /etc/fonts/conf.avail.infinality/30-non-tt-fonts.conf
lrwxrwxrwx 1 root root   49 Mai  15 14:50 30-tt-fonts.conf -> /etc/fonts/conf.avail.infinality/30-tt-fonts.conf
lrwxrwxrwx 1 root root   57 Mai  15 14:50 35-droid-sans-group.conf -> /etc/fonts/conf.avail.infinality/35-droid-sans-group.conf
lrwxrwxrwx 1 root root   58 Mai  15 14:50 35-droid-serif-group.conf -> /etc/fonts/conf.avail.infinality/35-droid-serif-group.conf
lrwxrwxrwx 1 root root   52 Mai  15 14:50 37-repl-global.conf -> /etc/fonts/conf.avail.infinality/37-repl-global.conf
lrwxrwxrwx 1 root root   62 Mai  15 14:50 38-repl-tt-traced-bitmap.conf -> /etc/fonts/conf.avail.infinality/38-repl-tt-traced-bitmap.conf
lrwxrwxrwx 1 root root   56 Mai  15 14:50 39-repl-corrective.conf -> /etc/fonts/conf.avail.infinality/39-repl-corrective.conf
lrwxrwxrwx 1 root root   49 Mai  15 14:50 40-nonlatin.conf -> /etc/fonts/conf.avail.infinality/40-nonlatin.conf
lrwxrwxrwx 1 root root   31 Med  20  2012 42-luxi-mono.conf -> ../conf.avail/42-luxi-mono.conf
lrwxrwxrwx 1 root root   46 Mai  15 14:50 45-latin.conf -> /etc/fonts/conf.avail.infinality/45-latin.conf
lrwxrwxrwx 1 root root   50 Mai  15 14:50 49-sansserif.conf -> /etc/fonts/conf.avail.infinality/49-sansserif.conf
lrwxrwxrwx 1 root root   45 Mai  15 14:50 50-user.conf -> /etc/fonts/conf.avail.infinality/50-user.conf
lrwxrwxrwx 1 root root   46 Mai  15 14:50 51-local.conf -> /etc/fonts/conf.avail.infinality/51-local.conf
lrwxrwxrwx 1 root root   46 Mai  15 14:50 60-latin.conf -> /etc/fonts/conf.avail.infinality/60-latin.conf
lrwxrwxrwx 1 root root   50 Mai  15 14:50 65-non-latin.conf -> /etc/fonts/conf.avail.infinality/65-non-latin.conf
lrwxrwxrwx 1 root root   49 Mai  15 14:50 66-override.conf -> /etc/fonts/conf.avail.infinality/66-override.conf
lrwxrwxrwx 1 root root   53 Mai  15 14:50 67-aliases-wine.conf -> /etc/fonts/conf.avail.infinality/67-aliases-wine.conf
lrwxrwxrwx 1 root root   51 Mai  15 14:50 70-no-bitmaps.conf -> /etc/fonts/conf.avail.infinality/70-no-bitmaps.conf
lrwxrwxrwx 1 root root   57 Mai  15 14:50 72-embedded-bitmaps.conf -> /etc/fonts/conf.avail.infinality/72-embedded-bitmaps.conf
lrwxrwxrwx 1 root root   54 Mai  15 14:50 73-ttf-as-bitmap.conf -> /etc/fonts/conf.avail.infinality/73-ttf-as-bitmap.conf
lrwxrwxrwx 1 root root   55 Mai  15 14:50 74-force-autohint.conf -> /etc/fonts/conf.avail.infinality/74-force-autohint.conf
lrwxrwxrwx 1 root root   64 Mai  15 14:50 75-qt-subpixel-positioning.conf -> /etc/fonts/conf.avail.infinality/75-qt-subpixel-positioning.conf
lrwxrwxrwx 1 root root   57 Mai  15 14:50 76-forced-synthetic.conf -> /etc/fonts/conf.avail.infinality/76-forced-synthetic.conf
lrwxrwxrwx 1 root root   60 Mai  15 14:50 80-selective-rendering.conf -> /etc/fonts/conf.avail.infinality/80-selective-rendering.conf
lrwxrwxrwx 1 root root   56 Mai  15 14:50 81-final-rendering.conf -> /etc/fonts/conf.avail.infinality/81-final-rendering.conf
lrwxrwxrwx 1 root root   56 Mai  15 14:50 82-final-lang-spec.conf -> /etc/fonts/conf.avail.infinality/82-final-lang-spec.conf
lrwxrwxrwx 1 root root   53 Mai  15 14:50 90-no-synthetic.conf -> /etc/fonts/conf.avail.infinality/90-no-synthetic.conf
lrwxrwxrwx 1 root root   47 Mai  15 14:50 95-reject.conf -> /etc/fonts/conf.avail.infinality/95-reject.conf
-rw-r--r-- 1 root root  366 Mai  28  2012 99pdftoopvp.conf
-rw-r--r-- 1 root root  959 Mai  15 14:50 README

More in a bit.

EDIT: oops:

$ cat /etc/profile.d/infinality-settings.sh 
###################################################################
### INFINALITY ENVIRONMENT VARIABLES FOR EXTRA RUN-TIME OPTIONS ###
################### custom settings by bohoomil ###################
###################################################################

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"
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="0"
export INFINALITY_FT_CHROMEOS_STYLE_SHARPENING_STRENGTH="35"
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"

Last edited by cfr (2013-05-18 22:45:48)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#242 2013-05-18 22:31:02

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

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

@wilfriedd: genius. tongue Now I get your point. It was enough to assign lower numbers to TT/NOT TT/MONO groups, which means placing them in 71-80 range, where all adjustments are supposed to be performed. Now the numbers indeed look different. What's bugging me is that fonts look just like before the shift (it seems that the whole process will always be more corporal than mathematical for me). smile Of course, I will revise the rendering before uploading upgraded and signed packages.

72dpi was removed from the /etc/fonts/fonts.conf because some people complained about fonts in certain applications (like Openbox) being too small by default (or shoud I say: the fault?). Having realized that the benefits of lowering dpi in fonts.conf were lesser than expected, I decided to remove the lines from the global file and move them to the local configuration. In the next upgrade such an option will be available in the collection of tweak-it-yourself files.

I truly appreciate the effort you've put into investigating and patiently explaining the problem to me: that's something I couldn't expect anyone to do. Thank you very much for that. smile


:: Registered Linux User No. 223384

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

Offline

#243 2013-05-18 22:36:52

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

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

@cfr, thank you for the info. I will look into it as soon as possible.

I believe you are a KDE user: if you really are, please set the native KDE font rendering parameters so that they reflect the basic infinality settings found in 10-base-rendering.conf. Any conflict between the two (a DE / fontconfig-infinality) can lead to frustrating hodgepodge on the screen.


:: Registered Linux User No. 223384

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

Offline

#244 2013-05-18 22:54:03

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,148

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

bohoomil wrote:

@cfr, thank you for the info. I will look into it as soon as possible.

I believe you are a KDE user: if you really are, please set the native KDE font rendering parameters so that they reflect the basic infinality settings found in 10-base-rendering.conf. Any conflict between the two (a DE / fontconfig-infinality) can lead to frustrating hodgepodge on the screen.

I am a KDE user and I already checked this under appearance > fonts in system settings and think I set things correctly:

I do have custom fonts set (from the Droid family in sizes 8 and 9: Droid Serif, Droid Sans Mono and Droid Sans [unknown]).

Anti-aliasing is set to use System Settings and the DPI box is not checked (so the dropdown shows 96dpi greyed out).

The only thing I changed were the default fonts which had all been set to ABeeZee after installing the ultimate bundle. (But I did that yesterday as it was the first thing I checked.)

I don't think I've ever really used the font management panel itself in KDE but basically, it just shows a list of fonts all of which are checked.

EDIT: In the README in /usr/share/doc/..., it says that there are 3 brightness/darkness levels to choose from and that one of the inactive ones may be uncommented and the currently active one commented in /etc/profile.d/infinality-settings.sh. However, my copy doesn't seem to have any settings commented. Have I somehow messed this file up? To the best of my knowledge, I haven't touched it. (My copy is posted above.)

EDIT 2: List of fonts is at http://bpaste.net/show/100015/. Not sure if that is where I was meant to put it but it does seem to be there. As I say, maybe I should do something to/with the 09 config for texlive. But for pdf, isn't it using the embedded fonts anyway? (These are Latin Modern in most cases and in the pdf I was looking at by way of a test. Definitely embedded subset.)

Last edited by cfr (2013-05-19 01:46:31)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#245 2013-05-19 02:45:46

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

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

cfr wrote:

As I say, maybe I should do something to/with the 09 config for texlive. But for pdf, isn't it using the embedded fonts anyway?

Thank you for the file -- that's exactly what I was asking for.

09-texlive-fonts.conf's sole task is to provide access to TeXLive fonts: nothing more, nothing less. It has no influence on rendering whatsoever, and if your fonts are accessible for fc-list it means that everything is working as expected here.

The odd thing is that TeX Gyre fonts are correctly reproduced on my screen, being probably for the first time usable, and so they should be on yours. What I am actually going to do: I will create a clean Arch installation with KDE and the exact copy of your font configuration. It will take a few days till I am done with testing it, but this way I will be able to check in the environment itself where the source of your problems may be hidden.

By the way, if one or two other KDE users could report how the bundle is working in their cases, it could help a lot.

The infinality-settings.sh is indeed an older copy. The new one hasn't been officially distributed yet (it came as an add-on with the updated fontconfig package), but it case it got lost somewhere, here it comes again:

### infinality environment variables for extra run-time options ###
### custom settings by bohoomil ###
### http://bohoomil.cu.cc ###

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

Last edited by bohoomil (2013-05-19 02:49:15)


:: Registered Linux User No. 223384

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

Offline

#246 2013-05-19 07:04:06

nasedo
Member
Registered: 2012-02-16
Posts: 11

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

@bohoomil: Here's my report, I hope it helps. Again, thanks for making fonts nicer for all of us.

I use KDE with Awesome as window manager. In my case fonts look fine everywhere (Konsole, Dolphin, Akregator etc, except Okular, but just inside PDFs, UI is fine). Same with non-KDE applications. My default font is Droid Sans [unknown] in sizes 8 and 9 but any other font looks just as good.

I set 'Use anti-aliasing' to 'System Settings' and disabled 'Force fonts DPI' checkbox. Then I created ~/.config/fontconfig/fonts.conf as recommended somewhere on Infinality forum:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>

</fontconfig>

And made it immutable (If not it would quickly get overwritten with what I guess are KDE's defaults, regardless of my disabling those settings earlier). I also noticed that Xft.hintstyle as shown by 'xrdb -q' changes to hintmedium every time I open KDE's Font Settings (even if I don't change anything) and right after booting into KDE.

Last edited by nasedo (2013-05-19 07:04:21)

Offline

#247 2013-05-19 08:13:09

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

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

Thank you very much, nasedo. It helps indeed.

Once upon a time, when cleartype was still on top of the world, there was a patch for poppler-qt when someone wanted to beef up Okular's output a bit… Today we can use Okular driven by mupdf: has anyone tried it out? Better yet, with infinality patches? If yes, any impressions?


:: Registered Linux User No. 223384

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

Offline

#248 2013-05-19 14:57:53

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,148

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

Thanks very much. That is very generous.

My fonts have actually settled down a lot in the UI now although I'm not sure why. Okular is currently one of my main issues, especially with Latin Modern. Before I switched to the new bundle, my pdfs were clearly legible in Okular and now they are very difficult.

I thought that firefox was doing better, too, because the Arch forums were legible again but I just realised other websites are not. I know this is a change from before I installed the bundle because my blog now looks crap and I was editing it only a couple of days ago so I know it looked OK then.

I'm going to try the new infinality-settings.sh. I am not sure why I have the old version since I had a completely different infinality-settings.sh before installing the new bundle. Maybe I just need to pick a darker setting or something. Do I need to reboot to ensure I'm using the new file? Or can I just switch to multiuser target and back to graphical?

EDIT: poppler is required for Okular to be able to save annotations in the PDF itself. Plus Okular showed PDFs OK before I installed the bundle. (I have fiddled in the past to adjust things, though, so maybe I just need to figure out what I did and see if I can apply it in the new set up.)

EDIT: Actually, I see the defaults have changed in the new version so I'll try those first.

Last edited by cfr (2013-05-19 15:05:11)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#249 2013-05-19 16:20:37

wilfriedd
Member
Registered: 2013-05-08
Posts: 9

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

@bohoomil,

No problem, the pleasure was mine smile I'm looking forward to testing your new revised packages.

Offline

#250 2013-05-19 17:43:08

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,148

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

nasedo wrote:

I set 'Use anti-aliasing' to 'System Settings' and disabled 'Force fonts DPI' checkbox. Then I created ~/.config/fontconfig/fonts.conf as recommended somewhere on Infinality forum:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>

</fontconfig>

And made it immutable (If not it would quickly get overwritten with what I guess are KDE's defaults, regardless of my disabling those settings earlier).

Thanks. I hadn't realised it would do this so I've created this now and removed write permission.

EDIT: added immutable flag. Otherwise it immediately overwrites even though no write permission for file (I guess it replaces the whole file).

I also noticed that Xft.hintstyle as shown by 'xrdb -q' changes to hintmedium every time I open KDE's Font Settings (even if I don't change anything) and right after booting into KDE.

This is also annoying although I guess it does not affect fontconfig but only applications which don't use that?

I *think* but have not yet tested this extensively that if you enable configuration through the fonts settings panel, set the defaults as you actually want them, apply that, then return the settings to the non-interference mode, then apply that, that the settings will then "stick" for Xft etc. at whatever you chose when you enabled configuration via the settings panel.

Last edited by cfr (2013-05-19 18:23:58)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

Board footer

Powered by FluxBB