Nicolas,
It looks to me like you terminate the loop too early. gindex == 0 is the last
glyph; you could use do {} while (); rather than while () {}.
David %^
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
.
David %^
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
David Bevan
Sent: 26 September 2011 09:13
To: Nicolas Rougier
Cc: Freetype-devel@nongnu.org
Subject: Re: [ft-devel] FT_Get_Char
Message-
From: Werner LEMBERG [mailto:invalid.nore...@gnu.org]
Sent: 12 August 2011 07:55
To: Werner LEMBERG; David Bevan
Subject: [bug #33992] heap underflow in ft_stroke_border_close
Update of bug #33992 (project freetype):
Status:None = In Progress
This is also fixed by the fix for Savannah bug #33992.
Thanks.
David %^
-Original Message-
From: freetype-bounces+dbevan=emtex@nongnu.org
[mailto:freetype-bounces+dbevan=emtex@nongnu.org] On Behalf Of seayoung
Sent: 11 August 2011 03:55
To: Werner LEMBERG
Cc: freetype
Werner,
I think only the documentation for FT_Stroker_LineJoin will need updating to
match the new ftstroker.h.
Perhaps this happens automatically.
David %^
-Original Message-
From: David Bevan
Sent: 01 July 2011 11:40
To: 'Werner LEMBERG'; graham.as...@cartotype.com; freetype
Swapping the directions of the outer and inner borders seems to make sense.
I'll include that in my fixes.
David %^
From: Graham Asher [mailto:graham.as...@cartotype.com]
Sent: 27 June 2011 17:14
To: David Bevan
Cc: Werner LEMBERG; freetype-devel@nongnu.org
: Graham Asher [mailto:graham.as...@cartotype.com]
Sent: 28 June 2011 15:43
To: David Bevan
Cc: freetype-devel@nongnu.org
Subject: Re: [ft-devel] stroker - bevel joins
David,
here's a quote concerning optimisation from an e-mail of mine to Werner back in
March when I was looking into this - key
have any view on handling the miter limit?
I will implement option 4 below unless I receive feedback in favour of a
different approach.
Thanks.
David %^
From: Graham Asher [mailto:graham.as...@cartotype.com]
Sent: 27 June 2011 17:14
To: David Bevan
Cc
Some of these tables are very short (a total of only 44 bytes on the Mac), so
what is the likelihood that they match tables in other fonts that don't require
TT hinting?
We need some guarantee that comparing these values will uniquely identify the
relevant fonts.
David %^
-Original
In general scope, I think, you raised a concern that
the checksum in TTF header is too simple (it's a sum
of 32-bit values of the table) to guarantee the identity.
It's reasonable.
My concern is that the (small) tables may actually be the same in a variety of
fonts.
If I check the fonts
Aleksei,
If you relax the condition, you increase the number of splits. Normally, making
such a change is a mistake because the benefit of simplifying the condition is
easily outweighed by the greater cost of increasing the recursive depth. This
is the very reason why we ended up with a much
Alexei,
Since there are two changes, (the value of FT_MAX_CURVE_DEVIATION and the
algorithm), each must be tested independently.
Which has broken the rendering?
We need trace info: Does the new algorithm actually do what it claims. I.e. is
the actual deviation really limited to the
; freetype-devel
Subject: Re: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Alexei,
I don't have much time or energy for this at the moment - sorry. Of course
I
will be looking at it again, but I believe that the solution hammered out
by
David Bevan and myself is a good one - it solves
Graham,
Here are the results of my performance testing. I was a bit surprised by the
results.
In gray_convert_glyph, the time is distributed as follows:
OLDNEW
render_line 20%15%
render_cubic 15%33%
render_scanline 14%10%
split_cubic6%
.
David %^
-Original Message-
From: GRAHAM ASHER [mailto:graham.as...@btinternet.com]
Sent: 07 September 2010 13:46
To: David Bevan
Cc: freetype-devel
Subject: Re: [ft-devel] latest patch file for spline flattening
That is very interesting and very useful - in fact I think the more
I've now implemented something based on Hain's research and it seems to be
measurably faster than previous FT approaches. I have used Hain's paper (now
available from http://tinyurl.com/HainBez) to provide some sensible heuristics
rather than implement all his stuff in detail, and done so
Here are some test results with Latin fonts (40 thousand curves from fonts at
various point sizes).
Trace results:
CJK CJK CJK LATIN LATIN
OLD NEW HAINNEW HAIN
Graham,
That's looking much closer to what I would have thought we needed; only
splitting the curve when required. However, your fast heuristic can be very
inaccurate.
Consider
P0: 0,0
P1: 5,5
P2: 95,5
P3: 100,0
The max deviation is 3.75 (0.75 * 5 since Hain's v == 1), but your
, but hope to spend most of tomorrow on this.
David %^
-Original Message-
From: Graham Asher [mailto:graham.as...@btinternet.com]
Sent: 6 September 2010 12:36
To: David Bevan
Cc: freetype-devel
Subject: Re: [ft-devel] latest patch file for spline flattening
David,
in fact I coded
of the chord, so all we need do is add one iteration for an initial
contrary
case.) I suspect that the answer is no, but I am sure David Bevan will
want to
comment. If the answer is no, then I shall need to code up a fix that
estimates
flatness efficiently on each iteration of the bisection loop
Some brief comments inline.
More feedback from my investigations later.
-Original Message-
From: Graham Asher [mailto:graham.as...@btinternet.com]
Sent: 3 September 2010 13:56
To: David Bevan
Cc: FreeType
Subject: Re: [ft-devel] more thoughts on cubic spline flattening
David
I've added some trace code to gray_render_cubic to report the average number of
line segments created for a Bezier arc, and to calculate for each segment the
(exact) deviation of the arc segment it replaces.
I've still only tested this with the pre-2.4.0 code. Here are the results with
my
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
Graham Asher
Sent: 29 August 2010 20:01
To: James Cloos
Cc: freetype-devel
Subject: Re: [ft-devel] Re: preliminary analysis of
Rather than piecemeal reinventing of the wheel, I would have thought that FT
should implement a mathematically rigorous flattener. The following might be a
good place to start:
http://www.cis.southalabama.edu/~hain/general/Publications/Bezier/Camera-ready%20CISST02%202.pdf
Or:
.
David %^
P.S. I have a degree in mathematics from Oxford University.
-Original Message-
From: GRAHAM ASHER [mailto:graham.as...@btinternet.com]
Sent: 31 August 2010 12:19
To: David Bevan; freetype-devel
Subject: Re: [ft-devel] a satisfactory fix for the cubic spline bug
-Original Message-
From: freetype-devel-bounces+david.bevan=pb@nongnu.org
[mailto:freetype-devel-bounces+david.bevan=pb@nongnu.org] On Behalf Of
GRAHAM ASHER
Sent: 23 July 2010 08:57
To: Werner LEMBERG
Cc: FreeType
Subject: [ft-devel] rasterization without sorting - in
Hi!
Our software uses the FreeType charmap index directly to access the appropriate
cmap. (In retrospect, that was perhaps a poor design decision.)
We will need to be able to retain the existing behaviour. However, if the
original index is available somehow, we would have no problems with a
on the FT2 charmap index and the TT
cmap subtable index being the same - and would need changing if we did
encounter a broken TTF.
David %^
-Original Message-
From: mpsuz...@hiroshima-u.ac.jp [mailto:mpsuz...@hiroshima-u.ac.jp]
Sent: 12 July 2010 09:31
To: David Bevan
Cc: freetype-devel
Of Behdad
Esfahbod
Sent: 05 May 2010 20:40
To: David Bevan
Cc: freetype-devel@nongnu.org; Antony Bush; Stephen Brazier; Houjie Tu
Subject: Re: [ft-devel] FT_LOAD_VERTICAL_LAYOUT?
On 05/05/2010 08:55 AM, David Bevan wrote:
And how /should/ FreeType be used for vertical writing mode?
This is how cairo
is FT_LOAD_VERTICAL_LAYOUT problematic?
And how should FreeType be used for vertical writing mode?
David %^
David Bevan
Development Manager
Pitney Bowes Emtex Software
Tel: +44 (0)1923 279300
david.be...@pb.commailto:david.be...@pb.com
___
Freetype-devel
All the proposed solutions assume that there is a (known) integer size which
matches the pointer size. This is clearly a compiler-specific requirement.
For example, in the latest proposal below, if unsigned long is 32-bit and void*
is 64-bit [which I believe is the case with 64-bit MSVC -
31 matches
Mail list logo
