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

zainin · 2014-09-14 19:16:04

The problem is I can't really tell you much. The fonts are embedded in *mkv (think anime stylized subtitles) - is there any way to tell what fonts were used?
The debug messages don't say anything useful. As soon as a certain font is used mpv segfaults without any warnings.

EDIT: Apparently you can check what fonts were used with mediainfo. The file is called PAINP__.TTF and looks like this. Here's a link to a TTF file if that helps.

EDIT 2: Tried with updated freetype2 packages. No change.

Last edited by zainin (2014-09-15 17:54:11)

Zanshi · 2014-09-17 19:03:04

@zainin

I'm having an issue really similar to yours. mpv crashes when watching videos with heavy use of embedded .ass fonts. I've tried using the mpv package in the community repo as well as the mpv-build-git package in the AUR. I've also tried both libass and libass-git.
mpv crashes with everything. I'm using infinality-bundle, infinality-bundle-multilib, ibfonts-meta-base and ibfonts-meta-extended.

It works just fine with the regular fontconfig packages.

Error log from playing a file that causes a crash:

[statusline] AV: 00:00:24 / 00:22:54 (1%) A-V:  0.000 Cache:  2s+37058KB
[libass] fontconfig: cannot find font 'Franklin Gothic Book', falling back to 'Noto Sans'
[statusline] AV: 00:00:32 / 00:22:54 (2%) A-V:  0.000 Cache:  2s+33553KB
[libass] Glyph bounding box too large: 33554442x33554454px
[libass] Glyph bounding box too large: 33554445x33554457px
[libass] Glyph bounding box too large: 47453143x47453125px
[libass] Glyph bounding box too large: 33554445x33554457px
[libass] Glyph bounding box too large: 47453142x47453125px
[libass] Glyph bounding box too large: 47453143x47453125px
[libass] Glyph bounding box too large: 47453142x47453125px
[libass] Glyph bounding box too large: 33554445x33554457px
[libass] Glyph bounding box too large: 33554448x34px
[libass] Glyph bounding box too large: 47453142x47453125px
[libass] Glyph bounding box too large: 33554443x33554454px
[libass] Glyph bounding box too large: 33554448x33554450px
[libass] Glyph bounding box too large: 47453143x47453124px
[libass] Glyph bounding box too large: 33554438x35px
[libass] Glyph bounding box too large: 33x33554441px
[libass] Glyph bounding box too large: 33554449x35px
[statusline] AV: 00:00:38 / 00:22:54 (2%) A-V:  0.000 Cache:  2s+26458KB
[libass] Glyph bounding box too large: 33554445x33554457px
[libass] Glyph bounding box too large: 33554443x33554454px
[libass] Glyph bounding box too large: 47453143x47453125px
[libass] Glyph bounding box too large: 33554448x35px
[libass] Glyph bounding box too large: 33554445x35px
[libass] Glyph bounding box too large: 33554443x33554454px
[libass] Glyph bounding box too large: 47453142x47453124px
[libass] Glyph bounding box too large: 33554442x33554454px
[libass] Glyph bounding box too large: 33554448x35px
[libass] Glyph bounding box too large: 33554448x33554440px
[libass] Glyph bounding box too large: 33554443x33554454px
[statusline] AV: 00:00:42 / 00:22:54 (3%) A-V: -0.001 Cache:  2s+21669KB
[libass] Glyph bounding box too large: 33554440x33px
[libass] Glyph bounding box too large: 32x33554441px
mpv: ass_rasterizer.c:430: segment_split_horz: Assertion `x > line->x_min && x < line->x_max' failed.
[1]    18800 abort (core dumped)  mpv -v

$ env | grep -i infinality

INFINALITY_FT_FRINGE_FILTER_STRENGTH=50
INFINALITY_FT_USE_VARIOUS_TWEAKS=false
INFINALITY_FT_FILTER_PARAMS=10 25 37 25 10

$ xrdb -q | grep Xft

Xft.antialias:	1
Xft.hinting:	1
Xft.hintstyle:	hintfull
Xft.rgba:	rgb
Xft.dpi:	96

bohoomil · 2014-09-17 20:48:26

@Zanshi Thank you for the additional info.

By this:

It works just fine with the regular fontconfig packages.

-- do you mean that freetype2-infinality-ultimate works properly with the stock fontconfig? Do you suspect fontconfig-infinality-ultimate (not freetype2-infinality-ultimate) to be responsible for mpv crashing?

Zanshi · 2014-09-17 21:43:46

Thanks for looking into the issue bohoomil!

No, sorry, it does indeed seem like freetype2-infinality-ultimate is responsible. Using either the regular or the infinality versions of fontconfig and cairo together with freetype2-infinality-ultimate causes mpv to crash too.

goddesse · 2014-09-18 09:13:04

Zanshi or zainin, can either of you pm me a pointer to a particular mkv that causes the issue?

goddesse · 2014-09-20 07:00:12

From what I can tell, mpv/libass crashes with any recent version of freetype2-git on the affected files. Can Zanshi or zainin test a non-infinality version of freetype2-git to confirm?

Zanshi · 2014-09-20 10:10:05

goddesse wrote:

From what I can tell, mpv/libass crashes with any recent version of freetype2-git on the affected files. Can Zanshi or zainin test a non-infinality version of freetype2-git to confirm?

Interesting! Just tried with freetype2-git from the AUR and mpv/libass crashes with this version too.

zainin · 2014-09-20 11:44:04

I can confirm as well. Segfaults with freetype2-git.

goddesse · 2014-09-20 18:20:29

If you want, here's 03-aflatin.c.patch which has been modified to run on the stable release of freetype 2.5.3 which is the only file in the patchset that doesn't cleanly compile on stable 2.5.3 freetype: http://pastebin.com/bBHKpueW

I don't get crashing when using the infinality patchset the stable freetype and AFAICT, it has nothing to do with anything freetype-infinality does. I think this is a bug with mpv/libass and probably needs to be raised with mpv.

bohoomil · 2014-09-20 18:25:47

Thanks, @goddesse. I will rebuild freetype2-iu soon, too.

bohoomil · 2014-09-20 21:08:47

I think we'll just wait for libass to be fixed instead of getting back to the stock freetype2 2.5.3 with Infinality patchset, which I tried doing for testing purposes. Since the last version upgrade, freetype2 has been significantly improved by the upstream so downgrading it wouldn't be a good (temporary) solution, IMO. As @zainin's workaround is usable and the problem isn't really freetype2/Infinality related, let's stick with it for a while. I hope libass developers will eventually update the code properly.

orschiro · 2014-09-27 09:31:07

@bohoomil

Can you reproduce the following rendering issue on the site http://beta.download.cyanogenmod.org/install?

On Firefox this page looks like this: http://i.imgur.com/ab6uItI.jpg

On Chromium, however, it renders nicely.

bohoomil · 2014-09-27 16:59:05

@orschiro That's how FF happens to interpret CSS font weights. To fix the issue, we can try and force fontconfig to assign CSS font weights to respective fontconfig values (i.e. 300 = 50, 400 = 80, etc.).

Just install (or update) `ttf-lato-ibx`to v.2.007-7 and remove the following entry from your `37-repl-global-foo.conf`:

  <match target="font">
    <test name="family">
      <string>@font-face:Lato</string>
    </test>
    <edit name="family" mode="assign">
      <string>Lato</string>
    </edit>
  </match>
  <match target="pattern">
    <test name="family">
      <string>@font-face:Lato</string>
    </test>
    <edit name="family" mode="prepend" binding="strong">
      <string>Lato</string>
    </edit>
  </match>

Now FF should use correct font weights with Lato.

Edit 1 I will try and create a fontconfig rule that will do this automatically for all font families when necessary.

Edit 2 There was a little glitch in the 37-repl-lato.conf -- now it's correct.

The way Lato Light is rendered in FF is correct. The problem is--as always--that Webkit and Gecko interpret weights a bit differently. Besides, Firefox will do better with a local copy of the font: it should actually work well with the rule above, but the more detailed new one won't hurt (it should actually provide a more consistent translation). You can prove it's working by setting the <int>50</int> value (which means 'weight=light') to any supported by fontconfig (see `man fonts-conf` for details).

Edit 3 And now it should be really OK in all web browsers. I fixed wrong weight values in Lato Thin (was: 275, should be: 200) and Lato Hairline (was: 250, should be: 100). Without it, all three (i.e. Light, Thin and Hairline) were recognized as Light (i.e. 300, which translates into 50 in fontconfig's values).

Last edited by bohoomil (2014-09-28 02:04:04)

logos88 · 2014-09-27 17:19:23

What is the difference between croscore fonts and liberation fonts? which one are better to replace Arial and Times new Roman?

bohoomil · 2014-09-27 20:43:16

@logos88 IMO both will do just fine. I decided to stick with `ttf-liberation-ib` as the default package (hence it belongs to the base group in the ib-fonts repository) because I didn't notice any significant differences in quality in favour of the Google family. All in all -- get the default.

logos88 · 2014-09-28 16:34:18

Oks. I read that the Google family were better because are a newer version of the liberation family made by the same designer, but I really couldn't find any differences in a first view, so I'll make as you say and stay in the default. Thanks!

orschiro · 2014-09-29 14:35:10

bohoomil wrote:

Edit 3 And now it should be really OK in all web browsers. I fixed wrong weight values in Lato Thin (was: 275, should be: 200) and Lato Hairline (was: 250, should be: 100). Without it, all three (i.e. Light, Thin and Hairline) were recognized as Light (i.e. 300, which translates into 50 in fontconfig's values).

Thank you! Does your third edit mean that the fix is now applied by the package itself and I do not need to remove the lines in 37-repl-global-foo.conf?

bohoomil · 2014-09-29 21:50:06

Yes, exactly. The former replacement rule in `37-repl-global-foo.conf` is all we should need with the fixed Lato. The newly uploaded ttf-lato-ibx, rev. 2.007-10, doesn't need any additional fontconfig settings but those we've been using by default so far.

Last edited by bohoomil (2014-09-29 21:50:28)

aphirst · 2014-10-01 09:41:26

Zanshi wrote:

@zainin
I'm having an issue really similar to yours. mpv crashes when watching videos with heavy use of embedded .ass fonts. I've tried using the mpv package in the community repo as well as the mpv-build-git package in the AUR. I've also tried both libass and libass-git.
mpv crashes with everything. I'm using infinality-bundle, infinality-bundle-multilib, ibfonts-meta-base and ibfonts-meta-extended.
It works just fine with the regular fontconfig packages.
Error log from playing a file that causes a crash:
[statusline] AV: 00:00:24 / 00:22:54 (1%) A-V:  0.000 Cache:  2s+37058KB
[libass] fontconfig: cannot find font 'Franklin Gothic Book', falling back to 'Noto Sans'
[statusline] AV: 00:00:32 / 00:22:54 (2%) A-V:  0.000 Cache:  2s+33553KB
[libass] Glyph bounding box too large: 33554442x33554454px
[libass] Glyph bounding box too large: 33554445x33554457px

I am experiencing similar behaviour to Zanshi regarding libass, except rather than crashing, mpv+libass-git simply mis-renders some characters, and printing the same sort of 'glyph bounding box too large' errors. An affected file can be found here, with a screenshot demonstrating the error here. A verbose mpv log can be found here.

I'm using:

freetype2-infinality-ultimate 2.5.3-12
fontconfig-infinality-ultimate 2.11.1-20
libass-git 0.11.2.37.gcad1cae-1
mpv 0.5.4-1

Since this only occurred in freetype2-infinality -10 and later according to some people in Freenode #libass (I myself simply didn't encounter any affected files until after I upgraded, presumably just by coincidence), I am led to believe that the underlying issue here is with infinality; but obviously I do not know for sure.

Last edited by aphirst (2014-10-01 09:44:33)

jamtat · 2014-10-01 18:08:18

Even though I don't understand very well what infinality-bundle is or does, I decided to try it, since the fonts in my cobbled-together desktop enironment (using jwm) looked pretty terrible. I must say the results were pretty impressive. But recently I began to see errors when I would do pacman -Syu relating to this package. Now I'm getting other errors, namely I got today

error: could not open file /var/lib/pacman/sync/infinality-bundle.db: Unrecognized archive format

and, on a later attempt

error: failed retrieving file 'infinality-bundle.db.sig' from ibn.net63.net : Maximum file size exceeded

What could be going on here?

AFTERTHOUGHT: I'm beginning to wonder whether the erros I'm seeing might not be indicative of a pacman, rather than an infinality-bundle, issue.

Last edited by jamtat (2014-10-01 21:01:10)

bohoomil · 2014-10-01 23:35:01

jamtat wrote:

What could be going on here?

This:

failed retrieving file 'infinality-bundle.db.sig' from ibn.net63.net

The old server was deprecated at the end of March 2014. The only file you can download from it today is the 404 error page.

Please, consult the Wiki for more information and update your system on a regular basis.

jamtat · 2014-10-02 01:38:52

Thanks for your input, bohoomil. I've been seeing an error message for awhile now and have done web searches at least a couple of times. I always found this thread and the repository address it contains, so was unable to determine why I was getting the error messages. I used the wiki and this thread to set all this up to begin with, but did not make a habit of re-reading the wiki entry to look for changes such as the repository address shift. With some help from some scripters I cobbled together an update script for my system about a year and a half ago: it runs four times a week, so my system stays up to date quite well since then; it's semi-automated, so I didn't notice the error message right away once the server address changed.

3xOSC · 2014-10-03 13:44:44

I just installed Infinality and most of my fonts work well, even the bitmap ones.
I can't for the life of me get Cantarell to work. I have done fc-list to make sure that it is there:

/usr/share/fonts/otf-cantarell-ib/Cantarell-Bold.otf: Cantarell:style=Bold
/usr/share/fonts/otf-cantarell-ib/Cantarell-Regular.otf: Cantarell:style=Regular

and it is. (This is the cantarell off of infinality-bundle-fonts btw)

I did a bit of reading and tried to muck around with my ~/.config/fontconfig/fonts.conf and added some files in the /etc/fonts/conf.avail.infinality and conf.d and nothing seems to help.

At the moment my cantarell looks like this:
http://i.imgur.com/Ru4PakV.png

and the fonts.conf in my ~/.config/fontconfig looks like this:
http://ix.io/eBl

bohoomil · 2014-10-03 19:30:26

Why do you want to use Cantarell in your terminal emulator? It's not a usable combination. (BTW, you shouldn't need any local $XDG_CONFIG_HOME/fontconfig/fonts.conf file: it will mess things up terribly.)

3xOSC · 2014-10-04 07:48:49

bohoomil wrote:

Why do you want to use Cantarell in your terminal emulator? It's not a usable combination. (BTW, you shouldn't need any local $XDG_CONFIG_HOME/fontconfig/fonts.conf file: it will mess things up terribly.)

I think Cantarell looks quite nice. When you say it isn't a usable combination, do you mean it just doesn't work with infinality, or that it looks incredibly ugly?

Also, can I juts go ahead and delete my fontsconfig/fonts.conf?

Arch Linux

#1376 2014-09-14 19:16:04

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

#1377 2014-09-17 19:03:04

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

#1378 2014-09-17 20:48:26

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

#1379 2014-09-17 21:43:46

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

#1380 2014-09-18 09:13:04

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

#1381 2014-09-20 07:00:12

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

#1382 2014-09-20 10:10:05

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

#1383 2014-09-20 11:44:04

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

#1384 2014-09-20 18:20:29

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

#1385 2014-09-20 18:25:47

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

#1386 2014-09-20 21:08:47

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

#1387 2014-09-27 09:31:07

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

#1388 2014-09-27 16:59:05

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

#1389 2014-09-27 17:19:23

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

#1390 2014-09-27 20:43:16

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

#1391 2014-09-28 16:34:18

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

#1392 2014-09-29 14:35:10

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

#1393 2014-09-29 21:50:06

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

#1394 2014-10-01 09:41:26

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

#1395 2014-10-01 18:08:18

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

#1396 2014-10-01 23:35:01

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

#1397 2014-10-02 01:38:52

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

#1398 2014-10-03 13:44:44

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

#1399 2014-10-03 19:30:26

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

#1400 2014-10-04 07:48:49

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

Board footer