Re: [ft-devel] [CREATE] glyf (i.e. contour) analysis reports on libre fonts.

[Hin-Tak Leung]

On Fri, 12/8/16, peter sikking  wrote:

> Dave Crossland wrote:
 
> > Thanks Hin-Tak! You did an amazing thing
 in the last year :D
 
> hear hear. this kind of work can be rather
 thankless, so
 I hope that Hin-Tak is getting
 enough fun and satisfaction
 out of it.
 

Peter, thanks for the kind words!

One response in create can be taken that way, and certain another one in 
Typedrawers: "I have been doing this for years, it does not seems to cause 
problems, why is it flagged as a problem?" . Those are the sort of responses I 
find very draining and exhausting.

Font engines are built to cope with all sort of problems. That does not means 
those problems should not be fixed. In addition, Microsoft had obviously built 
the analysis to be strict and also their preferences-as-imperatives, because 
they can, in both senses - they are big enough to say, because I prefer things 
done this way, therefore you should do things this way, and also, they know far 
more about fonts and can implement more thorough tests for them.

That the test is very strict, is exactly where its value is. Anybody can 
blindly tell you that your font is okay. It takes efforts to detect flaws.

Very much to Microsoft's credit, they have opened up the glyf test in source 
form; and the 1.0 rasterization test is binary-only but free download and 
free-use. The latter allows an imitation to be created in 2.0, quite 
successfully, and beyond initial expectation too: if you just throw a large 
number of buggy fonts at the old 1.0 test and collect the reports, and try to 
detect the same flaws with an alternative implementation, you end up with 
nearly the same thing, much faster and more robust too.

I have fixed a whole lot of problems in the past 12 months, where FV does not 
finish writing a report or does not complete an analysis (like missing the 
rasterization test, but also elsewhere). This latest is a continuation and next 
level up, where FV itself says it cannot continue. For most parts, I have to 
trust that the existing code from Microsoft which they had been writing for 
15-20 years is correct, and the generated reports are worth looking at by font 
designers, however painful they might feel to be told that their favorite 
creations can be flawed.

So I have learned not to argue about the content of the reports. I do not look 
at individual reports, and do not wish to engage in any discussion in that 
direction. I only try to make it produce a report under all circumstances, and 
hopefully, the reports are worth looking at.

It does not need to be 100% correct 100% of the time, and it does not need to 
claim to be. If it flags some genuine problems with some fonts, and some of the 
problems get fixed over time, that's worth doing.

Hin-Tak

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] "Inside the fastest font renderer in the world" - conversion started

[Graham Asher]

Behdad,

It might be faster, but then again it might not be, depending on the 
value of n, the cost of the test for subdivision, and other things. I 
shall leave all of ftsmooth untouched; this will be an independent piece 
of software that may be connected to FreeType afterwards. However, I 
shall not be engaging in a general discussion about this, except for the 
odd question to Raph, but getting on with it, using my judgement as to 
how to proceed - committee programming is not for me. Anyone who wants 
to try other ways of converting what is a small piece of software can 
try their hand; as I said, there's no rocket science involved.


- Graham


On 12/08/2016 21:38, Behdad Esfahbod wrote:


Because it's faster to subdivide into n segments in a single loop.  
But yeah, that doesn't really matter here, I think you can leave that 
part of ftsmooth untouched.



On Aug 12, 2016 7:15 AM, "Graham Asher" > wrote:


Hi Werner,

yes, I e-mailed him yesterday, and asked a question about his code
too, but with no great hope of an early reply, knowing he's busy.
I asked him why his code to handle quadratic splines used a
division into a number of evenly spaced values for the t parameter
rather than recursive Casteljau splitting. The question was
triggered by seeing that there is a handler for quadratic splines
but not for cubics in his code (it was written for TrueType only).
I suspect the answer has to do with the use of floating-point
rather than integer arithmetic, but if there is no good reason I
will be tempted to (for now) use Casteljau splitting for cubic
splines, or for both types. I am almost certain that it will have
little impact on efficiency, or even improve it, but let's see.

- Graham


On 12/08/2016 06:45, Werner LEMBERG wrote:

Hello Graham,

I have started converting it to C++.  I will do that for
now because
C would adds an extra layer of difficulty and slow the
work down;
but don't worry, there's no rocket science, and it should
be easy to
produce a C version when I've done it.

great!  Please inform Raph also (in case you haven't done so);
I think
he is not on this list.

Wish me luck...

I do :-)


 Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org 
https://lists.nongnu.org/mailman/listinfo/freetype-devel




___
Freetype-devel mailing list
Freetype-devel@nongnu.org 
https://lists.nongnu.org/mailman/listinfo/freetype-devel




--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel