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

cfr · 2013-05-19 22:55:06

I also tried the other backend for Okular. However, I cannot get it to build:

==> Making package: okular-backend-mupdf 0.0.1-1 (Sul 19 Mai 23:51:22 BST 2013)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found okular-backend-mupdf.patch
==> Validating source files with md5sums...
    okular-backend-mupdf.patch ... Passed
==> Extracting sources...
==> Starting build()...
A    mupdf
A    mupdf/Messages.sh
A    mupdf/cmake
A    mupdf/cmake/modules
A    mupdf/cmake/modules/Findjbig2dec.cmake
A    mupdf/cmake/modules/FindLIBOPENJPEG.cmake
A    mupdf/get-mupdf.sh
A    mupdf/okularMupdf.desktop
A    mupdf/qmupdf_p.h
A    mupdf/generator_mupdf.cpp
A    mupdf/qmupdf.h
A    mupdf/okularApplication_mupdf.desktop
A    mupdf/CMakeLists-fitz.txt
A    mupdf/generator_mupdf.h
A    mupdf/CMakeLists.txt
A    mupdf/qmupdf.cpp
A    mupdf/libokularGenerator_mupdf.desktop
Exported revision 1355483.
Cloning into 'mupdf'...
remote: Counting objects: 24412, done.
remote: Compressing objects: 100% (11795/11795), done.
remote: Total 24412 (delta 18796), reused 15471 (delta 12008)
Receiving objects: 100% (24412/24412), 12.81 MiB | 316 KiB/s, done.
Resolving deltas: 100% (18796/18796), done.
patching file CMakeLists-fitz.txt
patching file get-mupdf.sh
patching file qmupdf.cpp
-- The C compiler identification is GNU 4.8.0
-- The CXX compiler identification is GNU 4.8.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found
-- Found Qt-Version 4.8.4 (using /usr/bin/qmake-qt4)
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libXft.so;/usr/lib64/libXau.so;/usr/lib64/libXdmcp.so;/usr/lib64/libXpm.so
-- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so;/usr/lib64/libXft.so;/usr/lib64/libXau.so;/usr/lib64/libXdmcp.so;/usr/lib64/libXpm.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib64/libX11.so
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found OpenSSL: /usr/lib64/libssl.so;/usr/lib64/libcrypto.so (found version "1.0.1e") 
-- Looking for _POSIX_TIMERS
-- Looking for _POSIX_TIMERS - found
-- Found Automoc4: /usr/bin/automoc4  
-- Found Perl: /usr/bin/perl (found version "5.16.3") 
-- Found Phonon: /usr/include/qt4 (Required is at least version "4.3.80") 
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Performing Test HAVE_FPIE_SUPPORT
-- Performing Test HAVE_FPIE_SUPPORT - Success
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL
-- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success
-- Performing Test __KDE_HAVE_GCC_VISIBILITY
-- Performing Test __KDE_HAVE_GCC_VISIBILITY - Success
-- Found KDE 4.10 include dir: /usr/include
-- Found KDE 4.10 library dir: /usr/lib
-- Found the KDE4 kconfig_compiler preprocessor: /usr/bin/kconfig_compiler
-- Found automoc4: /usr/bin/automoc4
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.8") 
-- Found Freetype: /usr/lib64/libfreetype.so (found version "2.4.11") 
-- Found JPEG: /usr/lib64/libjpeg.so  
-- Could NOT find LibOpenJPEG (missing:  LIBOPENJPEG_INCLUDE_DIR) 
-- Found jbig2dec: /usr/lib64/libjbig2dec.so  
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LIBOPENJPEG_INCLUDE_DIR
   used as include directory in directory /home/software/builds/okular-backend-mupdf/src/mupdf/mupdf
   used as include directory in directory /home/software/builds/okular-backend-mupdf/src/mupdf/mupdf
   used as include directory in directory /home/software/builds/okular-backend-mupdf/src/mupdf/mupdf
   used as include directory in directory /home/software/builds/okular-backend-mupdf/src/mupdf/mupdf

-- Configuring incomplete, errors occurred!
==> ERROR: A failure occurred in build().
    Aborting...

Anybody else have better luck?

bohoomil · 2013-05-19 23:47:43

For now, just two quick screenshots:

1. KDE desktop with infinality + system settings in control panel: click.
2. FF in KDE with custom settings enabled (no tweaks, just raw Arimo / Tinos / Cousine): click.

Xft settings are changed when you don't load the correct ones at KDE startup. Just source a custom .Xresources via 'Startup applications' and you should be fine.
Besides, it gets reverted to medium hinting because this is the default value when you don't set a custom one. So -- in your control panel, set hintfull, rgb, 96 dpi. Without it FF looks like… Well, you know like what. Should help, IMO.

The rest is coming soon.

Last edited by bohoomil (2013-05-19 23:59:38)

cfr · 2013-05-20 22:57:19

OK. So I removed the immutable ~/.config/fontconfig/fonts.conf and set KDE font settings to "enabled" (rgb, full hinting, antialias) with force dpi 96. I also set things up so it seems to be sourcing ~/.Xresources.

$ 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>
</fontconfig>

$ xrdb -q | grep Xft
Xft.antialias:  1
Xft.autohint:   0
Xft.dpi:        96
Xft.hinting:    1
Xft.hintstyle:  hintfull
Xft.lcdfilter:  lcddefault
Xft.rgba:       rgb

And I rebooted.

Firefox seems definitely improved - thanks! Though my blog still isn't as legible as before I switched. But it is now fairly easily readable which is the main thing. It does not seem to have helped with Okular at all and that's currently my main concern, I guess. Maybe it is the particular font because Latin Modern has some thinner aspects and the new settings make these fade into almost nothing...? Or it is a bit blurrier?

I did install wimlib as WonderWoofy suggested but cannot figure out what to do with it yet. In any case, I don't think that would affect the rendering of Latin Modern in Okular. (Least I hope not!)

WonderWoofy · 2013-05-21 01:00:22

Wimlib is just something that you can use to extract the font files from a windows installer. This will enable you to build such packages as the ttf-win7-fonts and ttf-ms-win8 packages. You can download free keyless legal copies of windows from their digitalriver host.

cfr · 2013-05-21 01:11:07

WonderWoofy wrote:

Wimlib is just something that you can use to extract the font files from a windows installer. This will enable you to build such packages as the ttf-win7-fonts and ttf-ms-win8 packages. You can download free keyless legal copies of windows from their digitalriver host.

OK. Thanks. I didn't know you could do that. (I know literally nothing about Windows so when it seemed to need a Windows image, I assumed I was missing something. Last time I had Windows, it was on floppy disks.)

Current screenshot of Okular at At least, I hope. Either Arch went down or something I need to get to Arch went down and I couldn't finish posting the image. As (I hope) you can see, the fonts in the UI look great but the rendering of the PDF does not.

For the historical record, here is ff before bohoomil's instructions:
And here is Okular: (This looks very much to me like it does now but ff looks nothing like, thanks to the KDE adaptions.)

Last edited by cfr (2013-05-21 01:11:48)

keepitsimpleengineer · 2013-05-21 15:37:17

keepitsimpleengineer wrote:

[SOLVED]
hokasch wrote:
Do you have lib32-cairo-infinality-ultimate installed?
Yikes!
Even though I (thought I) installed it yesterday, I decided to re-install. Discovered it was not installed, and after installation, arcoread now works.
Thanks

Discovered the problem here. While lib32-cairo-infinality-ultimate was being "installed" (screen0), I opened a new Terminal Emulator on screen1. Due to a bug (report now filed) in Terminal Emulator, all Terminal Emulator sessions running on screen0 were instantly killed.

jakobcreutzfeldt · 2013-05-21 17:54:15

[I'm not sure where else to put this but since it's relevant to recent discussions, I think it's appropriate here but mods feel free to move it.]

OK, the poor PDF rendering problem in GNU/Linux has been irritating me so I've been looking into it, focusing mainly on poppler. I've gotten things to be significantly improved by forcing it to use slight hinting (normally it forces no hinting and I've read that anything more than slight hinting causes problems in PDFs). This removes all of the blurriness that I see in most PDFs (not all...ones generated by libreoffice still seem messed up).

[a comparison of mupdf (left) and evince using the patched poppler (right)]

Here's the patch. Give it a try. It might make a good AUR candidate.

edit: patch removed. see my later post

(note: see this ancient bug report: https://bugs.launchpad.net/ubuntu/+sour … +bug/80921)

In the end, the fonts are just jagged from apparently not being antialiased. I've tried patching the Evince code to force sub-pixel antialiasing (I'm not sure where to add it in the poppler code) but it didn't have any apparent effect. Poppler doesn't have antialiasing set anywhere in the code, so one would hope that with the infinality-bundle of Cairo, it should respect fontconfig settings but apparently it isn't. Anyone have any ideas?

edit: to the typography nerds, you may not want this patch since using hinting on PDFs implies that you no longer get a faithful recreation of what a printout might look like, since it's snapping pixels to new locations.

Last edited by jakobcreutzfeldt (2013-05-24 07:16:43)

bohoomil · 2013-05-21 19:28:40

@keepitsimpleengineer & @jakobcreutzfeldt: thank you so much for examining the problems! I will certainly build poppler with the patch. Of course, any skillful hacking here is most welcome: it would be really great if we could improve those lousy PDFs…

As for more regular improvements: today in the morning my head wrongly instructed my hands to remove the most recent (and greatly polished) copy of conf.avail.infinality that only at night I finished working on. That's unfortunately one of the many side effects of my medicine, frustrating and tedious. So, instead of packaging and signing, I had to act in my private 'Groundhog Day', which included recreating configuration in its current state and testing the rendering of +400 fonts… Oh well… On the other hand, the results look very well in my opinion (many bugs have been fixed, numerous fonts should render even better -- that includes mainly zh / jap scripts). Of course, now the fresh new commit is already where it should be. For all brave hearts: you can clone the branch and manually replace the content of your /etc/fonts/conf.avail.infinality. All the files in the repository should be re-linked in /etc/fonts/conf.d and only those, so in the end contents of both directories are the same. Later on a few optional configuration files will be added, but those should remain only available in /etc/fonts/conf.avail.infinality. If you'd rather wait, the updated packages will be available soon.

Thank you for using, following and supporting!

jakobcreutzfeldt · 2013-05-21 21:18:58

OK here's a patch to force subpixel antialiasing in Poppler (original source)

edit: patch removed. see my later post

I'm undecided on how good the results are on this (my laptop has a much higher pixel density than my work monitor, so it's hard to judge). The slight hinting greatly improves contrast but it introduces problems at small font sizes. The antialiasing is there but, for lack of a good way of describing it, it's not great. I'm going to withold judgment until I see it at work. It seems that the improvements are really only for lower-resolution monitors.

So, the patch combo overall feels like a slight improvement but it carries its own annoyances. Has anyone else given it a try?

@bohoomil: with the infinality-bundle version of cairo, do you know how fontconfig settings interract with the internal Cairo settings? I haven't looked at the Cairo code at all. What I mean is, if we force Poppler to use subpixel antialiasing via Cairo settings, as in this patch, does it pass the antialiasing work off to fontconfig or does it use its own algorithms? The same goes for hinting. I'm wondering if, even though these patches turn on hinting and subpixel AA, they're not being influenced by the infinality settings, which would be a shame.

Last edited by jakobcreutzfeldt (2013-05-23 12:11:40)

bohoomil · 2013-05-21 22:26:25

jakobcreutzfeldt wrote:

with the infinality-bundle version of cairo, do you know how fontconfig settings interract with the internal Cairo settings?

Cairo is supposed to use fontconfig settings, and as far as I can tell, it does. It's basically cairo-ubuntu from the AUR so the behaviour of both packages should be (almost) identical.

Thanks for the second patch. I'm currently experimenting with various values of CAIRO_ANTIALIAS. As far as I know, the SUBPIXEL requires SUBPIXEL_ORDER to be set as well (RGB in our case would be correct I guess).

Last edited by bohoomil (2013-05-21 22:34:57)

cfr · 2013-05-21 22:37:21

Although I cannot build the mupdf backend for Okular from AUR, I did try mupdf itself and the same pdf looks loads better in mupdf. It looks awful in zathura which is using poppler. So poppler definitely seems to be doing something poorly.

What I don't understand is why the same pdf looks any worse with the new infinality bundle than it did before given that it apparently ignores fontconfig settings (according to the above).

bohoomil · 2013-05-21 23:43:57

cfr wrote:

What I don't understand is why the same pdf looks any worse with the new infinality bundle […]

Perform the following:

sed 's/append/assign/' -i /etc/fonts/conf.d/10-base-rendering.conf

and see what happens then.

cfr · 2013-05-22 01:37:13

Is there a way to get the new config used without rebooting/restarting X? I looked in the wiki page because usually pages tell you what to do after tweaking configurations but I couldn't see anything relevant.

(I restarted the application but I'm assuming that's not enough.)

pablox · 2013-05-22 02:02:37

cfr wrote:

Is there a way to get the new config used without rebooting/restarting X? I looked in the wiki page because usually pages tell you what to do after tweaking configurations but I couldn't see anything relevant.
(I restarted the application but I'm assuming that's not enough.)

Which kind of config? Font configuration (aliases, replacements, ecc) can be made after restarting the app, the other ones, I believe the only way it's restarting x.

bohoomil · 2013-05-22 02:12:48

@cfr, if you mean applying the one-liner above, no reboot is necessary.

jakobcreutzfeldt · 2013-05-22 11:02:37

I updated the two poppler patches in my original post to be the most technically correct. The end result still isn't great though. I give up.

wilfriedd · 2013-05-22 13:16:48

@bohoomil:

I took a look at your new configuration files, and in general they look good, most of my previous remarks have been resolved.
The only thing that's still a bit confusing for me is the non-tt fonts rendering options.

Right now you have 2 files: 89-non-tt-rendering.conf and 90-non-tt-fonts.conf. The 89-non-tt-rendering.conf file looks for a font-type (NON TT Instructed Font) that's only assigned later in the 90-non-tt-fonts.conf. So this match can never happen.
However, I see you do set some rendering options at the end of 90-non-tt-fonts.conf.

I can imagine 2 possible explanations:
1) The rendering options in 89-non-tt-rendering.conf are the correct ones. In this case you should remove the redundant rendering options from the end of 90-non-tt-fonts.conf and place the 89-non-tt-rendering.conf file after 90-non-tt-fonts.conf in order for them to apply correctly
2) The rendering options in 89-non-tt-rendering are redundant. In this case, just remove that file as it is never applied anyway as is.

bohoomil · 2013-05-22 17:32:48

@wilfriedd, I know about 89-*.conf and I left it there on purpose just because it does nothing (it would remain only in avail directory, without a symlink in conf.d -- the git repo reflects the avail directory after all). I simply haven't decided whether or not I should leave an option to control 'qt_use_subpixel_positioning'. If I do, 82-{no|yes}-qt-subpixel-positioning.conf, 89-non-tt-rendering.conf & 90-non-tt-fonts.conf will have to be reordered anyway to have an effect (89-{no|yes}-qt-subpixel-positioning.conf => 88-non-tt-fonts.conf sans rendering options at the bottom of the list => 87-non-tt-rendering.conf). For now, I'm inclined to use the simpler solution by default since the number of cases when an additional parameter could be handy seems marginal.

@jakobcreutzfeldt, apply this line and check the PDF rendering again.

cfr · 2013-05-23 00:07:28

bohoomil wrote:

@cfr, if you mean applying the one-liner above, no reboot is necessary.

I did. If restarting the app should be enough, the change doesn't seem to have made any difference.

I also noticed that bold numerals from Droid Serif don't render correctly in LibreOffice any longer. They used to look fine in Arch (and they still look fine with Fedora's default configuration). Incidentally, I checked Latin Modern in Okular on Fedora as well and it isn't great but it is reasonably legible. (Similar to how it looked on Arch before I upgraded to the new bundle. However, I am not running Arch and Fedora on the same system so, apart from anything else, the monitor is completely different. Hence not a fair comparison.)

My current impression is that with your bundle, some of my fonts now look really nice but some are poor enough to be difficult to read.

bohoomil · 2013-05-23 01:26:22

I think it's time I summed up all the changes before the updated and signed packages are made available.

1. Poppler & PDF issues.

Having tested the patches and consulted freetype and cairo documentations, I realized that all the patches were supposed to do was duplicate fontconfig rules as found in /etc/fonts/conf.d/10-base-rendering.conf. This can be easily done without applying any patch to poppler: it's enough to make fontconfig assign the basic rules instead of appending them. The rendering of PDF files (incl. embedded fonts) should improve because poppler will no longer force it's own, hard coded defaults which override fontconfig settings (appended only, thus giving the application's instructions a higher priority over what was globally set as default).

In order to minimize a possible impact on DEs' native font settings, it should be enough to duplicate the values set in 10-base-rendering.conf in a corresponding place in a DE's control panel: This is how things were done in the git version of fontconfig-ultimate.

Just for the record, a few screenshots of Okular running under the modified configuration:

embedded fonts #1: click
embedded fonts #2: click
a web page converted to a PDF file: click

The quality still cries for poppler hacks, but if compared with the previous configuration, it seems acceptable.

2. Fontconfig rules priorities.

I reworked the hierarchy in /etc/fonts/conf.d as advised by wilfriedd. The modification should prevent TTF fonts from being accidentally autohinted or applied inconsistent set of rules, which makes this fix work in a less evident way at first glance (and often at second, too). However, this is an important change since it strengthens the way presets are applied, leaving fontconfig less freedom to arbitraty treat a particular font family.

3. As discussed earlier in this thread, bitmap fonts are again accessible by default. Enabling and disabling particular features was made more intuitive (82-no-foo.conf & 83-yes-foo.conf). However, in the final release the optional switches will be duplicated in /usr/share/doc/fontconfig-infinality-ultimate/fontconfig, meaning that in most cases it should be enough to activate them on a per-user basis.

4. The rendering of the following fonts was tweaked:

Avenir Next, DejaVu Sans (thinish 's' in Extralight variant and above 25px in the Light one), FangSong, Gulim / Dotum, KaiTi, Lucida Sans Typewriter, Meiryo, Microsoft Yi Baiti, MingLiU / PMingLiU, MS Gothic / PGothic / UI Gothic, Open Sans, SimSun / SimHei, Trebuchet MS, Ubuntu & @font-face:Ubuntu, and a few more.

5. The content of /etc/fonts directories.

Templates in conf.avail.infinality:

10-base-rendering.conf         82-no-postscript.conf
31-fix-cantarell.conf          82-no-ttf-as-bitmap.conf
35-droid-sans-group.conf       83-yes-bitmaps.conf
35-droid-serif-group.conf      83-yes-embedded-bitmaps.conf
37-repl-global.conf            83-yes-force-autohint.conf
38-repl-tt-traced-bitmap.conf  83-yes-postscript.conf
39-repl-corrective.conf        83-yes-ttf-as-bitmap.conf
40-nonlatin.conf               88-forced-synthetic.conf
45-latin.conf                  89-non-tt-rendering-qt.conf
49-sansserif.conf              90-non-tt-fonts.conf
50-user.conf                   90-non-tt-fonts-qt.conf
51-local.conf                  90-tt-fonts.conf
60-latin.conf                  91-no-qt-subpixel-positioning.conf
65-non-latin.conf              92-selective-rendering.conf
66-aliases-wine.conf           93-final-lang-spec.conf
68-override.conf               93-final-rendering.conf
82-no-bitmaps.conf             94-no-synthetic.conf
82-no-embedded-bitmaps.conf    95-reject.conf
82-no-force-autohint.conf

Symlinks in conf.d:

10-base-rendering.conf         68-override.conf
31-fix-cantarell.conf          82-no-embedded-bitmaps.conf
35-droid-sans-group.conf       82-no-force-autohint.conf
35-droid-serif-group.conf      82-no-ttf-as-bitmap.conf
37-repl-global.conf            83-yes-bitmaps.conf
38-repl-tt-traced-bitmap.conf  83-yes-postscript.conf
39-repl-corrective.conf        88-forced-synthetic.conf
40-nonlatin.conf               90-non-tt-fonts.conf
45-latin.conf                  90-tt-fonts.conf
49-sansserif.conf              92-selective-rendering.conf
50-user.conf                   93-final-lang-spec.conf
51-local.conf                  93-final-rendering.conf
60-latin.conf                  94-no-synthetic.conf
65-non-latin.conf              95-reject.conf
66-aliases-wine.conf           README

6. It may be necessary to manually replace the freetype2 runtime file with /etc/profile.d/infinality-settings.sh.pacnew.

7. Signature.

The typical sequence should do:

a. Remove 'SigLevel = Never' from the repo address in your pacman.conf.

b. Import and sign the key:

# pacman-key -r 962DDE58
# pacman-key --lsign-key 962DDE58

8. The packages are available for testing in a D*box. When no major issues come to light, they will be available in the repository soon.

Thanks.

@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…

WonderWoofy · 2013-05-23 01:56:29

Things look good to me with the update

wilfriedd · 2013-05-23 09:35:59

Same here, the new packages are looking good to me

Perfect Gentleman · 2013-05-23 12:00:00

installed packages from D*box. It's okay for me.

Last edited by Perfect Gentleman (2013-05-23 12:01:32)

jakobcreutzfeldt · 2013-05-23 12:02:37

@bohoomil - sounds great!

So, I didn't give up on Poppler and I have gotten some great results. I've re-written the two patches. I find that this combo is the best:

--- poppler-0.22.3/poppler/CairoFontEngine.cc	2013-02-20 21:09:05.000000000 +0100
+++ poppler-0.22.3/poppler/CairoFontEngine.cc.new	2013-05-22 12:50:43.768141180 +0200
@@ -182,7 +182,7 @@
   }
 
   font_face = cairo_ft_font_face_create_for_ft_face (face,
-							  FT_LOAD_NO_HINTING |
+							  FT_LOAD_NO_AUTOHINT |
 							  FT_LOAD_NO_BITMAP);
   if (cairo_font_face_set_user_data (font_face,
 				     &_ft_cairo_key,
@@ -345,7 +345,7 @@
   _ft_open_faces = l;
 
   l->font_face = cairo_ft_font_face_create_for_ft_face (tmpl.face,
-							  FT_LOAD_NO_HINTING |
+							  FT_LOAD_NO_AUTOHINT |
 							  FT_LOAD_NO_BITMAP);
   if (cairo_font_face_set_user_data (l->font_face,
 				     &_ft_cairo_key,

--- poppler-0.22.3/poppler/CairoOutputDev.cc	2013-04-11 23:20:32.000000000 +0200
+++ poppler-0.22.3/poppler/CairoOutputDev.cc.new	2013-05-21 23:03:30.373835491 +0200
@@ -198,6 +198,16 @@
   }
   if (cairo != NULL) {
     this->cairo = cairo_reference (cairo);
+    {
+    cairo_font_options_t *options = cairo_font_options_create ();
+    cairo_get_font_options (cairo, options);
+    cairo_font_options_set_antialias (options, CAIRO_ANTIALIAS_SUBPIXEL);
+    cairo_font_options_set_subpixel_order (options, CAIRO_SUBPIXEL_ORDER_DEFAULT);
+    cairo_font_options_set_hint_style (options, CAIRO_HINT_STYLE_SLIGHT);
+    cairo_font_options_set_hint_metrics (options, CAIRO_HINT_METRICS_ON);
+    cairo_set_font_options (cairo, options);
+    cairo_font_options_destroy (options);
+    }
 	/* save the initial matrix so that we can use it for type3 fonts. */
 	//XXX: is this sufficient? could we miss changes to the matrix somehow?
 	cairo_get_matrix(cairo, &orig_matrix);

I've also found that Evince is somehow ignoring subpixel antialiasing and is instead defaulting to gray AA. When I look at epdfview (which is what I used at home when I previously said that subpixel AA was working), I can see a huge difference.

[comparison of epdfview with (left) and without (right) the Poppler patches]
[comparison of evince (left) and epdfview (right), both with the Poppler patches]
[close-up comparison of evince (left) and epdfview (right), both with the Poppler patches]
(notice on the italicized letters you can easily see the RGB subpixel AA in epdfview but not in evince, which seems to be forcing gray AA)

These screenshots are after implementing the 10-base-rendering.conf tweak that bohoomil specified before. Also, unlike what I previously said, these updated patches appear to work for all PDFs, including those generated by LibreOffice.

Users of Okular may need patches 0001 and 0002 here to make sure that Okular is using Cairo as the Poppler backend and not Splash. I'm not sure though because I don't use it. Those patches probably need updating; I think he's a couple of versions behind us.

Last edited by jakobcreutzfeldt (2013-05-23 12:18:38)

bohoomil · 2013-05-23 12:14:07

@jakobcreutzfeldt, I am not sure what I should say, but the shots look amazing. Simply. Wow. I will check the patches out on my private ground, but it seems like there's something really nice being cooked.

OK, testing and tweaking.

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. )

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.

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!

Last edited by bohoomil (2013-05-23 12:50:39)

Arch Linux

#251 2013-05-19 22:55:06

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

#252 2013-05-19 23:47:43

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

#253 2013-05-20 22:57:19

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

#254 2013-05-21 01:00:22

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

#255 2013-05-21 01:11:07

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

#256 2013-05-21 15:37:17

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

#257 2013-05-21 17:54:15

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

#258 2013-05-21 19:28:40

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

#259 2013-05-21 21:18:58

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

#260 2013-05-21 22:26:25

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

#261 2013-05-21 22:37:21

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

#262 2013-05-21 23:43:57

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

#263 2013-05-22 01:37:13

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

#264 2013-05-22 02:02:37

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

#265 2013-05-22 02:12:48

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

#266 2013-05-22 11:02:37

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

#267 2013-05-22 13:16:48

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

#268 2013-05-22 17:32:48

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

#269 2013-05-23 00:07:28

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

#270 2013-05-23 01:26:22

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

#271 2013-05-23 01:56:29

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

#272 2013-05-23 09:35:59

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

#273 2013-05-23 12:00:00

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

#274 2013-05-23 12:02:37

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

#275 2013-05-23 12:14:07

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

Board footer