Release Objectives

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Release Objectives

Frank Trampe
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

mskala
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Just Fill Bugs
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Frank Trampe
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, <[hidden email]> 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
Joe
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Joe
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
Joe
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Joe
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

mskala
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Kristof Bastiaensen-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Frank Trampe
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Kristof Bastiaensen-2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

mskala
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Kristof Bastiaensen-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

mskala
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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Dave Crossland

On 20 June 2014 08:30, <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Release Objectives

Kristof Bastiaensen-2
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
Reply | Threaded
Open this post in threaded view
|

Overlap removal

Kristof Bastiaensen-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Overlap removal

newsletter-59
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
Reply | Threaded
Open this post in threaded view
|

Re: Overlap removal

Dave Crossland
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
Reply | Threaded
Open this post in threaded view
|

Re: Overlap removal

Kristof Bastiaensen-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Overlap removal

Kristof Bastiaensen-2
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
12