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
[ft-devel] .gitignore in release tarballs
Hi, our building system warned me that there are .gitignore files distributed in release tarballs of freetype. Could you remove them in upcoming releases? Regards Marek P.S.: I see that they are there since 2.3.12 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF bitmap foundary patch
in openSUSE we apply a patch called freetype2-bitmap-foundry.patch which seems to add foundry support to PCF font files, likely to fix the problem reported over at http://lists.freedesktop.org/archives/fontconfig/2006-February/002072.html . The patch is attached for your inspection, can anyone check if its useful still? It seems to be useful. However, I would like to have a better description what this fix is intended to do, with an example or a good bug report. I've CCed coolo, apparently the author of the patch; perhaps he or she can shed some light on this issue. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PCF bitmap foundary patch
Hi; On Wed, Jun 29, 2011 at 6:41 PM, Werner LEMBERG w...@gnu.org wrote: in openSUSE we apply a patch called freetype2-bitmap-foundry.patch which seems to add foundry support to PCF font files, likely to fix the problem reported over at http://lists.freedesktop.org/archives/fontconfig/2006-February/002072.html . The patch is attached for your inspection, can anyone check if its useful still? It seems to be useful. However, I would like to have a better description what this fix is intended to do, with an example or a good bug report. I've CCed coolo, apparently the author of the patch; perhaps he or she can shed some light on this issue. The patch author is actually Mike Fabian, which I CC'd now, hope he has a long fresh memory! :-) Regards, ismail ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint: How to install
On 25 Jun 2011, at 06:56, Werner LEMBERG wrote: Please try the current git snapshot and play with the options --hinting-range-min and --hinting-range-max. Currently, the default value for hinting-range-max is 1000; this means that the autohinter tests all ppem values up to 1000 to find hinting sets. However, the larger the ppem, the larger the blue zones. And by design, the autohinter ignores blue zones which are larger than 3/4 pixels. If you limit hinting-range-max to a value where the blue zones are still handled, the generated bytecode uses this hinting set for all larger sizes also. Finding a good value for hinting-range-max has to be done with trial and error, but a waterfall already indicates bad sizes, so hinting-range-max must be less than that). hmm i have tested varying min-range max-range - by shifting ranges i can get the 'egging issue' to move up/down a ppem size, so the issue persists but just at different ppem's. The adverse effects of having a very small value for hinting-range-max must be analyzed also; it essentially means that some horizontal segments which at larger ppem values no longer align are still treated as edges. Maybe it helps if I introduce options to manipulate the `gasp' table, making it possible to set an upper limit for applying hints. From my experience i doubt that the gasp table will hold any magic bullets, especially under DirectWrite. Finally, I don't know yet whether it makes sense to directly manipulate the 3/4 pixels limit (perhaps by deactivating this threshold completely). This needs further testing. Worth a try. I have opened up a ttfautohint version of Ubuntu Font in FontLab, where i can use a 'gridfit' mode (just as in FontForge) but i can also add Visual TrueType commands and see the resulting effect on the pixels. So i tested the 'o' glyph. It seems to me that the egging issue is caused by the top curves of the 'o' snapping to the top edge of the pixel that corresponds to that alignment zone, if i force these curves to snap to the bottom edge of the alignment zone pixel then the egging is fixed! Of course then i need all pixels in the alignment zone to snap to the bottom of the pixel to get uniform x-height throughout all glyphs. Could there be a way to force pixel snapping to the bottom of pixel in some alignment zones like this with ttfautohint? many thanks -vernon ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] .gitignore in release tarballs
Marek Kasik mka...@redhat.com writes: our building system warned me that there are .gitignore files distributed in release tarballs of freetype. Could you remove them in upcoming releases? Why should .gitignore files be removed from release tarballs? They're part of the source code. A build system that warns about them would seem to be broken. -Miles -- Next to fried food, the South has suffered most from oratory. -- Walter Hines Page ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
