Requirements for new GPC replacement

	+ Numericaly stable - the libart intersector hasn't crapped out yet - DONE
	+ Handle self intersection - DONE
	+ Handles full range of ops: XOR etc. - DONE
	+ Of same order as gpc - DONE

	+ Plug in API compatible replacement for gpc (optional) -
	decided against this; IMO it is better to modify
	vcl/source/gdi/poly2.cxx directly than marshal the polygons
	twice (PolyPolygon -> GPC -> libart) and reverse.

	+ License compatible with StarOffice so we can fold it
	  into CVS and have a single source base (optional) - libart
	  is LGPL.  Is this good enough?

GPC - licensing problems,
    - 'Free for non-commercial use' [ is it [L]GPL compatible ? ]

gpc:
	only used in vcl/source/gdi/poly2.cxx 
	cf. vcl/inc/poly*

Found a GPL-ed, Java implementation of the Bentley-Ottman line
intersection algorithm: http://www.solyanik.com/sergey/sweep11/
Along with the Hobby paper on how to tweak that particular algorithm
for robustness against degeneracies, we could possibly Fix(tm) libart
or at least have a good intersection backend for a new clipping
algorithm.

Random notes:

	- Libart does not implement art_svp_minus().  I implemented
	it; patch is waiting approval from Raph.  Put this in the
	our patch anyways so we have full functionality.

	- Do Metafont or Metapost include polygon clippers?  Will look
        for these.

Vatti, B.R., "A Generic Solution to Polygon Clipping",
Communications of the ACM, 35(7), July 1992, pp.56-63.

[ can we bring pressure to bear on this chap to LGPL it ? ]
external/gpc/gpc.[ch] from http://www.cs.man.ac.uk/aig/staff/alan/software/

http://www.faqs.org/faqs/graphics/algorithms-faq/

Sticking point is Self Intersecting Polygons (perhaps) cf.
http://home.attbi.com/~msleonov/pbcomp.html

A paper on the subject is here:
http://davis.wpi.edu/~matt/courses/clipping/


PolyPolygon - mostly used in 

PolyPolygon::GetIntersection - no '->' refs

[valid hits:]
./vcl/source/gdi/outdev4.cxx:178:               rPolyPoly.GetIntersection( *pClipPolyPoly, *pPolyPoly );
./vcl/source/gdi/poly.cxx:1240: aTmp.GetIntersection( rPolyPoly, rResult );
./svtools/source/filter.vcl/wmf/winmtf.cxx:89:          aPolyPoly.GetIntersection( aPolyPolyRect, aIntersection );
./svtools/source/filter.vcl/wmf/winmtf.cxx:126:                         aPolyPoly.GetIntersection( rPolyPolygon, aNewClipPath );
./svtools/source/filter.vcl/wmf/winmtf.cxx:989:         aClipPath.GetClipPath().GetIntersection( aPolyPolyRect, aDest );
./svtools/source/filter.vcl/wmf/winmtf.cxx:1138:                        aClipPath.GetClipPath().GetIntersection( aPolyPoly, aDest );
./svtools/source/filter.vcl/wmf/winmtf.cxx:1185:                        aClipPath.GetClipPath().GetIntersection( rPolyPolygon, aDest );

PolyPolygon::GetUnion - [ a different GetUnion ]:

[valid hits:]
./vcl/source/gdi/poly.cxx:1248: aTmp.GetUnion( rPolyPoly, rResult );
./svtools/source/filter.vcl/wmf/winmtf.cxx:117:                         aPolyPoly.GetUnion( rPolyPolygon, aNewClipPath );

PolyPolygon::GetDifference - no '->' refs

./vcl/source/gdi/poly.cxx:1256:    aTmp.GetDifference( rPolyPoly, rResult );
./svtools/source/filter.vcl/wmf/winmtf.cxx:102:         aPolyPoly.GetDifference( aPolyPolyRect, aDifference );
./svtools/source/filter.vcl/wmf/winmtf.cxx:123:                         aPolyPoly.GetDifference( rPolyPolygon, aNewClipPath );

PolyPolygon::GetXOR - no '->' refs

./vcl/source/gdi/poly.cxx:1264:     aTmp.GetXOR( rPolyPoly, rResult );
./svtools/source/filter.vcl/wmf/winmtf.cxx:120:                         aPolyPoly.GetXOR( rPolyPolygon, aNewClipPath );

Would the 'Java2D' code be equally good; can we make it Free Software ?

OutputDevice::ImplDrawPolyPolygon
	Uses GetIntersection - unused outside of outdev4.cxx

OutputDevice::ImplDrawPolygon - unused outside of outdev4.cxx
	OutputDevice::ImplDrawLinearGradient

OutputDevice::ImplDrawComplexGradient - clip-poly is the outline,
	OutputDevice::DrawGradient
	OutputDevice::AddGradientActions [ but with no clippoly ]

	clip-poly == the outline;
	We do thousands of redundant clipping ops here.



<saint> _michael: he doesn't, from my own legal perspective.
<saint> _michael: that's why I contacted the univ as well
<_michael> saint: ok; so a secondary problem is that it's not his to say ;-)
<saint> and they implied that they were happy for alan to grant exemptions.
<saint> but its just not clear enough
<saint> and on the issue of relicensing under either GPL or LGPL for future projects...
<saint> the uni said they were planning to review this at some point in the future
<reals> i think the situation is that while the uni owns the copyright (so we can't get around it all by just having him sign JCA), they also have granted him the ability to grant licences
<_michael> saint: well; it's possible to get in touch with the university of Manchester quite easily;
<saint> reals: but not having seen documentation to "prove" that, it never pays to assume anything....
<saint> _michael: sure.
<_michael> saint: is Alan adverse to 'L' GPLing it ?
<_michael> saint: does he make money out of it ? did you glean any more from them ?
<saint> his response above seemed to be firm to me...
<saint> the university makes money out of it now
<_michael> saint: oh, grief - that sucks.
<saint> :-)
<_michael> saint: so we're sunk.
<_michael> saint: as soon as the beaurocrats see it as a revenue stream ...
<saint> that is why I didn't really pursue it much further at the time.
<_michael> saint: thanks for being so helpful ( & clueful )
<saint> no prob.   we've got to work together on this stuff! :-)
<_michael> saint:  it turns out that [AFAICS] gpc is used in 2 places
<reals> saint: yes, well, essentially there are lots of pieces (not just gpc, also jpeg, zlib, etc) that any commercial distro has to assure themselves they are fine shipping 
<_michael> saint: 1) Rendering gradients - this is done horrilby inefficiently
<saint> _michael: two places now?  I thought it was only one?
<_michael> saint: 2) Importing wmf - this is quite vital for Powerpoint etc.
<saint> reals: absolutely....  its getting a real mess these days w/ patents.
<_michael> saint: well - it's wrapped in VCL, I just chased where that was used.
<saint> reals: mp3 being a great example
<saint> ahh interesting
<saint> the gradients I was aware of
<saint> but not the implication for wmf
<_michael> saint: the gradient code is pretty horribly inefficient AFAICS,
<saint> _michael: libart seems to me to me the closest thing resembling a "replacement".
<saint> :-/
<reals> i think it may also at some point conceivably be used in the cvg and pdf filters
<saint> reals: mmmm
<reals> s/cvg/svg/
<_michael> saint: the problem is - winding back the code and seeing what constrains we have on the polygons we render gradients in.
<_michael> saint: since gpc is extremely accepting of odd, self-intersecting, convex, etc. input.
<saint> ksvg uses libart as I recall.
<saint> _michael: right....
<saint> not sure what other alternatives exist for gpc at this time.
<saint> i.e. other than _maybe_ libart, or an adaption of libart, I know of none myself...
<saint> it would make a good potential university project for somebody.
<_michael> saint: either way - getting gpc GPL'd would be a solution - inasmuch as it would suit the university and us ?
<_michael> saint: yes; that's another option,
<saint> _michael: that would be perfect - getting gpc GPL'd...
<_michael> saint: I could try grabbing someone at Cambridge to poke at it,
<_michael> saint: ultimately it's implementing someone else' algorithem,
--- saint is now known as |
<|> No. I didn't. I tried multclip library that is more close to gpc, but
<|> it didn't support self-intersecting polygons.
--- | is now known as saint
<saint> that was from Peter Novodvorsky.
<_michael> right; and I assume that's vital -
<saint> right.
<_michael> looking at what happens with a gradient in a user-drawn polygon,
<saint> so that's not an option either
* _michael wonders
<_michael> why am I not getting debug spew on the console,
<saint> _michael: because your machine is turned off? ;-)
<_michael> does OpenOffice do some IO re-direction somewhere ?
<saint> Kevin Hendricks was looking at writing a replacement for gpc....
<saint> but last time I checked has not made much progress.
<reals> I'd be suprised if he found the time now that 'school' has started again 
<saint> _michael: I just saw your e-mail :-)
<_michael> saint: the annoying thing about clippoly
<_michael> saint: is that there is (was) an LGPL 'C' version by Leonov, but then he disappeared
<_michael> saint: but possibly the algorithem is fundamentally no-good for SI
<_michael> I wonder if Manchester's 'GNU Maverik' contains the same functionality.
<saint> mmeeks@gnu.org, right?
* saint is going to forward an e-mail
<_michael> saint: yes.
<_michael> saint: or michael@ximian.com is better.
<_michael> saint: yes.
<_michael> saint: or michael@ximian.com is better.
<saint> ok
<_michael> reals: has anyone answered my 'how does libgcc_s get there' question yet ?
<saint> _michael: check your e-mail
--> waratah (~ken@c17521.rivrw4.nsw.optusnet.com.au) has joined #OpenOffice.org
<_michael> typedef enum { TETLEY, PG_TIPS, EARL_GREY } MAV_teabag;
<_michael> :-)
* _michael sucks mail reluctantly.
<saint> lol
