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

bohoomil · 2014-06-08 19:29:44

Would it be possible to see a screenshot? What font size are you using?

89c51 · 2014-06-08 19:46:37

with (ib and dejavu-ib):

http://i.imgur.com/6AAx2OC.png

without (stock system):

http://i.imgur.com/iAu8Eft.png

size 12 in both.

aphirst · 2014-06-08 21:14:13

@bohoomil

Since the update to the most recent version of the infinality patches, I'm encountering rendering issues in mpv (specifically with libass subtitles). Every other application seems to have no issues whatsoever, just mpv. mpv also uses libass to render its on-screen-display.

Screenshot here

I'm not entirely sure how do downgrade these freetype packages, but the mpv OSD should have black borders on all the lines (instead it's all-white), and the subtitles are clearly just garbled. Very simple fonts in the subtitles just look all-white, but some fonts also have that weird webbing glitch too, as in the screenshot. I can provide samples of files if you like.

Are you in a position to test some player which uses libass yourself (e.g. mpv) to see what the problem might be, or do I need to dig further? I've also pinged rcombs in #libass but it seems appropriate to check on this end first.

I tried running mpv in verbose mode but there's absolutely nothing in the logs which suggests any kind of problem, just a cursory comment that libass successfully initialised fonts.

bohoomil · 2014-06-08 21:22:15

@89c51 It seems to be a Terminology related issue: for comparison, see xfce4-terminal and Terminology, both with exactly the same settings. Solution? I cannot think of any at the moment. You can try experimenting with other fonts and check out one that is thinner/better hinted by design (unless you insist on using DejaVu of course). Sometimes when nothing better can be done, you can experiment with bg/fg contrast: brightening the colour of the text can help mask a few drawbacks here and there. None of these are true fixes, though…

bohoomil · 2014-06-08 21:29:26

@aphirst I noticed that in mplayer2, too (I build it with libass support). For now I think I will disable the patch and re-upload the working packages. Let us wait and see what rcombs is going to say.

aphirst · 2014-06-08 21:39:01

bohoomil wrote:

@aphirst I noticed that in mplayer2, too (I build it with libass support). For now I think I will disable the patch and re-upload the working packages. Let us wait and see what rcombs is going to say.

We're talking about it in Freenode #libass now, here's a relevant part of our conversation:

<rcombs> aphirst: were you getting those issues with freetype-fpu?
<rcombs> (I've been using freetype-fpu locally since pushing it and haven't seen anything like that, but I wouldn't really be surprised if there was some corner case that I screwed up)
<aphirst> well I never got round to trying just freetype-fpu on its own, as I'd already set up the repo packages with the infinality packages, and didn't especially look forward to the downgrading and reinstalling mess
<aphirst> I suppose I naively hoped it would be fine
<rcombs> aphirst: please do
<rcombs> aphirst: either we'll see it work fine on freetype-fpu and we blame some other infinality patch, or we see it fail on freetype-fpu as well and you send me a sample and I fix a corner-case
<aphirst> rcombs, I'll try, though I won't really have time till tomorrow evening now
<aphirst> mmm
<rcombs> or just send a sample now and I'll check myself
<aphirst> sample of a video?
<aphirst> rcombs, well it even affects the mpv OSD, it f---s up the borders of the progress bar elements
<aphirst> rcombs, even with mpv --no-config
<aphirst> rcombs, but sure I'll send a video which shows it
<rcombs> aphirst: ah, then that'll be infinality then
<rcombs> aphirst: no such problems here

<Chortos-2> the only thing I can think of is all the corner cases with 0 and pi
<aphirst> well I'll just have to see what progress I can make with the infinality patched package maintainer

<Chortos-2> for all we know, maybe these glitches are somehow caused by a slightly wrong value of M_PI

<Chortos-2> I'm sure freetype makes some assumptions about the ranges of its trigonometric values

<Chortos-2> to expand on my earlier comment, for example, atan2 guarantees its return value to be in [-pi, pi]. then the patch multiplies it by 180/M_PI. if M_PI is a bit too small, the resulting value may be outside the [-180, 180] range

Basically, he reckons that something in the Infinality patchset is interfering with it in some way. I myself am not really in a position to investigate this, but I might at least look through the patches to see if anything else touches fttrigon.c. It'd be a shame if this ultimately can't get merged.

EDIT: Huh, nothing in the main 'infinality' patch seems to touch that file. Not sure about any other alterations made since then, i.e. anything extra that's been added by bohoomil.

Last edited by aphirst (2014-06-08 21:57:01)

bohoomil · 2014-06-08 21:54:12

I'd say that Infinality patchset needs an update. Too bad that the author has been unreachable for quite a time…

brebs · 2014-06-08 21:59:29

FWIW, these 3 values for M_PI don't help mpv's progress bar:

3.14159265358979323846
3.14159265358979323846264338327950288
3.141592653589793238462643383279502884L

Edit: This bug exists in 11rcombs' repo, compiled plainly, so blame him

Well, plainly except for the necessary definition:

sed -e "1i #define M_PI 3.141592653589793238462643383279502884L" -i src/base/fttrigon.c

Last edited by brebs (2014-06-08 22:03:13)

aphirst · 2014-06-08 22:06:30

brebs wrote:

FWIW, these 3 values for M_PI don't help mpv's progress bar:
3.14159265358979323846
3.14159265358979323846264338327950288
3.141592653589793238462643383279502884L
Edit: This bug exists in 11rcombs' repo, compiled plainly, so blame him
Well, plainly except for the necessary definition:
sed -e "1i #define M_PI 3.141592653589793238462643383279502884L" -i src/base/fttrigon.c

Thanks for testing! I was just about to ask another Arch-using friend if he had the time to try it for my sake. I've let rcombs know in the channel that this is the case. They're currently investigating whether or not some of the trig functions behave differently on the different platforms, and I'll post back with any conclusions they come to.

EDIT: rcombs pushed a change which might be worth testing?

<Chortos-2> or maybe freetype actually expects them to be treated differently, but then why does it work on os x
<rcombs> Chortos-2: what platforms have you been testing on?
<Chortos-2> just snow leopard
<rcombs> so what we're saying is, perhaps OSX's library handles the edge cases in a way freetype likes?
<rcombs> (the behavior when dy and dx are both 0 in atanf is undefined, btw)
<Chortos-2> well, more like "I have faith that OS X handles the edge cases in accordance with IEEE 754, so that probably means freetype does like that", but that's also a possibility
<rcombs> erm, atan2f
<Chortos-2> hmm
<Chortos-2> that could be it
<rcombs> lemme see if that ever gets passed in
<rcombs> (and what gets returned)
<Chortos-2> well, there was an explicit check for it in the original code
<Chortos-2> but no, it's not undefined
<Chortos-2> If y is ±0 and x is -0, ±pi shall be returned.
<Chortos-2> If y is ±0 and x is +0, ±0 shall be returned.
<Chortos-2> (I don't think -0 ever happens in your code)
<rcombs> well, either way, it's not what freetype does
<Chortos-2> 0 is what freetype does
<rcombs> oh, -0
<rcombs> Chortos-2: where's this spec from?
<Chortos-2> posix (more precisely, man 3p on linux)
<rcombs> is atan2f POSIX?
<Chortos-2> but both the os x and linux man pages for atan2f confirm that they do just that
<Chortos-2> well, atan2f is C99, and edge cases are IEEE 754
<Chortos-2> IEEE 60559 nowadays, apparently
<rcombs> well, pushed a change that puts FT's 0 check back; see if it makes a difference?
<Chortos-2> (spoiler: it won't) but it never hurts to check, of course
<rcombs> yeah
<Chortos-2> — atan2(±0, −0) returns ±π.
<Chortos-2> — atan2(±0, +0) returns ±0.
<Chortos-2> same from C11
<Chortos-2> (where the leading dash is a list marker)
<Chortos-2> oh, s/IEEE 60559/IEC 60559/
<Chortos-2> this last quote is specifically from annex F, "IEC 60559 floating-point arithmetic"

EDIT 2: @brebs, what are your CFLAGS? Chortos-2 was asking whether you had anything like -O3, -Ofast or --fast-math set when building?

Last edited by aphirst (2014-06-08 22:21:12)

brebs · 2014-06-08 22:29:53

That cleanup commit just makes mpv crash (in glibc 2.19), as soon as the progressbar would be displayed (the crash happens before the progressbar is shown).

My CFLAGS are standard stuff: -O2 -march=native -fomit-frame-pointer -pipe

I would not be surprised if this is another maths bug in glibc.

aphirst · 2014-06-08 22:44:37

brebs wrote:

That cleanup commit just makes mpv crash (in glibc 2.19), as soon as the progressbar would be displayed (the crash happens before the progressbar is shown).
My CFLAGS are standard stuff: -O2 -march=native -fomit-frame-pointer -pipe
I would not be surprised if this is another maths bug in glibc.

That seems to be what they're getting at. Also, Chortos-2 asks:

Chortos-2 wrote:

could you perhaps paste the disassembly of the relevant functions from `objdump -d libfreetype.so` with the fpu patch enabled (either 'vanilla' freetype or infinality, as long as the fpu patch is there)?

Also, rcombs asks if he could have a traceback of the crash you got?

rcombs wrote:

so, if anyone wants to poke at freetype-fpu, I'd appreciate any insights; as for the crashes I'm hearing about, I'll take either address sanitizer or valgrind reports (and nothing else tyvm)

Last edited by aphirst (2014-06-09 06:25:55)

89c51 · 2014-06-08 22:55:16

bohoomil wrote:

@89c51 It seems to be a Terminology related issue: for comparison, see xfce4-terminal and Terminology, both with exactly the same settings. Solution? I cannot think of any at the moment. You can try experimenting with other fonts and check out one that is thinner/better hinted by design (unless you insist on using DejaVu of course). Sometimes when nothing better can be done, you can experiment with bg/fg contrast: brightening the colour of the text can help mask a few drawbacks here and there. None of these are true fixes, though…

Thanks. (BTW the correct terminology link is http://bohoomil.com/img/arch_shots/2014 … vu_ttf.png )

Has the toolkit hinting settings something to do with the differences we see? (xfce-term is gtk E is EFL)

brebs · 2014-06-08 23:05:44

I'm outta time right now, can try again tomorrow. Here's the limited backtrace info I have to hand, sorry:

Program received signal SIGSEGV, Segmentation fault.
0xf5ce8b64 in __memset_sse2 () from /lib/libc.so.6
(gdb) backtrace 
#0  0xf5ce8b64 in __memset_sse2 () from /lib/libc.so.6
#1  0xf5d7b6bd in alloc_bitmap () from /usr/lib/libass.so.5
#2  0xf5d7b882 in outline_to_bitmap () from /usr/lib/libass.so.5
#3  0xf5d7c4cb in outline_to_bitmap3 () from /usr/lib/libass.so.5
#4  0xf5d799ea in ass_render_event () from /usr/lib/libass.so.5
#5  0xf5d7a343 in ass_render_frame () from /usr/lib/libass.so.5
#6  0x080c7a8f in mp_ass_render_frame (renderer=0x967d328, track=0x9894018, 
    time=time@entry=0, parts=parts@entry=0x905c170, res=res@entry=0xffe26cc4)
    at ../sub/ass_mp.c:174
#7  0x080cd4f4 in osd_object_get_bitmaps (osd=osd@entry=0x9055dc0, 
    obj=obj@entry=0x905c100, out_imgs=0xffe26cc4, out_imgs@entry=0x0)
    at ../sub/osd_libass.c:469
#8  0x080cc40e in render_object (out_imgs=0x0, sub_formats=0x93be4ec, 
    video_pts=64.033333333333331, res=..., obj=0x905c100, osd=0x9055dc0)
    at ../sub/osd.c:178

This is with mpv 0.3.10 and libass 0.11.2, and Infinality with patch, from the changes in freetype-fpu.

Last edited by brebs (2014-06-08 23:07:10)

brebs · 2014-06-09 12:41:23

aphirst wrote:

rcombs wrote:
so, if anyone wants to poke at freetype-fpu, I'd appreciate any insights; as for the crashes I'm hearing about, I'll take either address sanitizer or valgrind reports (and nothing else tyvm)

Here's something else

I tried a git checkout of glibc, but it doesn't stop the crashes.

I tried reducing the patchset, but that didn't stop the crashes.

It seems totally broken on Linux Mpv works fine without any of rcombs' changes, weird.

rumpelsepp · 2014-06-10 09:22:39

Hi,

I get i really strange font rendering in googles help pages using chrome: https://support.google.com/mail/answer/7401?hl=en
I have removed all custom font replacements and reinstalled infinality bundle. Preset ist 'free'. The rendered font on this webpage is OpenSans Light.

Screen

orschiro · 2014-06-10 09:38:36

@rumpelsepp

I can confirm it. It looks exactly the same for me, also using the free presets and default settings.

Last edited by orschiro (2014-06-10 09:38:46)

orschiro · 2014-06-11 19:07:40

@bohoomil

Is it a bug that for instance Noto Sans displays a bold font type setting twice or a feature?

Screenshot: http://i.imgur.com/gsr8QP2.png

At least I cannot see a difference between the two with my eyes.

aphirst · 2014-06-12 16:18:47

brebs wrote:

aphirst wrote:
rcombs wrote:
so, if anyone wants to poke at freetype-fpu, I'd appreciate any insights; as for the crashes I'm hearing about, I'll take either address sanitizer or valgrind reports (and nothing else tyvm)
Here's something else
I tried a git checkout of glibc, but it doesn't stop the crashes.
I tried reducing the patchset, but that didn't stop the crashes.
It seems totally broken on Linux Mpv works fine without any of rcombs' changes, weird.

No chance of asan or valgrind output? I was gonna try to look into this myself, but time's been tight for me recently.

bohoomil · 2014-06-13 10:04:14

rumpelsepp wrote:

Screen

This is the ugly Chrome/Chromium ID (= bug). The ugly (but effective) workaround (already mentioned in the Wiki) is the following piece of code:

<match target="pattern">
    <edit name="dpi" mode="assign">
      <double>72</double>
    </edit>
  </match>

--- put in $XDG_CONFIG_HOME/fontconfig/fonts.conf. (orschiro, you should already know that, shame on you! ;p )

@89c51 I am sorry for the terribly late response. This can be either the toolkit specific issue or the matter of its implementation. Terminology has a pretty sophisticated UI. This can introduce certain interference to the clarity of the picture, once the font is not technically perfect. If possible, try to simplify it a bit, e.g. disable some gradients and more graphically advanced UI elements just to see if this helps. I for one would check out a different font family in the first place: Liberation Mono has proved to be very reliable and quite easy to deal with, it is my personal favourite wherever nothing else works as expected.

IMPORTANT NOTICE

In a few minutes I am going to upload a huge update: ~150 font packages with reworked rendering settings, lots of fixes and such. The main difference is that, as a few recent updates has already shown, I decided to split per-family settings from global fontconfig-iu config files and move them to individual font packages. Infinality-bundle-fonts users should not notice any difference but for the better: some long present issues somehow have been fixed by the switch. Those of you who do not use fonts from the repository can still use every single configuration file. Please, check out the Changelog and read how to update your systems properly. Thanks.

89c51 · 2014-06-13 10:42:20

@bohoomil

No problem mate. You are a community member not a tech support guy. I just wanted to know if it is something that worth mentioning to the E people so they can look into it.

rumpelsepp · 2014-06-13 17:06:08

bohoomil wrote:

rumpelsepp wrote:
Screen
This is the ugly Chrome/Chromium ID (= bug). The ugly (but effective) workaround (already mentioned in the Wiki) is the following piece of code:
<match target="pattern">
    <edit name="dpi" mode="assign">
      <double>72</double>
    </edit>
  </match>
--- put in $XDG_CONFIG_HOME/fontconfig/fonts.conf. (orschiro, you should already know that, shame on you! ;p )

Thanks, I will check it out!

Reading your recent changelog entry I've seen a bug on your homepage. The last line is not readable.
Bildschirmfoto%20vom%202014-06-13%2019%3A03%3A54.png

bohoomil · 2014-06-13 18:02:24

@rumpelsepp Thanks -- fixed. I forgot to copy the modified template from the draft directory to the public one.

orschiro · 2014-06-13 18:25:08

--- put in $XDG_CONFIG_HOME/fontconfig/fonts.conf. (orschiro, you should already know that, shame on you! ;p )

I know.

But although I have created this file in the past, it seems to be not sufficient for the Google page.

~ cat .config/fontconfig/fonts.conf
<!-- 
Fix bold font issue in Chromium
https://bbs.archlinux.org/viewtopic.php?pid=1344369#p1344369
-->
<match target="pattern">
    <edit name="dpi" mode="assign">
      <double>72</double>
    </edit>
</match>

bohoomil · 2014-06-13 20:40:02

orschiro wrote:

it seems to be not sufficient for the Google page.

Because this is not a proper fix. People at Google should reconsider their web browser philosophy: the way fonts are handled in Chromium simply sucks.

aphirst · 2014-06-14 19:03:43

@brebs /bphoomil

rcombs wrote:

I just had a crash similar to the ones people have been reporting in freetype-fpu; I pulled the latest master and rebased my branch against that, and it stopped happening
pushed that change; could you test?
sounds like there's a decent chance it was actually a bug in the version of Freetype I made my changes against
aphirst: care to poke the infinality guys?

Arch Linux

#1201 2014-06-08 19:29:44

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

#1202 2014-06-08 19:46:37

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

#1203 2014-06-08 21:14:13

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

#1204 2014-06-08 21:22:15

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

#1205 2014-06-08 21:29:26

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

#1206 2014-06-08 21:39:01

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

#1207 2014-06-08 21:54:12

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

#1208 2014-06-08 21:59:29

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

#1209 2014-06-08 22:06:30

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

#1210 2014-06-08 22:29:53

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

#1211 2014-06-08 22:44:37

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

#1212 2014-06-08 22:55:16

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

#1213 2014-06-08 23:05:44

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

#1214 2014-06-09 12:41:23

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

#1215 2014-06-10 09:22:39

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

#1216 2014-06-10 09:38:36

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

#1217 2014-06-11 19:07:40

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

#1218 2014-06-12 16:18:47

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

#1219 2014-06-13 10:04:14

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

#1220 2014-06-13 10:42:20

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

#1221 2014-06-13 17:06:08

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

#1222 2014-06-13 18:02:24

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

#1223 2014-06-13 18:25:08

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

#1224 2014-06-13 20:40:02

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

#1225 2014-06-14 19:03:43

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

Board footer