Ben

He came up with that example, because that's what I gave him in way of an explanation. When using the cusped version, the spiral is formed from straight lines. The partial turn in this case is a percentage of the distance along these straight lines for a single 'turn'. To express this as an angle about a notional centre is less meaningful when the geometry is not an arc. Using an angle would result in non-linear interpolation of the straight line segments. Note, a 'turn' is a complete lap around, not a segment or arc. Since arc angles (or more accurately, the circle divisor angle) can be arbitrary, a turn is determined as being independent of the arc angle for simplicity. So - you can specify a spiral of 2 turns (a notional rotation of 720 degrees) but then set the arc angle to whatever value gives you the visual result you want.

Yes, because it is the only curved spiral that finishes in the centre of the shape - all other curved spirals have a non-centred end. The plotted one achieves this (currently) at the expense of it using straight lines to link the procedurally placed points.

I can look into on-canvas controls, but not all values/properties can be easily represented with a control point.

Yes - the construction for a Phi spiral would be fundamentally different to Fibonacci. The Fibonacci we build from the centre following the sequence. A Phi spiral would be a constant scaling from the outside. I'll have a think. Actually - try using the Decaying spiral, set "Decay per segment" and use 100-(100/phi) for the Decay value. I could probably add this as a preset. We do have a continuous spiral - it's the plotted one. Each point is correctly placed. Currently it's line segments only (though you can increase that to add accuracy). If I can figure out the maths for correct(ish) curve segments I'll add it.

Adobe does not publish the internal workings of their text engine. Without this proprietary knowledge it is almost impossible for us to export editable text to PSD.

Having played with the Live Paint feature in AI, it does seem to get very confused very quickly. It's sort of OK until you change the geometry a lot, then it doesn't really know where you intended the fill to be. The feature also regroups your layers - so will change any ordering you might have had. Fine, unless your ordering was exposed by occluded fills and strokes. So, our approach doesn't mess with your original layer ordering (apart from if you insert fill layers in-between). Also, we create post-editable fill objects - so when you are done, you can treat them like any other layer.

This is a (welcome) side-effect in some ways. The new objects you created to do the internal fills are like any other curve object. So, the 'click to select and fill' method works on them in exactly the same way. When you click it will find the top most filled object at the mouse position - in this case it happens to be an area fill you made previously.

It's what I do.

This will be fixed in 2.1.

Yes- different platforms are likely to have subtly different fonts. They may have the same name, but might be produced differently. As I stated before - the specific error with failure to perform the bool op is down to edge case calculations as a result of possibly only one or two curves in the font glyphs. This will be rectified in 2.1.

@lacerto I suggest you wait for the fixes that will be coming in 2.1. This will address the mathematical problems affecting font glyphs and boolean ops. Issues with fonts not being filled correctly during Divide ops is a separate issue that will be looked into.

That will be because I haven't actually released a fix yet. I said I was working on it - not that it had gone live.

No - I'm referring to anything that modifies the geometry, such as using the contour tool to create curves that are slightly different.

The workarounds are going to ruin your geometry. Anyone is free to apply this as a temporary measure, but it's less than ideal. We wouldn't look to incorporating this as a solution in our code.

Thanks for the file. The issue is exactly what I suspected. We are seeing some precision issues with very specific types of curves. Unfortunately, fonts seem to exhibit these forms of curves more than anything else - curves that are almost symmetrical, but less than a complete 1/4 circle arc. In a nutshell - there is a calculation we do that uses some complicated maths for polynomial root finding - these curves produce numbers that get very large in the calculation and exceed the limits of what a 64-bit computer can handle without loosing vital precision. Creating these test cases was difficult - they just happen by an unfortunate combination of input geometry, and hard to predict. But, the method we are using produces much more overall accurate results than other software might do (we give you a zoom to over 1,000,000%, and we try to ensure that anything you do looks precise even past that zoom level). I am working on a solution to this issue that balances the needs of precision and speed.