Re: Release Objectives

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
[email protected]                 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