Re: Release Objectives

On 19-06-14 20:17, [email protected] 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