Re: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread James Cloos
> "GA" == GRAHAM ASHER writes: GA> Some reasons this hasn't made very many waves; GA> 1. My impression is that nearly all actual fonts are TrueType these GA> days. TrueType does't use cubic splines. It uses quadratics only. Cubic fonts remain an important sector, especially for print and f

Re: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread GRAHAM ASHER
nd s-coordinates with the same sign. Graham - Original Message From: Werner LEMBERG To: david.be...@pb.com Cc: graham.as...@btinternet.com; freetype-devel@nongnu.org Sent: Tuesday, 31 August, 2010 14:29:49 Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug > If I

Re: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread GRAHAM ASHER
: Tuesday, 31 August, 2010 17:07:52 Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug Can you give the workings? The equation I think you mean is this one: 0.07200(v + 3.180556)v + 0.449000, so when I substitute 0.1 for v I get 0.07200(0.1 + 3.180556)0.1 + 0.449000 which gives

Re: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread GRAHAM ASHER
e roots, posing more problems for integer overflow and speed. > > If you can code up a better fix than mine, using one of the algorithms you > cite, > I will be very happy to withdraw my suggestion in favour of yours. I think > an > insuperable difficulty will be the possibility of

Re: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread Werner LEMBERG
> If I was managing this project, I would certainly consider this an > unacceptable approach / sequence of events. Usually, I'm quite conservative, and Graham has provided a lot of useful additions to the FreeType code. I trust him to fix that in due course. > Better to keep the inefficiency th

RE: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread David Bevan
ack in the pre-history of FT, since it is obviously of critical > importance for > correct output. > > Since it apparently hasn't been, we can make use of the latest research. > > David %^> > > > > -Original Message- > > From: freetype-devel-

Re: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread GRAHAM ASHER
12:18:45 Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug David, Thank you very much for the citations, which are very interesting, but I don't think anybody is proposing reinventing anything - least of all me. The problem here is not whether there are known rigorous m

Re: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread Werner LEMBERG
> Naively, I had assumed that this sort of issue would have been > resolved properly back in the pre-history of FT, since it is > obviously of critical importance for correct output. Well, Graham tries to make FreeType faster than the originally used (and working) algorithm. > Since it apparentl

Re: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread GRAHAM ASHER
al Message From: David Bevan To: freetype-devel Sent: Tuesday, 31 August, 2010 9:14:36 Subject: RE: [ft-devel] a satisfactory fix for the cubic spline bug Rather than piecemeal reinventing of the wheel, I would have thought that FT should implement a mathematically rigorous flattener. The follo

RE: [ft-devel] a satisfactory fix for the cubic spline bug

2010-08-31 Thread David Bevan
el > Subject: [ft-devel] a satisfactory fix for the cubic spline bug > > I thought about this overnight and realised that we can slightly modify > the existing heuristic to get a much simpler fix. Instead of trying to > find points on the curve or trying to measure the distance from a

[ft-devel] a satisfactory fix for the cubic spline bug

2010-08-30 Thread Graham Asher
I thought about this overnight and realised that we can slightly modify the existing heuristic to get a much simpler fix. Instead of trying to find points on the curve or trying to measure the distance from a point to a straight line, we adapt the earlier idea, used in existing FreeType code, o