Re: [ft-devel] stroker - bevel joins
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 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? Change the implementation to match the PS/PDF References, discarding the XPS-style approach. 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. Support both, with FT_STROKER_LINEJOIN_MITER unchanged, and a new FT_STROKER_LINEJOIN_FIXED_MITER for the PS/PDF approach. 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 david.be...@pb.commailto:david.be...@pb.com ___ Freetype-devel mailing list Freetype-devel@nongnu.orgmailto:Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] stroker - bevel joins
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: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 quote in bold below: I have also discovered that CartoType's method of stroking paths is much faster than FreeType's (more than twice as fast, I think - at any rate, it makes CartoType benchmark at about 10 seconds as opposed to 15 seconds, and CartoType does a lot of other things; this was disappointing to me because I had hoped to speed up CartoType by using the FreeType method). I don't have time to create a FreeType version of the CartoType system right now, but I think it's because CartoType uses the intersections of parallels to get inner join positions, while FreeType calculates them using trigonometry. I'm happy to share CartoType's system with the world if it's of interest - but again, it's a matter of time, because I am very busy and CartoType's C++ coding style is very different from FreeType's C, so I'd have to do a lot of conversion. Credit for CartoType's system is due to my colleague Lex Warners (now inactive, alas), who also implemented the fixed-point trigonometric routines. I haven't had time to think about the mitre limit yet. Best regards, Graham On 28/06/2011 09:01, David Bevan wrote: 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:graham.as...@cartotype.com] Sent: 27 June 2011 17:14 To: David Bevan Cc: Werner LEMBERG; freetype-devel@nongnu.orgmailto:freetype-devel@nongnu.org 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
Re: [ft-devel] stroker - bevel joins
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:graham.as...@cartotype.com] Sent: 27 June 2011 17:14 To: David Bevan Cc: Werner LEMBERG; freetype-devel@nongnu.org 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 david.be...@pb.com ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
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 quote in bold below: I have also discovered that CartoType's method of stroking paths is much faster than FreeType's (more than twice as fast, I think - at any rate, it makes CartoType benchmark at about 10 seconds as opposed to 15 seconds, and CartoType does a lot of other things; this was disappointing to me because I had hoped to speed up CartoType by using the FreeType method). I don't have time to create a FreeType version of the CartoType system right now, but I think it's because *CartoType uses the intersections of parallels to get inner join positions, while FreeType calculates them using trigonometry.* I'm happy to share CartoType's system with the world if it's of interest - but again, it's a matter of time, because I am very busy and CartoType's C++ coding style is very different from FreeType's C, so I'd have to do a lot of conversion. Credit for CartoType's system is due to my colleague Lex Warners (now inactive, alas), who also implemented the fixed-point trigonometric routines. I haven't had time to think about the mitre limit yet. Best regards, Graham On 28/06/2011 09:01, David Bevan wrote: 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:graham.as...@cartotype.com] Sent: 27 June 2011 17:14 To: David Bevan Cc: Werner LEMBERG; freetype-devel@nongnu.org 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
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). 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 david.be...@pb.com mailto:david.be...@pb.com ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
