On 2018-03-11 18:03:27, Matthieu Herrb <matth...@herrb.eu> wrote:
> On Sun, Mar 11, 2018 at 11:58:50AM +0900, Bryan Linton wrote:
> > [I sent a copy of this email to tech@ 24 hours ago and it hasn't
> > shown up yet.  Apologies if this ends up being a double-post.]
> > 
> > Hello tech@
> > 
> > I'm not sure if it's bad form to crosspost this from bugs@ to
> > tech@ or not, but I have a patch that fixes a font rendering issue
> > with the new FreeType 2.8.1 update that went in last December.
> > 
> > The beginning of the thread can be found at the following link.
> > It also includes a screenshot (linked at the very bottom of the
> > page) of how it manifests in an xterm.  FWIW, I also see the same
> > rendering issue in Firefox, so it's not just limited to the console:
> >     https://marc.info/?l=openbsd-bugs&m=151835980313045&w=2
> > 
> > I managed to bisect things, and found that this one-line diff
> > fixes the issue for me.  It's a reversion back to the line of code
> > that was present in FreeType 2.8.0.
> 
> Thanks for bisecting the problem which apparently only happens for
> some specific fonts since I've not been able to reproduce it with any
> other font nor have I seen other reports of similar issues.
> 
> Did you try to report it upstreams ? (in the mean time Freetype 2.9
> has been released, but without change to this code.
> 

I have not reported this to upstream yet.  I see that you have
already done so in my stead though.  Thank you for doing so.

> Reading the commit bd28952e23bcd268a623ea5202e1cde4a92defe4 from
> upstreams they seem to assume that the memory allocated by
> memory->alloc() is already zeroed. The original but report is
> https://savannah.nongnu.org/bugs/?51816
> 
> Does an explicit zeroing like in the patch below also fix the issue
> for you ?
> 

Yes, I can confirm that your patch fixes this issue for me.  Thank
you very much for looking into this for me.

-- 
Bryan

Reply via email to