On Wed, 22 May 2019 04:03:25 +0900,
K¨¦vin Le Gouguec wrote:
> 
> 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].

Thanks for testing.  An updated patch is attached.

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

I've overlooked it at the last minute change for xftfont.c.  It is
fixed in the updated one.

> (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?)

Screening bitmap fonts from passing them to ftfont functions in
ftcrfont_get_bitmap, ftcrfont_anchor_point, and ftcrfont_shape is
resurrected by a new member bitmap_position_unit, which is primarily
introduced for HarfBuzz, in the updated patch.  The member
ft_size_draw is removed because it was a workaround in the previous
design.

In the updated patch, ftfont_open2 is merged into ftfont_open just as
before the introduction of the cairo drawing code, because they are no
longer used in cairo.

I'll push the updated one to master and also adapt it for the harfbuzz
branch in 15 hours or so.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp