Re: [ft-devel] stroker - bevel joins

[David Bevan]

Graham,

Thanks for the feedback.

I'm glad you're using it. At least there's someone who will be able to review / 
test my changes.

I'll look into the issue you mention.

Perhaps you could forward me your ideas for increasing performance, since I'm 
working on the code at the moment.

Do you 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:address@hidden 
Sent: 27 June 2011 17:14
To: David Bevan
Cc: Werner LEMBERG; address@hidden
Subject: Re: [ft-devel] stroker - bevel joins

I use the stroker - not in anger, but sometimes in sorrow ;-)

Actually it seems quite good, but it could do with some speed optimisation, 
which I have discussed before with Werner; I made some concrete suggestions 
based on a comparison with CartoType's stroker, which is somewhat faster. I 
also discovered that - for my purposes, which may be different from other 
people's, but I think this is a general bug - the direction of the outer and 
inner borders is swapped for envelopes of closed strokes, thus:
      ft_stroke_border_close( stroker->borders + 0, TRUE );
      ft_stroke_border_close( stroker->borders + 1, FALSE );
should be
      ft_stroke_border_close( stroker->borders + 0, FALSE );
      ft_stroke_border_close( stroker->borders + 1, TRUE );
The effect of the bug is to produce voids when filling envelopes of closed 
strokes that overlap other closed paths, because the outer border is clockwise 
and the inner is anti-clockwise; for correct filling, the outer should be 
anti-clockwise and the inner clockwise.

That's based on a slightly out-of-date version, so forgive me if it's been 
fixed.

Graham Asher
CartoType Ltd


On 27/06/2011 16:05, David Bevan wrote: 
Hi!
 
While developing code to support stroked text, we encountered a number of 
significant issues with the FT stroker. I will be submitting various fixes 
later in the week.
 
However, one of the issues requires discussion (or at least agreement) 
beforehand.
 
The PostScript/PDF References specify that the form of a bevel join (whether 
specified explicitly, or created as a result of exceeding the miter limit) is 
not dependent on the value of the miter limit. See the attached miter.pdf for 
an example.
 
The current FreeType code generates the bevel join using a different algorithm 
that does depend on the miter limit. This actually accords with the way the 
miter limit is handled in XPS (see attached extract from the spec).
 
NB: Be aware, if you look at the current code, that a miter join is called a 
bevel join and vice versa (and hence explicit bevel joins are implemented 
incorrectly). This will be fixed.
 
What do we want to do?
 
1. Change the implementation to match the PS/PDF References, discarding the 
XPS-style approach.
 
2. Support both, with FT_STROKER_LINEJOIN_MITER matching the PS/PDF References, 
and a new FT_STROKER_LINEJOIN_VARIABLE_MITER for the XPS-style approach.
 
3. Support both, with FT_STROKER_LINEJOIN_MITER unchanged, and a new 
FT_STROKER_LINEJOIN_FIXED_MITER for the PS/PDF approach.
 
4. Support both, with FT_STROKER_LINEJOIN_FIXED_MITER and 
FT_STROKER_LINEJOIN_VARIABLE_MITER, and FT_STROKER_LINEJOIN_MITER an alias for 
FT_STROKER_LINEJOIN_VARIABLE_MITER (the existing behaviour).
 
Something else.
 
1 & 2 introduce a backwards incompatibility, but is anyone actually using the 
stroker in anger?
 
As long as FT supports the PS/PDF approach, any of these is acceptable for us.
 
What do others think?
 
Thanks.
 
David %^>
 
David Bevan
Development Manager
Pitney Bowes Emtex Software
Tel: +44 (0)1923 279300
address@hidden
 


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