freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] Upstreaming freetype diagnostics patches


From: Hin-Tak Leung
Subject: Re: [ft-devel] Upstreaming freetype diagnostics patches
Date: Thu, 7 Sep 2017 17:08:51 +0000 (UTC)

--------------------------------------------
On Thu, 7/9/17, Werner LEMBERG <address@hidden> wrote:
 
> Felipe, you have to
> be aware that the target of FreeType is *not* font
> validation.  For this reason some errors
> necessary by FontValidator
> will never be
> reported by FreeType, which instead tries to understand
> even malformed fonts as much as possible.

I updated the FAQ entry - 
https://github.com/HinTak/Font-Validator/wiki/FAQ#why-did-you-not-try-harder-to-upstream-the-patch

- to also reflect an "upstream" point of view:

"Not all changes appropriate to font diagnostics (detailed, spend as
much time as necessary, and look at problems at some details,
tracking states and precise usage of resources) is suitable for font
rendering (fast and quiet, and skip over problems quickly,
always over-allocate slightly for user errors). Some of the changes will never 
be accepted."

The FAQ, sadly, is essentially the collected exchanges I seem to be repeatedly
try to get across to Felipe in the last week or so.

You know I upstream what I think should go into freetype from time
to time, when I update the fontval patch.

I think, in principle, you won't object to changes up to b54 being merged,
once the issues with b06 (the global variable, the error code list) is sorted 
out.

However, it is a 1900-line patch to mostly a 8500-line file, which is quite an
ugly thing to include. What it really amounts to, codes only used by one 
application.
Should freetype takes on a patch of that size for essentially single-use?
That's an upstream point of view too.

That's two weeks' of work between b06 and b54. Things happened the year after
b54/FontVal 2.0 upto FontVal 2.1 a few weeks ago, implementing the rest of it
in another 1000 lines, are a lot of changes/additions which
I am fairly sure don't belong in freetype, ever, at all.

Consider that I am the only linux user of this code, and I don't
want my system-wide freetype loaded up with this stuff that way
all the time with every web page I read, every document I edit,
even if/when the issue with the diagnostis hook is sorted out.
I think that says it all about whether most of it should be in freetype.

In any case, I am glad that changes in mono in the last 12 months
means I can ship all-in-one linux binaries without any mono bits or
visible customized freetype bits hanging around. That is a fairly
major improvement from a year ago.


reply via email to

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