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.

@Designer1 Can you upload your actual file. It is likely that there is a maths precision issue affecting that specific character glyph. I can only know for sure by debugging it. Can you also convert your text to curves before uploading. Thanks.

That's some top grade work, Sir! Why you going to leave us? It's seeing quality like this that makes me remember why I toil away blood, sweat and tears working on the vector tools. Hell - if it'll keep you around, I'll get to work cloning Buster Crabbe, so that we can make you lead artist on a new Flash Gordon movie serial.

If you have a file that demonstrates the crash, please submit it so that we can see what is causing the problem.

And this is the correct answer!

This will be because all angles are represented internally as radians. We then convert them to degrees using a*180/pi. That leads to a small amount of error in floating point precision. The error is small enough not to matter in real terms. In this example - the angle is not about the circle, but the arc start/end when presenting a pie shape. As Walt also says - we use cubic bezier quadrant approximations for a circle/ellipse - so there is an element of error in the outline compared to a mathematically true circle.

@Pšenda This is not the issue. We have all the checks possible to allow saving files to any storage medium (in fact, more than most software). The issue lies in the way that USB attached storage buffers data to later be written to physical storage. We will have finished writing the file with no error messages coming back from the Operating System. The *actual* write to the physical hardware happens at a later time that is out of our control - there is additional management of the hardware performed by device drivers, etc. This is one of the reason why you MUST dismount external drives BEFORE disconnecting them. We rarely (if ever) see these kind of corruptions happening on local storage, and that is why we advise people to work on local storage (which is also faster). Attached storage is good for duplicated backups, and we recommend that also. If a file fails to write during our saving process, we have checks and mitigation for that - as well as disconnected network shares, changes in access/permissions, out of space, etc. What we have no control over is what happens to the file after the saving process completes.

If the start of the file has been overwritten with zeros, then it will be missing vital data and can't be fixed.

It is.

Is there an error code?

We don't snap between geometry, only bounds of an object. The exception is for points when using the Node tool, or positioning the corner of an object bounding box. You can use the Node tool, and snap a guide to the nodes and handles of the currently selected curve objects. I think you only need to select the object, not the individual handles for that to work. (off the top of my head I can't recall if I added this for 1.8 or if it's already in 1.7). I could add snapping of guides (conceptually any infinite line) to curves in an object, BUT that snap could potentially have many potential targets. To now, people have been happy with snapping to bounds.