On 2018-03-11 18:03:27, Matthieu Herrb <[email protected]> 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
