|
From: | David Bevan |
Subject: | Re: [ft-devel] stroker - bevel joins |
Date: | Wed, 29 Jun 2011 03:52:04 -0400 |
Graham, Certainly the FT stroker could be
speeded up by limiting the use of trigonometric functions as far as possible. However, that would be quite a lot of
extra work, so I won’t be making any changes in that direction at this
time. Thanks. David %^> From: Graham Asher [mailto: David,
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: 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
|
[Prev in Thread] | Current Thread | [Next in Thread] |