Re: [ft-devel] stroker - bevel joins

[Graham Asher]

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).

 

5.       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