freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] [smooth] Implement minimal dynamic padding for LCD filter


From: Werner LEMBERG
Subject: Re: [ft-devel] [smooth] Implement minimal dynamic padding for LCD filtering. -- Still breaks Firefox
Date: Tue, 30 May 2017 08:27:41 +0200 (CEST)

>> There you go. This change breaks Skia:
>> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=ab2599ea3f09ba8da4f50b877021d23241d22609
>>
>> This is what Skia shoudl not do by itself
>> https://skia.googlesource.com/skia/+/master/src/ports/SkFontHost_FreeType.cpp#1180
>>
>> This is a Skia issue that I opened
>> https://bugs.chromium.org/p/skia/issues/detail?id=6663
>
> I think you cannot simply break Firefox/Chrome for a minor
> optimization.  What will happen when the next FreeType version gets
> released?  All distros will have to revert your patch to not break
> the browsers.

Well, sometimes Alexei has radical ideas compared to my conservative
attitude, but in this very case I'm on his side :-) External code
*must not* rely on internal FreeType stuff!

> So yes, it is wrong that Skia doesn't use the size and offset
> returned by FreeType.  But even if Skia fixes it, it will take a
> while before the fix reaches all users.

Distributions regularly apply patches to packages to suit their own
needs.  I don't see any problem here.  Honestly, I think that the
number of single users who compile Firefox or Chrome from scratch is
quite limited, thus the impact of this change is rather low – it's not
released yet!  Additionally, new releases of Firefox or Chrome are
*much* more frequent than FreeType releases.

My conclusion is that Ben will fix the issue as soon as he's back to
coding.  This certainly happens before the next FreeType release.  In
case a massive security bug forces an earlier FreeType release we can
simply take this patch out.


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]