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

jakobcreutzfeldt · 2013-05-23 13:05:01

bohoomil wrote:

1. FT_LOAD_NO_AUTOHINT is not a safe option since several fonts need autohinting in order to be legible at all. I reverted it (temporarily & for testing purposes) to previously used FT_LOAD_TARGET_LIGHT and it seems to do much better with texts with embedded fonts that require autohinter. (By the way, the effect of banning autohinter altogether was exactly what was happening with the previous fontconfig settings. )

Ok on removing the Autohint thing. I wasn't sure. However, you shouldn't use FT_LOAD_TARGET_LIGHT. From the Cairo documentation (emphasis added):

Cairo Documentation wrote:

load_flags: flags to pass to FT_Load_Glyph when loading glyphs from the font. These flags are OR'ed together with the flags derived from the cairo_font_options_t passed to cairo_scaled_font_create(), so only a few values such as FT_LOAD_VERTICAL_LAYOUT, and FT_LOAD_FORCE_AUTOHINT are useful. You should not pass any of the flags affecting the load target, such as FT_LOAD_TARGET_LIGHT.

(in the Freetype2 documentation, it states that the LOAD_TARGET flags shouldn't be OR'ed with anything)

edit: I just tested removing the autohinter banning and you're right, it does fix things (i.e. where in the original font a capital "M" has angled stems, banning the autohinter made them vertical, as visible in the first screenshot that I posted)

bohoomil wrote:

2. I changed CAIRO_SUBPIXEL_ORDER from DEFAULT to RGB, which improved the legibility of texts at lower zooms. We are using rgb in the bundle by default, so doing the same here seemed like a consistent action. Besides, it reduced the over-sharpness of fonts and extremely strong colorization.

This was another one I wasn't sure on, since I guess some people might have non-RGB monitors. I had (naively) assumed that by setting it to DEFAULT, it would defer to the fontconfig settings but if you see an improvement I guess I was wrong. Anyway, you're right, since we're defaulting to RGB in the bundle, we might as well hard-code it here too.

bohoomil wrote:

All in all: I feel there is a way to polish it even further and I am extremely happy that you suggested a way to go. I will keep playing with it on my own and will test any improvement & new option to come. Thank you very much!

Yes, there is probably still room for improvement! But I'm glad that we're making some progress! Play with the HINT_METRICS option. I wasn't sure about that one. HINT_SLIGHT is definitely the way to go, though.

Last edited by jakobcreutzfeldt (2013-05-23 13:16:22)

bohoomil · 2013-05-23 21:11:36

The packages will be probably available tomorrow, still without updated documentation, though. However, as no one has been injured during tests (thanks guys ), I think there is no point in further waiting.

And now in order to bring some hope back to cfr's desktop: a little show of free fonts both on clumsy pages of LibreOffice Writer and as an image viewed in zathura poppler (git version, no patches, no tweaks):

LibreOffice document: click,
…and the same document exported to PDF format: part 1 and part 2.

If there are more people around keen on hacking available pdf viewers and / or engines, please consider opening a dedicated thread where all the experiments could be located and discussed. I am not sure how far the subject can be pushed, what can be improved and what can't, due to technical limitations. Nevertheless, any good idea is worth checking out: after all, while digging deep in the ground one is more likely to find a diamond than when (s)he keeps watching the flat surface.

Thanks.

cfr · 2013-05-23 21:45:17

bohoomil wrote:

@cfr, please consult the screenshots and $1 above. Latin Modern, CMU and Tex Gyre families render very well, I can provide relevant screenshots for comparison (here is a quick shot of Droid Serif Bold in LibreOffice Writer: click). If the pictures look OK to you, then there still must be a problem with your configuration as this is what by default the bundle should do (and does). If not -- well, at the moment I really have no clue what I could do about it…

All of those screenshots look wonderful. I find the first slightly less readable than the others but tons more readable than what I get. So something is still awry with my configuration. I haven't installed your latest fixes yet, though, so maybe I should wait and troubleshoot then since things are going to change quite a bit. (Basically, I can't figure out what I've screwed up right now.)

bohoomil · 2013-05-23 22:46:37

cfr wrote:

Basically, I can't figure out what I've screwed up right now.

Neither can I, unfortunately… I believe there is something you can try doing when the updated packages are available. This is a bit rough approach, but when everything has been performed correctly, things shouldn't get any worse.

Install the upgrade (if something goes wrong, for example with signatures, there is still the previous copy in your system).
Leave KDE and log in the good, old, pitch black Linux console.
Remove fontconfig-infinality-ultimate with 'pacman -Rdd'. This should leave any leftovers from previous installations in /etc/fonts/conf.d and /etc/fonts/conf.avail.infinality.
Check both locations and clean them entirely if necessary. /etc/fonts/conf.avail can be left intact because we are not using it. As always, before running 'rm *' on a group of files, backup the whole directories so that we can recreate symlinks that may be necessary for the operation of your system. In your case there can be at least two such files: '09kde.conf'--if I recall its name correctly--that comes with KDE and '99pdftoopvp.conf', installed with cups-filters. The first one may be necessary only when you keep custom fonts in /usr/share/local/fonts; otherwise it's of no use. The latter provides a simple font substitution for ZapfDingbats & Symbol: copying back to its original destinations won't hurt.
Now install fontconfig-infinality-ultimate again.
Before going back to KDE, disable your local fontconfig directory:
```
mv ~/.config/fontconfig{,.bkp}
```
so that you begin with a generic ultimate configuration only.
Back in KDE go to the system settings and check if the basic values reflect the ones in /etc/fonts/conf.d/10-base-rendering.conf. If not, set them accordingly. There is one nasty option there that may be a real troublemaker: it lets you exclude fonts at particular sizes from being applied the default rendering values. If you find that this box is checked, uncheck it.
Launch your applications and check the results.

The screenshots will always look different depending on a machine they were taken in. On the other hand, if your impression is rather positive, it means that the same state can be reproduced in your environment. Little tweaks may be necessary (as long as they are possible) but the overall experience should be at least 98% the same at the start.

Additionally, you can create custom 60-latin.conf and 65-non-latin.conf in your local ~/.config/fontconfig/conf.d. This can help fontconfig choose proper font families in a less arbitrary way.

cfr · 2013-05-24 21:32:15

Thanks very much for all your help with this. I am afraid I failed at step 1. Yesterday, I installed and trusted your signature using the fingerprint and instructions you'd posted but I still get:

(17/17) checking keys in keyring                                                     [################################################] 100%
(17/17) checking package integrity                                                   [################################################] 100%
error: freetype2-infinality-ultimate: missing required signature
:: File /var/cache/pacman/pkg/freetype2-infinality-ultimate-2.4.11-4-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: fontconfig-infinality-ultimate: missing required signature
:: File /var/cache/pacman/pkg/fontconfig-infinality-ultimate-1:2.10.92-12-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: cairo-infinality-ultimate: missing required signature
:: File /var/cache/pacman/pkg/cairo-infinality-ultimate-1.12.14-8-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: lib32-freetype2-infinality-ultimate: missing required signature
:: File /var/cache/pacman/pkg/lib32-freetype2-infinality-ultimate-2.4.11-3-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: lib32-fontconfig-infinality-ultimate: missing required signature
:: File /var/cache/pacman/pkg/lib32-fontconfig-infinality-ultimate-2.10.92-3-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] y
error: failed to commit transaction (invalid or corrupted package)

I upgraded the rest of the system ignoring the 5 fontconfig packages and I'm just reinstalling the previous versions from the cache. (I don't think pacman actually did anything much but I'd rather be sure the database is in sync with what's installed.)

Not sure what I did wrong yet...

EDIT: I tried signing it again just in case I'd forgotten the second step but a listing looked no different afterwards. (This isn't very surprising - I'm pretty certain I signed it yesterday already.) Here's what a check gives me:

gpg> check
uid  bohoomil (dev key) <bohoomil@zoho.com>
sig!3        962DDE58 2013-04-22  [self-signature]
sig!  L      C0ADE01E 2013-05-23  Pacman Keychain Master Key <pacman@localhost>

gpg> list

pub  2048R/962DDE58  created: 2013-04-22  expires: never       usage: SC  
                     trust: unknown       validity: full
sub  2048R/C83B4AD8  created: 2013-04-22  expires: never       usage: E   
[  full  ] (1). bohoomil (dev key) <bohoomil@zoho.com>

Last edited by cfr (2013-05-24 21:53:00)

bohoomil · 2013-05-24 22:30:40

Check again, please, should be OK now.

cfr · 2013-05-25 00:49:50

Great! At least, the bit you did was great. I have evidently screwed up. I deleted the fontconfig cache in my home directory assuming that it would get recreated as needed but I guess that doesn't happen. At least LibreOffice no longer works. It doesn't give any errors. I'm just assuming that must be what causes it to fail.

Or else it is one of the following which I moved out of /etc/fonts/conf.d:

ls conf.d.dis/
09-texlive-fonts.conf@                  20-unhint-small-dejavu-serif.conf@  57-dejavu-sans.conf@
20-unhint-small-dejavu-sans-mono.conf@  42-luxi-mono.conf@                  57-dejavu-serif.conf@
20-unhint-small-dejavu-sans.conf@       57-dejavu-sans-mono.conf@           99pdftoopvp.conf

I know that LibreOffice needs ttf fonts but it isn't as though I don't have plenty of those installed. And these are just configuration files anyway, it doesn't affect availability of the fonts themselves that I know of.

However, LibreOffice appears to now only know about OpenSymbol which it installs itself. (At least, as far as I can tell from the two files it does seem to have recreated.)

Is there a trick to getting it to start up as if for the first time so it reconfigures itself? I tried the wiki page and the man page and then started to panic. (I'm in the middle of marking finals and I need the spreadsheet.) However, it will still work on my office machine so I should not really be panicking. (Office machine has Fedora.) Inconvenient but hardly fatal.

Last edited by cfr (2013-05-25 00:51:22)

bohoomil · 2013-05-25 01:31:05

"I didn't do it! I didn't!" -- It's going to become my third nature, because I have already two. ;p

The issue seems to be related to icu, updated only a couple of hours (?) ago. Here is a relevant part of my dmesg:

[23302.539526] traps: soffice.bin[9711] general protection ip:7fad8ff9f233 sp:7fffe06aecc0 error:0 in libicule.so.51.2[7fad8ff86000+55000]

Check yours.

Edit 1: Yep: check the bug: https://bugs.archlinux.org/task/35466.

Edit 2: Edit: You may want to update your font cache with 'fc-cache -f -v': if you installed fontconfig using the method I had mentioned earlier, sometimes fc-cache can not run automatically. However, each time you launch an application that requires fontconfig, font cache is updated anyway.

Besides, I realized that unchecking the 'Use hardware acceleration' box in LO options (LibreOffice → View [Graphics output]) may have positive impact on text quality.

From the bunch of config files you saved, you only need those two:

09-texlive-fonts.conf
99pdftoopvp.conf

The rest is already implemented in the bundle.

Last edited by bohoomil (2013-05-25 02:11:51)

cfr · 2013-05-25 02:22:37

I was about to say that replacing all of the symlinks I'd removed in /etc/fonts/conf.d doesn't seem to have helped even though I updated the font cache every time.

Incidentally, my Okular rendering looks about as it did before (before I started replacing sym links). Mind you, the rendering in LibreOffice no longer seems like such a big deal .

I'm somewhat relieved that this is not what I did. I was starting to think I was going nuts. (More nuts.)

Is that what error 139 is? That's the most useful information I found on why it won't start.

dmesg:

[103830.769467] soffice.bin[26879]: segfault at 10 ip 00007f0411b8cb60 sp 00007fff1c671578 error 4 in libicule.so.51.2[7f0411b61000+55000]
[103831.283942] systemd-journald[231]: Failed to set ACL on /var/log/journal/997d1b9ffaa8efe300b8ff4100003004/user-1000.journal, ignoring: Invalid argument
[103831.384603] systemd-journald[231]: Failed to write entry, ignoring: Argument list too long

journalctl -b shows something similar but without the complaints about ACLs.

I had checked .xsession-errors, errors.log, Xorg.0.log and libreoffice's bugzilla...

I also probably undid the effects of starting with default infinality settings by putting everything back in conf.d. (Obviously I figured LO with poor rendering was better than no LO at all and was assuming I must have removed *something* crucial.)

I did not have the kde specific file in conf.d you mentioned. I am not clear whether the others should be there or not. The only non-Arch/AUR one is 09 and that just adds additional font directories under /usr/local/texlive.

cfr · 2013-05-25 02:29:29

bohoomil wrote:

Edit 2: Edit: You may want to update your font cache with 'fc-cache -f -v': if you installed fontconfig using the method I had mentioned earlier, sometimes fc-cache can not run automatically. However, each time you launch an application that requires fontconfig, font cache is updated anyway.

I haven't been using -v but that just makes it more verbose, right?

Besides, I realized that unchecking the 'Use hardware acceleration' box in LO options (LibreOffice → View [Graphics output]) may have positive impact on text quality.

Would like to try this but cannot right now... .

EDIT: downgraded and unchecked "Defnyddio cyflymu caledwedd" which sounds right. I don't understand one of the words in the option below that so I left that checked as you only mentioned unchecking one of them.

EDIT 2: thought droid looked odd, found LO had changed it to gentium. Anyway, Droid Serif bold now looks tons better in LO than it did although I'm not sure if this is unchecking the box of other changes you made but it looks really nice now - thank you!

From the bunch of config files you saved, you only need those two:
09-texlive-fonts.conf
99pdftoopvp.conf
The rest is already implemented in the bundle.

I've removed the dejavu links as those were unowned. Given that the remaining link belongs to a package, what is the best way of removing/overriding it?

/etc/fonts/conf.d/42-luxi-mono.conf is owned by font-bh-ttf 1.0.3-1

Last edited by cfr (2013-05-25 02:47:48)

bohoomil · 2013-05-25 02:53:42

3. Inside the Luxi Mono file, you will find the following:

  <match target="scan">
    <test name="family">
      <string>Luxi Mono</string>
    </test> 
    <edit name="spacing">
      <int>100</int>
    </edit>
  </match>

which is already a part of 93-final-rendering.conf. If 42-luxi-mono.conf is a link, just remove it. (I realize I should add it to 'remove redundant links' array.)

2. Did you downgrade icu? When you do, check LO.

1. '-v' doesn't matter: I run it this way because I can see what's going on.

Let me sum up:

a) You installed the upgrade, everything was set up automatically, now you have 30-32 files in conf.d, 38 targets in conf.avail.infinality, $HOME/.config/fontconfig is disabled, KDE font settings are set correctly to mimic 10-base-config.conf.

b) When you launch Okular, it seems that your machine has been frozen in time and didn't react to the upgrade / maintenance routines / cleaning up / casting spells, etc. No change, even a slightest, tiniest shade of what can be seen in my screenshots.

If a) is true and b) is true, it means I have really nothing left in my toolbox. I'm very sorry for making you busy for a long time, but I have no clue what is / may be happening on your side…

cfr · 2013-05-25 03:25:25

bohoomil wrote:

If 42-luxi-mono.conf is a link, just remove it.

OK Done.

2. Did you downgrade icu? When you do, check LO.

Yes. LO looks much better. Very nice, in fact. Droid Serif bold looks good, including the numerals! (I edited my post above earlier but it probably was not that obvious.)

Let me sum up:
a) You installed the upgrade, everything was set up automatically, now you have 30-32 files in conf.d, 38 targets in conf.avail.infinality, $HOME/.config/fontconfig is disabled, KDE font settings are set correctly to mimic 10-base-config.conf.

Yes. 32 files in conf.d. 38 files in conf.avail.infinality.

$HOME/.config/fontconfig is not really disabled. It is just mimicking infinality:

cat .config/fontconfig/fonts.conf 
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>rgb</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintfull</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>
 <dir>~/.fonts</dir>
</fontconfig>

b) When you launch Okular, it seems that your machine has been frozen in time and didn't react to the upgrade / maintenance routines / cleaning up / casting spells, etc. No change, even a slightest, tiniest shade of what can be seen in my screenshots.

Yes.

If a) is true and b) is true, it means I have really nothing left in my toolbox. I'm very sorry for making you busy for a long time, but I have no clue what is / may be happening on your side…

Did you create a PDF with Latin Modern? If so, could I possibly see the PDF? (Not just a screenshot.) I'd like to know if the same PDF looks different on my machine than yours.

Last edited by cfr (2013-05-25 03:26:09)

bohoomil · 2013-05-25 03:27:12

Sure. Check this post.

Oh, sorry -- here is the link: a pdf file.

Last edited by bohoomil (2013-05-25 03:31:07)

cfr · 2013-05-25 03:30:14

Also:

$ cat .kde4/share/config/kcmfonts 
[General]
dontChangeAASettings=false
forceFontDPI=96

I'm not sure what this file does. I deleted it earlier but it has reemerged.

bohoomil · 2013-05-25 03:33:04

cfr wrote:

Also:
$ cat .kde4/share/config/kcmfonts 
[General]
dontChangeAASettings=false
forceFontDPI=96
I'm not sure what this file does. I deleted it earlier but it has reemerged.

It seems like this reflects your KDE settings, I'm afraid… Are you sure you have antialiasing set there?

cfr · 2013-05-25 03:38:44

bohoomil wrote:

Sure. Check this post.
Oh, sorry -- here is the link: a pdf file.

Thanks. Looks fantastic. At least, LM Roman looks rather faint but it it being used at odd sizes (e.g. 17 displayed at 12 point, 12 at 13 point) which probably explains it. It isn't blurry in the same way.

Something about my PDFs...

cfr · 2013-05-25 21:13:41

bohoomil wrote:

cfr wrote:
Also:
$ cat .kde4/share/config/kcmfonts 
[General]
dontChangeAASettings=false
forceFontDPI=96
I'm not sure what this file does. I deleted it earlier but it has reemerged.
It seems like this reflects your KDE settings, I'm afraid… Are you sure you have antialiasing set there?

Positive. Those changes are reflected in ~/.config/fontconfig/fonts.conf as shown above. I have anti-aliasing enabled and force dpi as 96, with the configuration of the anti-aliasing as rgb with full hinting and no exclude range.

I think "dontChangeAASettings" is a toggle for whether KDE interferes with the antialiasing or not. So this says it shouldn't not change them i.e. it should in line with the configuration in ~/.config/fontconfig/fonts.conf. I guess if you say "use system settings', then it would be true and theoretically KDE shouldn't touch them. But it does, as we know, it then puts its own defaults in ~/.config/fontconfig/fonts.conf.

So I think this is right, maybe?

bohoomil · 2013-05-25 22:32:33

The easiest way to make sure how it really works would be changing the option in the control panel and looking up the content of the file again. At the very moment I cannot check native KDE font settings myself, but as far as I can remember disabling them altogether does not imply passing through global fontconfig settings instead. You may try doing it anyway: disable the entire KDE font section, make sure Xft settings (in .Xresources) are loaded while the desktop starts up and check your most critical applications: LO, Okular and FF in this case. If it doesn't work at all or the results are worse than before, you can simply revert everything to the previous state. This is what I did in Xfce--click--which I'm using now instead of dwm (WMs like this are dead simple and won't mess with anything by default, so they are perfectly safe, or even too safe to assume that everything will work equally well in a typical DE).

By the way, did you check Acrobat Reader from the AUR? The results should be completely different due to Adobe's proprietary engine.

Last edited by bohoomil (2013-05-25 22:33:52)

cfr · 2013-05-25 23:05:26

OK. I backed up ~/.config/fontconfig/fonts.conf to ~/.config/fontconfig.dis/fonts.conf.2013-05-25. I then changed the antialias setting in KDE's panel to "disabled". kcmfonts is not changed.

$ diff -Naur fontconfig.dis/fonts.conf.2013-05-25 fontconfig/fonts.conf 
--- fontconfig.dis/fonts.conf.2013-05-25        2013-05-25 01:16:49.345844116 +0100
+++ fontconfig/fonts.conf       2013-05-25 23:50:55.099525284 +0100
@@ -16,10 +16,10 @@
    <const>hintfull</const>
   </edit>
  </match>
+ <dir>~/.fonts</dir>
  <match target="font">
   <edit mode="assign" name="antialias">
-   <bool>true</bool>
+   <bool>false</bool>
   </edit>
  </match>
- <dir>~/.fonts</dir>
 </fontconfig>

I then changed the antialias setting to "System Settings".

$ diff -Naur fontconfig.dis/fonts.conf.2013-05-25 fontconfig/fonts.conf 
--- fontconfig.dis/fonts.conf.2013-05-25        2013-05-25 01:16:49.345844116 +0100
+++ fontconfig/fonts.conf       2013-05-25 23:50:55.099525284 +0100
@@ -16,10 +16,10 @@
    <const>hintfull</const>
   </edit>
  </match>
+ <dir>~/.fonts</dir>
  <match target="font">
   <edit mode="assign" name="antialias">
-   <bool>true</bool>
+   <bool>false</bool>
   </edit>
  </match>
- <dir>~/.fonts</dir>
 </fontconfig>

Moreover, this does change the content of kcmfonts:

$ cat ~/.kde4/share/config/kcmfonts 
[General]
dontChangeAASettings=true
forceFontDPI=96

For some reason, this changed my default font to bold. Who knows why.

If, however, I enable antialiasing, configure it to match fontconfig's defaults, apply that and only then switch to "system settings", then ~/.config/fontconfig/fonts.conf is as desired and kcmfonts is as above. The trouble is that with this setting, we know that ~/.config/fontconfig/fonts.conf will be overwritten by KDE with KDE's preferred defaults and these will then trump the system wide settings, even though the setting in kcmfonts tells KDE not to do this. (I tested this a few days ago - there is discussion earlier in the thread. Before that, I always had KDE set to use "system settings" and not to touch antialiasing or dpi but it did anyway.)

So the safest option seems to be to tell KDE to configure antialiasing but to insist its settings match fontconfig's defaults. Nothing else will preserve the correct settings, it seems. That is, I think what I'm using is the best way to set it up, given KDE's behaviour.

I assume this is a bug in KDE which we are essentially working round.

Last edited by cfr (2013-05-25 23:06:51)

cfr · 2013-05-26 02:36:50

OK. I have no clue why changing KDE settings to something else and then changing them back to what they were originally should make any difference at all but my pdf now looks OK in Okular. At least, it looks pretty much as it did with fontconfig-infinality prior to my switching to the ultimate bundle. I still think there's something about my pdfs because the one bohoomil generated displays Latin Modern significantly more clearly but I do seem to have made some progress even if I have no idea how.

acroread has stopped working for me for some reason but the pdf I was testing looked fine in mupdf.

EDIT: acroread has now decided to work. (I tried it from the command line before - maybe it doesn't like that any more.) Anyway, my pdf is more readable than in Okular but doesn't look as good as in mupdf. Mostly, I think Latin Modern looks kind of faint in Okular but there is something odd about my pdf(s) which shows up in acroread as well as Okular and that is that the font doesn't look very even. I know that small-caps often display slightly oddly (but print fine) but I am not sure about the rest. So the main advantage of acroread is just that it seems to show Latin Modern somewhat darker. Not sure why it should be quite so faint in Okular... (Even the test pdf you sent me has it looking faint on my machine although the text is clear and most of the blurriness has gone from my pdf now Okular has randomly started to behave itself.)

Either I am going completely nuts or gremlins are at work. Or probably both.

Last edited by cfr (2013-05-26 03:04:49)

brebs · 2013-05-26 14:00:55

bohoomil wrote:

The next freetype2-infinality-ultimate release will be available as soon as we have Infinality patches for freetype2 2.4.12

freetype 2.4.12 is working well for me, looking slightly better in general, compared to what I remember. I suggest some git patches too.

Some of Infinality's patches are going upstream - example.

bohoomil · 2013-05-26 14:41:00

Thank you very much -- that's terrific news and great contribution. I will create upgraded freetype2 and fontconfig packages for testing soon.

flipper T · 2013-05-26 16:18:42

Just updating, get following

:: Starting full system upgrade...
error: could not open file /var/lib/pacman/sync/infinality-bundle.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/infinality-bundle.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/infinality-bundle-multilib.db: Unrecognized archive format
error: could not open file /var/lib/pacman/sync/infinality-bundle-multilib.db: Unrecognized archive format

Please help

[edit] refreshed mirrors, error gone.

Last edited by flipper T (2013-05-26 16:26:59)

cfr · 2013-05-27 02:39:35

Thanks to WonderWoofy, I've now got the Windows 7 fonts. (I used the image I have a licence for from DigitalRiver and wimlib.)

(But I'm still using Droid because I like it - especially since the latest updates to infinality.)

Is there any way to get Latin Modern to render better? This isn't a huge deal - I can now more-or-less read it even in Okular and Okular never displayed it well. Just I'm wondering how it can look so much better in mupdf/acroread.

I'm also wondering how something like microtype affects rendering of fonts when PDF created with font expansion etc. are displayed with fontconfig. Or does fontconfig ignore embedded fonts in this sort of case?

bohoomil · 2013-05-27 04:42:34

cfr wrote:

Just I'm wondering how it can look so much better in mupdf/acroread.

The picture is simply rendered by a different engine in a different way. That's why when I need to read longer passages and not only check LaTeX output, I use Acrobat.

Fontconfig won't help much when the font is embedded: poppler can be forced to treat fonts in a certain way, for instant autohint them, apply different subpixel positioning, etc. However, an embedded font is not accessible to fontconfig in the same way anymore. That's why only changes to freetype2 configuration have impact on PDFs. However, adjusting freetype settings so that poppler, GUI and web pages look well at the same time is the other name for nightmare (the first one in the row will always stand out).

One of these days I will make new releases of freetype2 and fontconfig available for testing (thank you again, brebs!). I'm testing them already and several glitches present in freetype2 v. 2.4.11 seem to be gone. I can't tell if you are going to see any difference as far as the LM family is concerned, but it's still worth checking out.

Arch Linux

#276 2013-05-23 13:05:01

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

#277 2013-05-23 21:11:36

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

#278 2013-05-23 21:45:17

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

#279 2013-05-23 22:46:37

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

#280 2013-05-24 21:32:15

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

#281 2013-05-24 22:30:40

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

#282 2013-05-25 00:49:50

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

#283 2013-05-25 01:31:05

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

#284 2013-05-25 02:22:37

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

#285 2013-05-25 02:29:29

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

#286 2013-05-25 02:53:42

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

#287 2013-05-25 03:25:25

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

#288 2013-05-25 03:27:12

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

#289 2013-05-25 03:30:14

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

#290 2013-05-25 03:33:04

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

#291 2013-05-25 03:38:44

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

#292 2013-05-25 21:13:41

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

#293 2013-05-25 22:32:33

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

#294 2013-05-25 23:05:26

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

#295 2013-05-26 02:36:50

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

#296 2013-05-26 14:00:55

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

#297 2013-05-26 14:41:00

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

#298 2013-05-26 16:18:42

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

#299 2013-05-27 02:39:35

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

#300 2013-05-27 04:42:34

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

Board footer