Ben

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.