[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35781: Discrepancies between xftfont.c and ftcrfont.c
From: |
Kévin Le Gouguec |
Subject: |
bug#35781: Discrepancies between xftfont.c and ftcrfont.c |
Date: |
Tue, 21 May 2019 21:03:25 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
mituharu@math.s.chiba-u.ac.jp writes:
> I tried making ftcrfont_open look much like xftfont_open.
> Could you try the attached patch?
Thank you for this patch!
I applied it on top of cb367c8e0d, and AFAICT this fixes the issue: on
both setups where I used to see a difference in hint style[1], the
fonts now look the same (i.e. with slight hinting). Things haven't
deteriorated on the third setup[2].
I glanced at your patch to try and get a sense of how things worked;
from what I can tell you moved some logic from xftfont.c to ftfont.c,
which is used by ftcrfont.c, so the XFT and Cairo build would use more
common code?
(Is there a reason why you left xftfont_add_rendering_parameters in
xftfont.c despite adding ftfont_add_rendering_parameters in ftfont.c?
Should this function be added to ftfont.h so that xftfont.c gets rid
of its duplicate implementation?)
(Also, I see you removed some code related to the bitmap_strike_index
and ft_size_draw members of struct font_info; is it because whatever
this code was doing is now handled by… something else in ftfont.c?)
(Sorry for these Boeotian questions!)
Again, thanks a lot for this patch!
[1] Debian stretch (cairo 1.14.8) and Xubuntu 16.04 (cairo 1.14.6).
[2] OpenSUSE Tumbleweed (cairo 1.16.0).