collinear wires

[GoogleCodeExporter]

Toped has to "learn" to cope with collinear wires containing one or more angles 
equal to Pi.
A simple example of such object:
addwire({{0,0},{0,400},{400,500},{400,0},{800,0}}, 130);

Point lines of such type are corrected when applied to polygons because they 
simply contain points which does not overlap any area. 
For the case of wires though (although not quite nice) such point sequences 
shall be considered valid. The reason is the same as above. They do produce an 
effective area and if filtered out the resulting object is different form the 
intended one. Which is bad!

The whole wire processing however presumes that such objects will be kept away 
from the DB. If they are treated as a normal wires there will be all kind of 
troubles starting from the validation and ending with the rendering. It seems 
that this kind of objects shall be covered by a new class (TdTData ancestor) 
which can implement the specific checks and processing fro them. One reason 
just from the top of my head is that the equivalent polygon describing those 
objects might have number of points different from 2*n. 

Original issue reported on code.google.com by krustev....@gmail.com on 16 Jun 2010 at 10:00

• Blocking: #55

[GoogleCodeExporter]

A number of changes to make the wire type described above acceptable for the 
data base. The issue was also used to consolidate all the wire contour algos 
across the project in a single one. Updates in r1548, r1549, r1550, r1553, 
r1554, r1555, r1556, r1557, r1558.
Wires of this type are still not acceptable if entered manually although the DB 
works fine with them. The problem is that the self-crossing algo marks them as 
self crossing. This should be a subject to another issue though. See further 
comments in Issue 55

Original comment by krustev....@gmail.com on 27 Jun 2010 at 10:00

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by krustev....@gmail.com on 1 Apr 2012 at 12:19

• Changed state: Verified