Boolean operations with letters do not work in Affinity Designer 2.0.3!

[Ben]

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.

[Designer1]

2 hours ago, Ben said:

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.

Thank you for your feedback. The reason why the boolean operations don't work with some fonts is irrelevant to me as a designer. I need a working software to be able to work with it. In Affinity Designer 1.06, the Boolean operations with this letter S work perfectly. Therefore, your reasoning is incomprehensible to me. Just programme Affinity Designer 2.03 as Affinity Designer 1.06.

@BenIn addition, I have reported here several times that the export quality of PNG and JPG is not very good, no matter which settings you choose. Possibly it is also due to this large zoom? Unfortunately, the professional export quality as in Photoshop is not achieved. That is a problem. Perhaps antialiasing settings should be improved so that typography can be exported in awan-free quality.

 

[SrPx]

10 hours ago, Ben said:

The workarounds are going to ruin your geometry

Does this mean that "copy as SVG" preference and "paste special- as SVG" produces inaccurate  geometry? I'd be worried for other workflows, not just this... I mean, supposedly, nothing should ruin the geometry, inside the software... 

[Designer1]

@BenYou have only partially fixed the problem in version 2.04. Cutting the letter S with the knife does not work.

[Ben]

16 hours ago, SrPx said:

Does this mean that "copy as SVG" preference and "paste special- as SVG" produces inaccurate  geometry? I'd be worried for other workflows, not just this... I mean, supposedly, nothing should ruin the geometry, inside the software... 

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

[Ben]

3 hours ago, Designer1 said:

@BenYou have only partially fixed the problem in version 2.04. Cutting the letter S with the knife does not work.

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.

[SrPx]

3 minutes ago, Ben said:

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

Oh, I see. Thank you.

[lacerto]

Frustratingly, this continues to be an issue also in 2.0.4 Windows versions (I have not been able to reproduce these kinds of problems with macOS versions, not with 2.03, nor with 2.0.4). It would be interesting to learn why Windows versions keep on having problems with basic Boolean operations? V2 apps obviously use different code than v 1 apps, but is this a library issue or something related to proprietary code not just yet being "in synch" between the OS versions?

[lepr]

On 1/27/2023 at 11:06 PM, lacerto said:

Frustratingly, this continues to be an issue also in 2.0.4 Windows versions (I have not been able to reproduce these kinds of problems with macOS versions, not with 2.03, nor with 2.0.4).

Same here. I've only seen the problems happen in the macOS apps if a file contains curves converted from text by the Windows software. My inexpert suspicion is something is crucially different about the output of the text-to-curves code in the macOS apps versus Windows apps.

[lacerto]

34 minutes ago, ,,, said:

crucially different about the output of the text-to-curves code in the macOS apps versus Windows apps

Yes, something like this. I have noticed that converting text to curves and then merging the curve elements to a "Curves" object sometimes gives similar (correct) results as operating directly with text objects in macOS versions. But then oddly the operations might fail (on Windows at least) when having former text objects converted to curves and any simple shape object involved in the operation.

Below is a simple v1 and v2 example (that is similar as has been used in another post on the forum related to subtract issues) that can be used to demonstrate and test the Boolean issues. V1 files seem to operate ok (in v1 apps) if the Boolean subtract (and other operations, too) is done non-destructively (as a compound operation) but v2 gives yet additional buggy results even when using compound versions.

 subtract_issue_v01.afdesign

subtract_issue_v02.afdesign

These files seem to be useful in testing other Boolean operations, as well, and most operations seem to be broken in v2 (Windows). In v1 having objects converted to "Curves" objects and then applying compound operation seems to work best. I have not tested these on macOS, but based on superficial tests with other similar files, Boolean operations now seem to work well (or at least much better) on macOS (also better than in v1 version of macOS).

[lepr]

25 minutes ago, lacerto said:

Yes, something like this. I have noticed that converting text to curves and then merging the curve elements to a "Curves" object sometimes gives similar (correct) results as operating directly with text objects in macOS versions. But then oddly the operations might fail (on Windows at least) when having former text objects converted to curves and any simple shape object involved in the operation.

Below is a simple v1 and v2 example (that is similar as has been used in another post on the forum related to subtract issues) that can be used to demonstrate and test the Boolean issues. V1 files seem to operate ok (in v1 apps) if the Boolean subtract (and other operations, too) is done non-destructively (as a compound operation) but v2 gives yet additional buggy results even when using compound versions.

 subtract_issue_v01.afdesign

subtract_issue_v02.afdesign

These files seem to be useful in testing other Boolean operations, as well, and most operations seem to be broken in v2 (Windows). In v1 having objects converted to "Curves" objects and then applying compound operation seems to work best. I have not tested these on macOS, but based on superficial tests with other similar files, Boolean operations now seem to work well (or at least much better) on macOS (also better than in v1 version of macOS).

 

All the following in AD2 on macOS.

Both your documents:

• subtracting rectangle from text -> good geometry result (but old bug of fill wrongly set to none needs to be fixed)
• subtracting rectangle from "Windows curves from text" -> messy geometry result

If I manually convert your text to curves (which happens on the fly, anyway, when using text in a Boolean operation):

• subtracting rectangle from "macOS curves from text" -> good geometry result (and correct fill)

So, this is a further example of the garbage Boolean output appearing to be provoked by something about the text-to-curves output of the Windows apps only.

[lacerto]

Here are more comprehensive test files attached, and some notes on results after performing Boolean operations:

a) On Windows v1 (just as a reference):

• Red color indicates shapes that were left invisible after operation (not really an issue)
• The two elements Boolean operated on each artboard are from top to bottom: frame text + rectangle, art text + rectangle, frame text converted to curves and merged + rectangle converted to curve, and art text converted to a curves and merged + rectangle converted to a curve
• Subtract simple fails when performed on frame and art text, but works if text is first converted to curves and merged; subtract compound works fine
• Intersect simple fails when performed on text (all objects lost)
• Xor simple has issues
• Divide simple has issues when performed on text objects, works fine if text objects are converted to curves and merged; Divide compound fails to divide any objects

b) On Windows v2:

• Subtract simple still fails on operations involving frame text, or former frame text converted to curves and merged
• Xor has issues with frame text and former frame text converted to curves and merged
• Divide works fine only with art text converted to curves and merged

c) On macOS v2, when opening a file where text objects have been converted to.curves and merged on Windows:

• There are issues in Subtract, Xor and Divide when operating with frame text converted to curves and merged
• Divide simple fails with text objects 

d) On macOS v2, when text objects have been converted to curves and merged on mac:

• There are still issues with divide simple when operating with text objects. Divide compound works fine.

What is strange is that the results are clearly dependent on the font that is used. The font in this test file was Arial. The differences between Windows and macOS might be dependent already on different versions of Arial these OSs have (the Windows version is much more complex and has e.g. OpenType fractions). Just using Arial Bold instead of Regular gives different results and gives similar or identical results on Windows (v2), compared to macOS:

In light of this, there is hope that this could be just a minor glitch, more related to specific feature in the font than the actual glyph shapes. If so, then it seems that the major issues that are left with Boolean operations are related to Divide simple involving text objects (on both platforms).

I might have done mistakes, so here are the test files I used:

boolean_regular_v02_before_from_win.afdesign (created on Windows and having versions of texts converted to curves and merged on Windows) 

boolean_regular_v02_before.afdesign (having versions of text objects converted to curves and merged on mac, so using diffrent version of Arial)

[lepr]

4 hours ago, lacerto said:

[...] here are the test files I used: [...]

Thanks! I'll take a look later today and come back to the thread.

[Designer1]

8 hours ago, lacerto said:

Here are more comprehensive test files attached, and some notes on results after performing Boolean operations:

a) On Windows v1 (just as a reference):

• Red color indicates shapes that were left invisible after operation (not really an issue)
• The two elements Boolean operated on each artboard are from top to bottom: frame text + rectangle, art text + rectangle, frame text converted to curves and merged + rectangle converted to curve, and art text converted to a curves and merged + rectangle converted to a curve
• Subtract simple fails when performed on frame and art text, but works if text is first converted to curves and merged; subtract compound works fine
• Intersect simple fails when performed on text (all objects lost)
• Xor simple has issues
• Divide simple has issues when performed on text objects, works fine if text objects are converted to curves and merged; Divide compound fails to divide any objects

b) On Windows v2:

• Subtract simple still fails on operations involving frame text, or former frame text converted to curves and merged
• Xor has issues with frame text and former frame text converted to curves and merged
• Divide works fine only with art text converted to curves and merged

c) On macOS v2, when opening a file where text objects have been converted to.curves and merged on Windows:

• There are issues in Subtract, Xor and Divide when operating with frame text converted to curves and merged
• Divide simple fails with text objects 

d) On macOS v2, when text objects have been converted to curves and merged on mac:

• There are still issues with divide simple when operating with text objects. Divide compound works fine.

What is strange is that the results are clearly dependent on the font that is used. The font in this test file was Arial. The differences between Windows and macOS might be dependent already on different versions of Arial these OSs have (the Windows version is much more complex and has e.g. OpenType fractions). Just using Arial Bold instead of Regular gives different results and gives similar or identical results on Windows (v2), compared to macOS:

In light of this, there is hope that this could be just a minor glitch, more related to specific feature in the font than the actual glyph shapes. If so, then it seems that the major issues that are left with Boolean operations are related to Divide simple involving text objects (on both platforms).

I might have done mistakes, so here are the test files I used:

boolean_regular_v02_before_from_win.afdesign (created on Windows and having versions of texts converted to curves and merged on Windows) 

boolean_regular_v02_before.afdesign (having versions of text objects converted to curves and merged on mac, so using diffrent version of Arial)

Thank you for this test, which also confirms my results in Windows 11 with Designer 2.04.

@Ben Now it's up to you to correct it. One can also expect Serif to carry out such tests themselves before the software is published. I am therefore surprised that such errors are first pointed out in the forum after the software has long been on the market. It is not possible to work with it now.

[lepr]

11 hours ago, lacerto said:

What is strange is that the results are clearly dependent on the font that is used. The font in this test file was Arial. The differences between Windows and macOS might be dependent already on different versions of Arial these OSs have (the Windows version is much more complex and has e.g. OpenType fractions). Just using Arial Bold instead of Regular gives different results and gives similar or identical results on Windows (v2), compared to macOS:

You certainly could be right about results differing because of the difference between font versions on Windows versus macOS, rather than differences in the Affinity code on each platform.

 

11 hours ago, lacerto said:

d) On macOS v2, when text objects have been converted to curves and merged on mac:

• There are still issues with divide simple when operating with text objects. Divide compound works fine.

There is no "Divide (Compound)" command. I guess you are talking about alt/opt-clicking the Divide button in the toolbar, similar to alt/opt-clicking the Add/Subtract/Intersect/Xor buttons to create a Compound.

Alt/opt-clicking Divide does not produce a Compound. The alt/opt key is a modifier for Divide when one or more unfilled curves are in the collection of operands. The key is used when you want the fragments of unfilled curves to be kept, otherwise they are discarded.

When filled text is an operand in a Boolean operation, the text is first wrongly converted to unfilled curves instead of filled curves (a persistent bug for several  years now), and then the Boolean operation proceeds. Hence, the difference you were getting by doing a simple Divide with filled text versus an alt/opt-Divide with filled text. You were effectively dividing with unfilled curves when dividing with filled text.

 

[lacerto]

9 minutes ago, ,,, said:

Alt/opt-clicking Divide does not produce a Compound. The alt/opt key is a modifier for Divide when one or more unfilled curves are in the collection of operands. The key is used when you want the fragments of unfilled curves to be kept, otherwise they are discarded.

Ok, thanks for clarifying, I need to examine this operation more closely to understand it better. I have previously thought that Boolean operations are pretty similar in different apps, and to certain extent they of course are, but they work differently in Affinity apps and e.g. CorelDRAW, Illustrator, VectorStyler and Inkscape, and also use a bit different terms.

[lacerto]

I played a while with v.2.0.4. Divide operation (now mainly on macOS) but still could not get it work consistently. But the feature is broken on both platforms, and now I got different behavior also on macOS depending on font, and also depending on whether text based objects (whether still as frame or artistic text or converted to curves and merged) were involved or not. So I got bored in the middle of trying to produce a similar chart of mere Division operation in different situations (both shapes filled, only top or bottom shape filled, neither shape filled, and then performing Divide simple and Alt+Divide), because getting so varied and inconsistent results.

I am not sure about usefulness of getting different results for Division depending on having the Alt key pressed down or not. I would prefer the operation to behave similarly as Illustrator so the operated shape areas would always be retained after being divided, no matter if filled or unfilled (so no area would ever be lost and could afterwards, after division, be filled if wished). I can see some limited usability in Inkscape kind of Division where the division is confined within the area defined by the top object and the rest is removed (disregarding the fill state), and perhaps this could be a possible functionality for holding down the Alt key during the operation.

[Ben]

@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.

[Ben]

21 hours ago, ,,, said:

You certainly could be right about results differing because of the difference between font versions on Windows versus macOS, rather than differences in the Affinity code on each platform.

 

There is no "Divide (Compound)" command. I guess you are talking about alt/opt-clicking the Divide button in the toolbar, similar to alt/opt-clicking the Add/Subtract/Intersect/Xor buttons to create a Compound.

Alt/opt-clicking Divide does not produce a Compound. The alt/opt key is a modifier for Divide when one or more unfilled curves are in the collection of operands. The key is used when you want the fragments of unfilled curves to be kept, otherwise they are discarded.

When filled text is an operand in a Boolean operation, the text is first wrongly converted to unfilled curves instead of filled curves (a persistent bug for several  years now), and then the Boolean operation proceeds. Hence, the difference you were getting by doing a simple Divide with filled text versus an alt/opt-Divide with filled text. You were effectively dividing with unfilled curves when dividing with filled text.

 

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.

[Designer1]

On 1/31/2023 at 5:44 PM, Ben said:

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.

When will 2.1. be released, may I ask? As a graphic designer, I depend on flawlessly functioning software.

[PaulEC]

6 hours ago, Designer1 said:

I depend on flawlessly functioning software.

I didn't think there were any! 😁

[EmT]

Hi @Designer1

Unfortunately we cannot give a time scale on when an update will be released. 

If you follow the 'News and Information' thread on our Forum, it will advise you when an update is available.  

https://forum.affinity.serif.com/index.php?/forum/4-news-and-information/ 

 

[bt1138]

"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."

It's pretty amazing that there are people in the world who can figure stuff like this out. Thanks, @Ben

[Ben]

12 hours ago, bt1138 said:

 

It's pretty amazing that there are people in the world who can figure stuff like this out. Thanks, @Ben

It's what I do.

[lacerto]

This is now from the latest v2 beta on Windows, and the issue with text objects (whether Artistic, Frame, or ones converted to curves), specifically with some fonts like Arial, seems to be fixed. I am still not sure about the behavior of Divide, though (simple Divide will delete parts that are not shared by objects divided), while Alt/Opt divide will keep them. I'd rather see this operate so that regular Divide keeps and Alt/Opt deletes.

Red and green show parts that were left unfilled after operation (even when both objects involved were filled), which could be fixed, but this is already pretty good.