rikrd / geomerative

Geomerative is a library for Processing. It extends 2D geometry operations to facilitate generative geometry. Includes a TrueType font and an SVG interpreters. This library exposes the shapes (such as vector drawings or typographies) in a more approchable way. Geomerative makes it easy to access the contours, the control points and the curve points, making it easy to develop generative typography and geometry pieces in Processing.
http://www.ricardmarxer.com/geomerative
GNU General Public License v3.0
176 stars 29 forks source link

SVG loading - Protect against ArrayIndexOutOfBoundsException (-1) as seen in https:… #10

Closed euphy closed 5 years ago

euphy commented 5 years ago

…//github.com/rikrd/geomerative/issues/9.

Very simple fix - but I want to let you know that I had to make some other (irrelevant, I think) changes to other parts of the project to get this to compile locally - and that's why I haven't included a fresh geomerative.jar.

There are a few places where you have something like:

int smooth = g.smooth;
...
if(smooth > 0){ 
...}

Where g is a PGraphics. That would not compile for me (core.jar from processing 2.2.1), I get an error saying that PGraphics.smooth is a boolean ("error: incompatible types: boolean cannot be converted to int").

Changing these instances to a boolean like this:

boolean smooth = g.smooth;
...
if(smooth){ 
...}

Means it compiles fine.

The source for PGraphics says it's an int (https://github.com/processing/processing/blob/master/core/src/processing/core/PGraphics.java#L176). And your code (treating it as an int) ran fine on my machine.

However, compiling Geomerative using your ant scripts on my installation does not like it.

So I can add those changes to the PR if you like, along with the compiled geomerative.jar... But I'm reluctant to do that because I don't want to break it for everyone except me!

Let me know if you'd like that, or for me to do some more experimenting.

sn

rikrd commented 5 years ago

Thanks!

wrt g.smooth, I think it is because you are still on Processing 2.x and this may be something they introduced in Processing 3.x, but I'm not sure about it.

euphy commented 5 years ago

Yes I couldn't really track back to when it changed from being a boolean to an int, guessed it was a 2 vs 3 thing. But can't quite see why it works ok running from the jar with ints, but not when compiling against it. I wonder if that's because both versions compile down to the same bytecode!