# Release Objectives

40 messages
12
Open this post in threaded view
|

## Release Objectives

 Greetings.As we start to plan for a Fontforge release in the next month or two, I want to make sure that we have fixed as many big bugs as possible before said release. I would appreciate reminders on this thread of any bugs in the current master branch that cause highly undesirable behavior (such as crashes) and are easily reproducible. I'm happy to look at any other seemingly low-hanging fruit as well. Best wishes,Frank ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 On Tue, 17 Jun 2014, Frank Trampe wrote: > As we start to plan for a Fontforge release in the next month or two, I want > to make sure that we have fixed as many big bugs as possible before said > release. I would appreciate reminders on this thread of any bugs in the > current master branch that cause highly undesirable behavior (such as > crashes) and are easily reproducible. I'm happy to look at any other > seemingly low-hanging fruit as well. I'm not sure it fits the definition of low-hanging fruit, but incorrect results from "Remove Overlaps" have been the highest priority issues for me for as long as I've been involved with the project. These problems are reasonably easy to reproduce, usually cross-platform, the effects are visible in the created fonts (which I think qualifies as "highly undesirable behaviour"; fonts processed by FontForge are unusable in the worst case), and there's no predictable way to work around such problems by changing the workflow, nor other free software known to me that could substitute for FontForge in doing the remove-overlap function. -- Matthew Skala [hidden email]                 People before principles. http://ansuz.sooke.bc.ca/------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 On 06/18/14 01:43, [hidden email] wrote: > > These problems are reasonably easy to reproduce, usually cross-platform, > the effects are visible in the created fonts (which I think qualifies as > "highly undesirable behaviour"; fonts processed by FontForge are unusable > in the worst case), and there's no predictable way to work around such > problems by changing the workflow, nor other free software known to me > that could substitute for FontForge in doing the remove-overlap function. > I guess a brutal force  way to detect failed remove-overlap operation was to render the outline into bitmap and compare the before/after bitmaps. If the deviation was too big, redo the remove-overlap operation with different setttings. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 In reply to this post by mskala This is likely to be one of the most difficult things to solve. The lack of comments in the long geometry functions does not help. I know that we need to solve it, and it is on my list. On Tue, Jun 17, 2014 at 12:43 PM, wrote: On Tue, 17 Jun 2014, Frank Trampe wrote: > As we start to plan for a Fontforge release in the next month or two, I want > to make sure that we have fixed as many big bugs as possible before said > release. I would appreciate reminders on this thread of any bugs in the > current master branch that cause highly undesirable behavior (such as > crashes) and are easily reproducible. I'm happy to look at any other > seemingly low-hanging fruit as well. I'm not sure it fits the definition of low-hanging fruit, but incorrect results from "Remove Overlaps" have been the highest priority issues for me for as long as I've been involved with the project. These problems are reasonably easy to reproduce, usually cross-platform, the effects are visible in the created fonts (which I think qualifies as "highly undesirable behaviour"; fonts processed by FontForge are unusable in the worst case), and there's no predictable way to work around such problems by changing the workflow, nor other free software known to me that could substitute for FontForge in doing the remove-overlap function. -- Matthew Skala [hidden email]                 People before principles. http://ansuz.sooke.bc.ca/ ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 In reply to this post by Just Fill Bugs On June 19, 2014 03:38:53 AM Just Fill Bugs wrote: > I guess a brutal force  way to detect failed remove-overlap operation > was to render the outline into bitmap and compare the before/after > bitmaps. If the deviation was too big, redo the remove-overlap > operation with different setttings. Let's avoid that if we can. Use Libspiro to turn the complex curves into simpler curves. Then it is a matter of figuring out which curve intersects what curve. When you've figured-out which curve crosses which curve, then you use a bit of algebra to find the crossover point. Straight lines should be simpler. Hand-drawn pencil scratchings maybe more complex. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 In reply to this post by Frank Trampe On June 19, 2014 07:39:30 AM Frank Trampe wrote: > This is likely to be one of the most difficult things to solve. The lack > of comments in the long geometry functions does not help. I know that > we need to solve it, and it is on my list. Resolve the easier issues first, make them more solid before tackling the tougher problems. Some of these tougher problems depend on many other routines, and it's a bit disappointing to try fix something when you have to spread yourself thin into the sub-routines. Comments certainly help. If not you, atleast the next person looking at that routine, for your problem, or something else that uses the same routine. Comment, comment, comment where you can. I've noted others have gone and improved and fixed stuff I've commented earlier. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 In reply to this post by Joe On Thu, 19 Jun 2014, Jose Da Silva wrote: > > I guess a brutal force  way to detect failed remove-overlap operation > > was to render the outline into bitmap and compare the before/after > > bitmaps. If the deviation was too big, redo the remove-overlap > > operation with different setttings. > > Let's avoid that if we can. I tried to implement that in Tsukurimashou, and it didn't work very well. I'm not sure what the current state of those tests is - it's been a while since I've touched them - but the code still exists, can be enabled with the appropriate configuration options, and I'd encourage interested parties to get a copy of Tsukurimashou and try it.  Issues 474 and 685 made the whole thing more difficult. > Then it is a matter of figuring out which curve intersects what curve. > When you've figured-out which curve crosses which curve, then you use a bit > of algebra to find the crossover point. Much can go wrong and we need to handle ALL the special cases properly. In particular, if you calculate the intersection point of two spline segments, because of numeric precision the point you calculate may not actually be exactly on either segment. If you split a segment A into two segments B and C, their end points may not actually be exactly at the intersection point you intended to use as the split point.  Then an intersection calculated against B might give you a point that is in effect a point on C; or an intersection that should be exactly at the endpoint of B may instead be within the interior of B, causing you to split B again, recursively, and create a very short segment. If you have two segments that coincide, you have to recognize that - and there may be cases where two segments *nearly* coincide (because, for instance, they both represent arcs of the same circle [splines can't represent circles exactly]) but due to numeric precision and the inherent limitations of the spline approximation they are not bit for bit identical.  If you don't use a tolerance and call them coincident when they're not, then you end up splitting them at all the many points where they cross, and because the differences between them were at the limits of your precision anyway, the resulting split-down segments will flail around due to rounding error and be likely to trigger other bugs. It may be a miracle it currently works as well as it does. > Straight lines should be simpler. With straight lines you're especially likely to run into issues of coincident segments.  There are also issues from lines that are meant to be straight but are not perfectly so. -- Matthew Skala [hidden email]                 People before principles. http://ansuz.sooke.bc.ca/------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 On 19-06-14 17:38, [hidden email] wrote: > On Thu, 19 Jun 2014, Jose Da Silva wrote: >>> I guess a brutal force  way to detect failed remove-overlap operation >>> was to render the outline into bitmap and compare the before/after >>> bitmaps. If the deviation was too big, redo the remove-overlap >>> operation with different setttings. >> Let's avoid that if we can. > I tried to implement that in Tsukurimashou, and it didn't work very well. > I'm not sure what the current state of those tests is - it's been a while > since I've touched them - but the code still exists, can be enabled with > the appropriate configuration options, and I'd encourage interested > parties to get a copy of Tsukurimashou and try it.  Issues 474 and 685 > made the whole thing more difficult. > >> Then it is a matter of figuring out which curve intersects what curve. >> When you've figured-out which curve crosses which curve, then you use a bit >> of algebra to find the crossover point. > Much can go wrong and we need to handle ALL the special cases properly. > > In particular, if you calculate the intersection point of two spline > segments, because of numeric precision the point you calculate may not > actually be exactly on either segment. > > If you split a segment A into two segments B and C, their end points may > not actually be exactly at the intersection point you intended to use as > the split point.  Then an intersection calculated against B might give you > a point that is in effect a point on C; or an intersection that should be > exactly at the endpoint of B may instead be within the interior of B, > causing you to split B again, recursively, and create a very short > segment. > > If you have two segments that coincide, you have to recognize that - and > there may be cases where two segments *nearly* coincide (because, for > instance, they both represent arcs of the same circle [splines can't > represent circles exactly]) but due to numeric precision and the > inherent limitations of the spline approximation they are not bit > for bit identical.  If you don't use a tolerance and call them coincident > when they're not, then you end up splitting them at all the many points > where they cross, and because the differences between them were at the > limits of your precision anyway, the resulting split-down segments will > flail around due to rounding error and be likely to trigger other bugs. > > It may be a miracle it currently works as well as it does. You can use the bezier clipping algorithm to robustly find the intersections between two bezier curves (see http://tom.cs.byu.edu/~557/text/cagd.pdf) This is also used by inkscape and lib2geom.  I have implemented it in my haskell library https://github.com/kuribas/cubicbezierThe two curves may have an infinite number of overlaping points, if they represent the same polynomial. This will be obviously the case when the two curves have the same control points. It's also possible when they are the same polynomial, but with different control points, but this is very unlikely. This should be checked before calculating overlapping points. If you have a design with nearly coincident segments, that may give many control points, but why would anyone use that in a design? The maximum number of points that coincide for two (non-identical) segments is 9, so that shouldn't cause any crashes. Kristof >> Straight lines should be simpler. > With straight lines you're especially likely to run into issues of > coincident segments.  There are also issues from lines that are meant to > be straight but are not perfectly so. > ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 With the right documentation and some advice from you, it may be easier to reimplement some of these things than to reverse engineer the existing code. On Thu, Jun 19, 2014 at 12:21 PM, Kristof Bastiaensen wrote: On 19-06-14 17:38, [hidden email] wrote: > On Thu, 19 Jun 2014, Jose Da Silva wrote: >>> I guess a brutal force  way to detect failed remove-overlap operation >>> was to render the outline into bitmap and compare the before/after >>> bitmaps. If the deviation was too big, redo the remove-overlap >>> operation with different setttings. >> Let's avoid that if we can. > I tried to implement that in Tsukurimashou, and it didn't work very well. > I'm not sure what the current state of those tests is - it's been a while > since I've touched them - but the code still exists, can be enabled with > the appropriate configuration options, and I'd encourage interested > parties to get a copy of Tsukurimashou and try it.  Issues 474 and 685 > made the whole thing more difficult. > >> Then it is a matter of figuring out which curve intersects what curve. >> When you've figured-out which curve crosses which curve, then you use a bit >> of algebra to find the crossover point. > Much can go wrong and we need to handle ALL the special cases properly. > > In particular, if you calculate the intersection point of two spline > segments, because of numeric precision the point you calculate may not > actually be exactly on either segment. > > If you split a segment A into two segments B and C, their end points may > not actually be exactly at the intersection point you intended to use as > the split point.  Then an intersection calculated against B might give you > a point that is in effect a point on C; or an intersection that should be > exactly at the endpoint of B may instead be within the interior of B, > causing you to split B again, recursively, and create a very short > segment. > > If you have two segments that coincide, you have to recognize that - and > there may be cases where two segments *nearly* coincide (because, for > instance, they both represent arcs of the same circle [splines can't > represent circles exactly]) but due to numeric precision and the > inherent limitations of the spline approximation they are not bit > for bit identical.  If you don't use a tolerance and call them coincident > when they're not, then you end up splitting them at all the many points > where they cross, and because the differences between them were at the > limits of your precision anyway, the resulting split-down segments will > flail around due to rounding error and be likely to trigger other bugs. > > It may be a miracle it currently works as well as it does. You can use the bezier clipping algorithm to robustly find the intersections between two bezier curves (see http://tom.cs.byu.edu/~557/text/cagd.pdf) This is also used by inkscape and lib2geom.  I have implemented it in my haskell library https://github.com/kuribas/cubicbezier The two curves may have an infinite number of overlaping points, if they represent the same polynomial. This will be obviously the case when the two curves have the same control points. It's also possible when they are the same polynomial, but with different control points, but this is very unlikely. This should be checked before calculating overlapping points. If you have a design with nearly coincident segments, that may give many control points, but why would anyone use that in a design? The maximum number of points that coincide for two (non-identical) segments is 9, so that shouldn't cause any crashes. Kristof >> Straight lines should be simpler. > With straight lines you're especially likely to run into issues of > coincident segments.  There are also issues from lines that are meant to > be straight but are not perfectly so. > ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 Ok, I'll make a roadmap for the overlap removal algorithm. On 19-06-14 19:49, Frank Trampe wrote: With the right documentation and some advice from you, it may be easier to reimplement some of these things than to reverse engineer the existing code. On Thu, Jun 19, 2014 at 12:21 PM, Kristof Bastiaensen wrote: On 19-06-14 17:38, [hidden email] wrote: > On Thu, 19 Jun 2014, Jose Da Silva wrote: >>> I guess a brutal force  way to detect failed remove-overlap operation >>> was to render the outline into bitmap and compare the before/after >>> bitmaps. If the deviation was too big, redo the remove-overlap >>> operation with different setttings. >> Let's avoid that if we can. > I tried to implement that in Tsukurimashou, and it didn't work very well. > I'm not sure what the current state of those tests is - it's been a while > since I've touched them - but the code still exists, can be enabled with > the appropriate configuration options, and I'd encourage interested > parties to get a copy of Tsukurimashou and try it.  Issues 474 and 685 > made the whole thing more difficult. > >> Then it is a matter of figuring out which curve intersects what curve. >> When you've figured-out which curve crosses which curve, then you use a bit >> of algebra to find the crossover point. > Much can go wrong and we need to handle ALL the special cases properly. > > In particular, if you calculate the intersection point of two spline > segments, because of numeric precision the point you calculate may not > actually be exactly on either segment. > > If you split a segment A into two segments B and C, their end points may > not actually be exactly at the intersection point you intended to use as > the split point.  Then an intersection calculated against B might give you > a point that is in effect a point on C; or an intersection that should be > exactly at the endpoint of B may instead be within the interior of B, > causing you to split B again, recursively, and create a very short > segment. > > If you have two segments that coincide, you have to recognize that - and > there may be cases where two segments *nearly* coincide (because, for > instance, they both represent arcs of the same circle [splines can't > represent circles exactly]) but due to numeric precision and the > inherent limitations of the spline approximation they are not bit > for bit identical.  If you don't use a tolerance and call them coincident > when they're not, then you end up splitting them at all the many points > where they cross, and because the differences between them were at the > limits of your precision anyway, the resulting split-down segments will > flail around due to rounding error and be likely to trigger other bugs. > > It may be a miracle it currently works as well as it does. You can use the bezier clipping algorithm to robustly find the intersections between two bezier curves (see http://tom.cs.byu.edu/~557/text/cagd.pdf) This is also used by inkscape and lib2geom.  I have implemented it in my haskell library https://github.com/kuribas/cubicbezier The two curves may have an infinite number of overlaping points, if they represent the same polynomial. This will be obviously the case when the two curves have the same control points. It's also possible when they are the same polynomial, but with different control points, but this is very unlikely. This should be checked before calculating overlapping points. If you have a design with nearly coincident segments, that may give many control points, but why would anyone use that in a design? The maximum number of points that coincide for two (non-identical) segments is 9, so that shouldn't cause any crashes. Kristof >> Straight lines should be simpler. > With straight lines you're especially likely to run into issues of > coincident segments.  There are also issues from lines that are meant to > be straight but are not perfectly so. > ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel  ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 In reply to this post by Kristof Bastiaensen-2 On Thu, 19 Jun 2014, Kristof Bastiaensen wrote: > If you have a design with nearly coincident segments, that may give > many control points, but why would anyone use that in a design? It's very likely to happen in fonts that originate from stroking paths with a pen.  If I define three line-segment paths for the letter A, stroke each one with an identical circular pen to get three closed paths, and then do "remove overlaps," then at the top there's be a case of two different spline segments both attempting to approximate different, but overlapping, arcs of the same circle.  This kind of thing happens all the time in my METAFONT-generated fonts, and it's a huge headache trying to avoid it.  I think "ilyaza" on Github has posted some examples of similar things in his own fonts. > The maximum number of points that coincide for two (non-identical) > segments is 9, so that shouldn't cause any crashes. After you compute those points, split the splines at them, and unavoidably round off to machine precision, there's some danger of new intersections being created.  I've seen at least one infinite loop (now fixed, I think) caused by this kind of situation, where it would find an intersection, split the spline, then find the same intersection within the new spline because of precision issues, split it again, and repeat until resource exhaustion. My opinion is that the best way to deal with such issues is to build a graph of all the segments and intersections once at the start, before you modify anything, ensure consistency of that graph, and then not do any kind of recursive intersection operations on later-created segments.  The existing code sort of works this way but doesn't seem to have been fully thought out.  Rewriting it from scratch is probably a good plan, but it'll probably be at least a year before there's any significant chance I could do or significantly participate in that myself. -- Matthew Skala [hidden email]                 People before principles. http://ansuz.sooke.bc.ca/------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 On 19-06-14 20:17, [hidden email] wrote: > On Thu, 19 Jun 2014, Kristof Bastiaensen wrote: >> If you have a design with nearly coincident segments, that may give >> many control points, but why would anyone use that in a design? > It's very likely to happen in fonts that originate from stroking paths > with a pen.  If I define three line-segment paths for the letter A, stroke > each one with an identical circular pen to get three closed paths, and > then do "remove overlaps," then at the top there's be a case of two > different spline segments both attempting to approximate different, but > overlapping, arcs of the same circle.  This kind of thing happens all the > time in my METAFONT-generated fonts, and it's a huge headache trying to > avoid it.  I think "ilyaza" on Github has posted some examples of similar > things in his own fonts. > I see.  Couldn't you avoid joining closed paths in the same point when stroking paths?  In the worst case this should give a few unnecessary control points, but not crash the program. >> The maximum number of points that coincide for two (non-identical) >> segments is 9, so that shouldn't cause any crashes. > After you compute those points, split the splines at them, and unavoidably > round off to machine precision, there's some danger of new intersections > being created.  I've seen at least one infinite loop (now fixed, I think) > caused by this kind of situation, where it would find an intersection, > split the spline, then find the same intersection within the new spline > because of precision issues, split it again, and repeat until resource > exhaustion. > > My opinion is that the best way to deal with such issues is to build a > graph of all the segments and intersections once at the start, before you > modify anything, ensure consistency of that graph, and then not do any > kind of recursive intersection operations on later-created segments.  The > existing code sort of works this way but doesn't seem to have been fully > thought out.  Rewriting it from scratch is probably a good plan, but it'll > probably be at least a year before there's any significant chance I could > do or significantly participate in that myself. > I haven't looked at the code, but I would certainly take out the code that does recursive splitting with something saner.  Making separate immutable stages is a good idea anyway, and less prone to bugs. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 On Fri, 20 Jun 2014, Kristof Bastiaensen wrote: > I see.  Couldn't you avoid joining closed paths in the same point when > stroking paths?  In the worst case this should give a few unnecessary > control points, but not crash the program. Not really.  If I have two paths to stroke that join at a point and I change them so that they no longer join, then the change will be visible as a nick in the outline in the final font.  I don't think that's acceptable.  It's also very difficult to require such a condition on all external sources of font data, when I might be working with a font I didn't create.  If the necessary changes to make a font suitable for "Remove Overlaps" cannot be done by scripts, FontForge becomes even less useful.  And the cases that the current code cannot handle are not well-understood enough that we could write a document accurately telling users what they're not allowed to do, anyway. I want to have a "Remove Overlaps" that *really* works, not only when common special-case situations fail to occur. -- Matthew Skala [hidden email]                 People before principles. http://ansuz.sooke.bc.ca/------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 On 20 June 2014 08:30, wrote: I want to have a "Remove Overlaps" that *really* works, not only when common special-case situations fail to occur.I think we are sure to add this over the summer :) ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Release Objectives

 In reply to this post by mskala On 20-06-14 14:30, [hidden email] wrote: > On Fri, 20 Jun 2014, Kristof Bastiaensen wrote: >> I see.  Couldn't you avoid joining closed paths in the same point when >> stroking paths?  In the worst case this should give a few unnecessary >> control points, but not crash the program. > Not really.  If I have two paths to stroke that join at a point and I > change them so that they no longer join, then the change will be visible > as a nick in the outline in the final font.  I don't think that's > acceptable.  It's also very difficult to require such a condition on all > external sources of font data, when I might be working with a font I > didn't create.  If the necessary changes to make a font suitable for > "Remove Overlaps" cannot be done by scripts, FontForge becomes even less > useful.  And the cases that the current code cannot handle are not > well-understood enough that we could write a document accurately telling > users what they're not allowed to do, anyway. > > I want to have a "Remove Overlaps" that *really* works, not only when > common special-case situations fail to occur. > Well, what I meant was to use a single closed path, rather than two closed overlapping paths.  This way the stroking algorithm would take care of that special case.  I agree that the code must work in every case, my point was that the worst that would happen is to have more control points than necessary.  That would be a less critical problem that could be solved later. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Overlap removal

 Hi, what's the best way to share my algorithm?  Is there a colaborative wiki or something, or should I just write it in a text file? Regards, Kristof ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Overlap removal

 Hi Kristof, hi everyone, I'm very keen to see your algorithm too. Because ufoJS (http://lib.ufojs.org/) lacks remove overlap and would profit from it. Maybe I should take chance and implement it alongside with the fontforge implementation. It could be good for the acquisition of knowledge if we work on two separate implementations. What do you think? Lasse On 06/25/2014 01:32 PM, Kristof Bastiaensen wrote: > Hi, > > what's the best way to share my algorithm?  Is there a > colaborative wiki or something, or should I just write > it in a text file? > > Regards, > Kristof > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft> _______________________________________________ > Fontforge-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/fontforge-devel> ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Overlap removal

 In reply to this post by Kristof Bastiaensen-2 You can use the fontforge.github.io website, is a git repo :) On 25 Jun 2014 07:33, "Kristof Bastiaensen" <[hidden email]> wrote: Hi, what's the best way to share my algorithm?  Is there a colaborative wiki or something, or should I just write it in a text file? Regards, Kristof ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
Open this post in threaded view
|

## Re: Overlap removal

 Should I fork the page, or can you add me as a user? My github name is kuribas. Kristof On 25-06-14 15:53, Dave Crossland wrote: You can use the fontforge.github.io website, is a git repo :) On 25 Jun 2014 07:33, "Kristof Bastiaensen" <[hidden email]> wrote: Hi, what's the best way to share my algorithm?  Is there a colaborative wiki or something, or should I just write it in a text file? Regards, Kristof ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel  ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel
 Actually forking isn't a bad idea, since I can edit my pages in emacs, so forget that. Is there a way to add math to the pages, using mathjax for example? A quick lookup suggest that redcarpet doesn't support mathjax, but kramdown does.  Would it be safe to change to that? Kristof On 26-06-14 12:03, Kristof Bastiaensen wrote: Should I fork the page, or can you add me as a user? My github name is kuribas. Kristof On 25-06-14 15:53, Dave Crossland wrote: You can use the fontforge.github.io website, is a git repo :) On 25 Jun 2014 07:33, "Kristof Bastiaensen" <[hidden email]> wrote: Hi, what's the best way to share my algorithm?  Is there a colaborative wiki or something, or should I just write it in a text file? Regards, Kristof ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel  ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel  ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft_______________________________________________ Fontforge-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/fontforge-devel