Bryan Rieger

starts at 4:00 or so

^ Strike that, it affects simple vector masking as well.
However, I think now I understand the idea behind the change:
Previously it was not possible to select e.g. the full image when it was masked by a vector object. In 2.4.2 I have to release the mask first to select the full image layer being masked/cropped.
That is now possible, and you can toggle the bounding box via Cycle selection. So it's not necessarily a bad thing. It should just likely be the other way around, i.e. the default box should be the vector mask, and then you can toggle to select the cropped/masked content instead.
In other words, if you need the old behavior/appearance, nest your objects inside other objects, and on double click you'll still get the full content bounding box as a bonus.
(Have I already mentioned that  I've never understood the point of the Vector Crop tool in the first place…? )

I just started using 2.6 the other day and I'm shocked that after all these months of development, 2.6 is as terrible as it is. The new cropping behaviour takes something that worked as expected (the object would be sized to the crop), and made it absolutely useless (the object is sized to the original object before crop). I simply can no no longer use that feature in any workflow. Who on earth thought that was an improvement on the existing behaviour?!
Other than a slightly improved pencil tool (thanks for the 'smoothness' setting, although 'smoothing' would be a better label), version 2.6 brings absolutely no benefits to my workflows. ePub export? Proper vector brushes? Clean-up/simplify geometry? An expand stroke feature that works reliably? A contour tool that isn't a 'minimum viable product'. Improved variable font support (ahem, Playpen and alternates). The list goes on and on… and I haven't even mentioned the now routinely excruciatingly slow file loading.
I had hoped that with the botched 2.5 release Serif would take its time to ensure that the 2.6 release was solid. Unfortunately, with this release my already waning confidence in Serif continues its downward trend, and the Canva acquisition appears to have only made things worse.

I just started using 2.6 the other day and I'm shocked that after all these months of development, 2.6 is as terrible as it is. The new cropping behaviour takes something that worked as expected (the object would be sized to the crop), and made it absolutely useless (the object is sized to the original object before crop). I simply can no no longer use that feature in any workflow. Who on earth thought that was an improvement on the existing behaviour?!
Other than a slightly improved pencil tool (thanks for the 'smoothness' setting, although 'smoothing' would be a better label), version 2.6 brings absolutely no benefits to my workflows. ePub export? Proper vector brushes? Clean-up/simplify geometry? An expand stroke feature that works reliably? A contour tool that isn't a 'minimum viable product'. Improved variable font support (ahem, Playpen and alternates). The list goes on and on… and I haven't even mentioned the now routinely excruciatingly slow file loading.
I had hoped that with the botched 2.5 release Serif would take its time to ensure that the 2.6 release was solid. Unfortunately, with this release my already waning confidence in Serif continues its downward trend, and the Canva acquisition appears to have only made things worse.

Please reconsider providing architecture specific builds for macOS Intel and Apple Silicon directly from Affinity. I know that doesn't help with the App Store Universal builds issue, but at least you could help those customers who have purchased directly from you. Oh, and an added benefit would be showing some respect to users with smaller hard-drives by not shipping GBs of libs they don't need.
Simply saying 'sorry for the inconvenience, but we're not going to bother to at least fix it where we can' just further demonstrates Serif's contempt for its users. 

I toggled the iCloud Drive settings for each of the apps and that seems to have worked. 🤞
Thanks @Hangman!

Maybe just adding it as an option in the Edit menu, just below duplicate. Or maybe it's already somewhere and I missed it, please ignore if that's the case.
I keep forgetting this dialog even exists until it pops up in tutorial videos. Or forget which key I need to press, or even the name of the dialog so I can look it up.
It's also troublesome for the user experience to have features like this prompted by key bindings only, with no visual cue somewhere in the UI that they are available, either as a reminder or as useful information for newcomers. I'm mostly self-taught, so I figure things out by looking through the buttons and menus and trying stuff out. Not seeing an option for a feature somewhere is just the same as not having it sometimes.

I haven't used these machine learning models yet, but I just wanted to say how nice a surprise it was to see that these were optional downloads, and not simply bundled into the existing applications. I really appreciate Serif giving creatives the respect to choose whether or not they want to integrate any machine learning into their workflows. 
Also, kudos for side-stepping the blanket AI hype train and calling these 'Machine Learning Models', which is not only more accurate, but also helps to frame the discussion in a much more informed manner.

I've always found the Astute Graphics tools indispensable when working with Illustrator, especially Vector First Aid (node clean up and optimization) and Phantasm (non-destructive vector colour control and halftones). Serif is sorely lacking any automated means of cleaning up the large number of nodes it's tools create (this is a very manual task in the Affinity suite), as well as vector colour adjustments (the existing adjustment layers render vectors to bitmap). Ideally tools like these would simply be a part of the Affinity toolset, but if that's not possible hopefully Astute Graphics will see the Affinity apps as a worthwhile investment once the SDK becomes available.

I haven't used these machine learning models yet, but I just wanted to say how nice a surprise it was to see that these were optional downloads, and not simply bundled into the existing applications. I really appreciate Serif giving creatives the respect to choose whether or not they want to integrate any machine learning into their workflows. 
Also, kudos for side-stepping the blanket AI hype train and calling these 'Machine Learning Models', which is not only more accurate, but also helps to frame the discussion in a much more informed manner.

By all means keep this thread visible for others to learn from. 
This  thread illustrates Granddaddy's problem-solving technique called Broadcasting Your Ignorance.
As I first learned some 45 years ago, in the days of IBM mainframe listservs and PC bulletin boards, the quickest way to find a solution to my problem was to broadcast my ignorance. Sure I was sometimes made fun of by others. So what? So long as I had my say they could say anything they pleased. Remember that nothing good ever happens that some don't have their fill of laughter from it. Intelligent people, those who can help you, know what to disregard and will think no worse of you because of foolish criticisms by others. The important thing is that there is always someone who understands your problem and who is willing and able to provide a solution. 
As a professional librarian in research libraries at two large state universities, I always taught students a three step sequence to finding information.
1.)  Ask someone who knows
2.)  Broadcast your ignorance
3.)  As a last resort, go to the library
Today that last step more often involves searching the Web. But beware. The Web is not a library. 
As was written long ago: Search engines, with their half-baked algorithms, are closer to slot machines than to library catalogues --David Rothenberg Chronicle of Higher Education p. A44, August 15, 1997 It's worse today given that search engines are written to serve the purposes and agendas of the search engine companies. Often that means they are designed to mislead you and redirect you away from the best information.  So ask someone who knows and when necessary broadcast your ignorance on these forums. As we see every day, someone who knows will answer your call.
Oh, and one thing more, broadcast your ignorance gently and with humility.

Please reconsider providing architecture specific builds for macOS Intel and Apple Silicon directly from Affinity. I know that doesn't help with the App Store Universal builds issue, but at least you could help those customers who have purchased directly from you. Oh, and an added benefit would be showing some respect to users with smaller hard-drives by not shipping GBs of libs they don't need.
Simply saying 'sorry for the inconvenience, but we're not going to bother to at least fix it where we can' just further demonstrates Serif's contempt for its users. 

Just to (hopefully) draw a line under this scripting language debate:
We chose JavaScript (ECMAScript) for reasons that I'm not going to go into here!  JavaScript floating point precision is as good as any other scripting language we could have chosen.  Although its native number type is floating point, integers up to 2^53 are represented precisely; if you need more then there's BigInt. If you need integer truncation then there's Math.floor. In other words: it's not a problem. Our JavaScript SDK is implemented as a plugin and built on top of our C++ SDK. This means that although we currently have no plans to do so ourselves, it will be fully possible for anyone to implement "first class" support for Python or any other scripting language.

Too used to using the default 'Outline' wireframe mode on my toolbar that I had forgotten about the X-ray mode. I'd agree this is a bug and will get it logged, thanks @Bryan Rieger!

@NathanC if you use View > View Mode > Wireframe > X-ray any pixel elements will appear dimmed/semi transparent when the document colour space is set to RGB. However when using CMYK colour space pixel elements are drawn only showing their bounding boxes, which is the same as switching to View > View Mode > Wireframe > Outline.
I'd consider this a bug, and would expect the same behaviour regardless of colour space.

I don't think they're finished putting all of the bugs in it yet.

I don't think they're finished putting all of the bugs in it yet.

I don't think they're finished putting all of the bugs in it yet.

I don't think they're finished putting all of the bugs in it yet.

.

Of course they do! 

Hello everyone,

While exporting a very simplified text from Affinity in regular Arial, 8 pt, black), I came across several oddities in the generated SVG file. To illustrate the case, I added “absent” characters represented by a red placeholder, as well as a red rectangle.
And there you have :
- A ghost font named ArialMT (from Adobe), which doesn't exist in my source file or even on my system.
- A totally useless empty group.
- Nested transformations for no good reason. None of the transformations are useful.
- Many useless attributes.
Here's the source file (Unnecessary things in color).
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 1334 350" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
    <g transform="matrix(4.16667,0,0,4.16667,0,0)">
        <g transform="matrix(4.60446,0,0,0.45635,0,0)">
            <rect x="0" y="0" width="18.243" height="184.069" style="fill:#e43a30;"/>
        </g>
        <g id="Fonte" transform="matrix(1,0,0,1,84,2.84217e-14)">
            <text x="14px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">In purus est, mattis eget, imp</text>
            <text x="150.948px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text>
            <text x="161.615px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">rdiet nec,</text>
            <text x="14px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">f</text>
            <text x="16.964px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text>
            <text x="27.63px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">rm</text>
            <text x="40.068px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text>
            <text x="50.734px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">ntum cong</text>
            <text x="100.542px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text>
            <text x="111.208px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">e, tortor. Aenean ut</text>
            <g transform="matrix(10.6667,0,0,10.6667,187.094,59.687)">
            </g>
            <text x="14px" y="59.687px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">nibh. Nullam hendrerit viverra mi […]</text>
        </g>
    </g>
</svg>
Here's why.
<?xml version=“1.0” encoding=“UTF-8” standalone=“no”?> <!-- Can be removed: redundant with file header. --> <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd”> <!-- Obsolete: useless in modern SVG files. --> <svg width=“100%” height=“100%” <!-- Potentially useless: dimensions will often depend on integration via CSS. --> viewBox="0 0 1334 350” version=“1.1” <!-- Superfluous: version is implicit in modern specifications. --> xmlns="http://www.w3.org/2000/svg” xmlns:xlink=“http://www.w3.org/1999/xlink” <!-- Potentially useless: `xlink` is no longer needed in SVG 2.0. --> xml:space=“preserve” <!-- Unnecessary in most cases: `xml:space=“preserve”` has little effect except with intentional spaces. --> xmlns:serif=“http://www.serif.com/” <!-- Totally useless: no use of this namespace in the file. --> style=“fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;”> <!-- Potentially useless if these styles don't concern content. --> To be more precise:
Here's a list of aspects to consider:
1. DTD usage
    Criticism:
Use of the DTD <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd”> is obsolete and of little use in a modern context. Most browsers ignore this declaration.     Improvement:
Remove the DTD or simply use the XML version without DTD. 2. Inline style
    Criticism:
The style attribute in svg and internal elements (rect, text) mixes style definitions in SVG content, making maintenance difficult.     Improvement:
Externalize styles in a CSS sheet or group them in a <style> tag in the SVG file to centralize styles. 3. Non-standard fonts
    Criticism:
The style font-family:'ArialMT', 'Arial'; includes a non-standard font (ArialMT), which may not be recognized on all systems. This may cause incorrect rendering.     Improvement:
Use standard fonts or define reliable fallbacks (font-family: 'Arial', sans-serif;). If the software could also optimize the source, it would produce much smaller images that would load more quickly. 4. Inconsistent attribute values
    Criticism:
x-positions for <text> elements use px values when other units might be more suitable (e.g. % or relative coordinates). Dimensions and transformations (matrix(...)) are complicated and difficult to interpret, making manual editing a pain.     Improvement:
Simplify transformations and use consistent units or positions to facilitate readability and maintenance. 5. Lack of descriptive tags (accessibility)
    Criticism:
The file does not contain accessible descriptions such as <title> or <desc> tags. These tags are useful for assistive technologies (screen readers).     Improvement:
Add <title> and <desc> tags to describe visually represented content. 6. Unnecessary or redundant data
    Criticism:
The namespace xmlns:serif=“http://www.serif.com/” is declared but never used. The <g transform=“matrix(10.6667,0,0,10.6667,214.422,59.687)”> element is empty, which seems unnecessary.     Improvement:
Remove unused elements or declarations to lighten the file. 7. Complex transformations
    Criticism:
Matrix(...) transformations are complex and make subsequent modification difficult. They can also cause compatibility problems with certain viewers or tools.     Improvement:
Replace matrices with explicit transformations (e.g. translate, scale, rotate) where possible. 8. Fixed dimensions and lack of dynamic viewBox
    Criticism:
The dimensions width=“100%” and height=“100%” do not guarantee correct rendering in all contexts, as they depend on the parent container. The viewBox is correctly defined, but its association with dynamic dimensions could be optimized.     Improvement:
Add explicit dimensions or use a more flexible viewBox to ensure consistent rendering. 9. Confusing hierarchical structure
    Criticism:
The numerous <g> and <text> sub-elements make the structure unwieldy. Each word or fragment is encapsulated in a separate element, making the file difficult to manipulate or modify.     Improvement:
Group text in a single <text> element if possible, with <tspan> elements to handle differences in style or position. 10. Style redundancy
    Criticism:
Each <text> element repeats the same styles (font-family, font-size, fill), making the file unwieldy.     Improvement:
Use classes or global styles to reduce redundancy. 11. Unnecessary inclusion of XML attributes
    Criticism:
The xml:space=“preserve” attribute is rarely needed and could be superfluous here.     Improvement:
Remove it if its presence does not modify the file's behavior. 12. Longer text spans
    Criticism:
The text of an option should not resemble a treasure hunt, but clearly describe its function. The current title, 'Longer text spans', is inappropriate, even a misnomer that can only add to the confusion. In French, the translation also adds a contradiction to the contradiction. This option actually determines whether or not <text> tags include <tspan> child tags.     Improvement:
A more suitable formulation would be:
<Text> tag without <tspan> child tags. Or: <Text> tag without <tspan>
In French :
Balise <Text> sans balises enfants <tspan>. Or: Balise <Text> sans <tspan> To take things a step further, here's some optimized code.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1334 350"> <!-- Styles CSS intégrés --> <style> .svg-red { fill: #e43a30; } .svg-black { fill: #11161e; } .svg-text { font-family: Arial, sans-serif; font-size: 10.667px; } </style> <!-- Rectangle rouge --> <rect x="0" y="0" width="76" height="184.069" class="svg-red" /> <!-- Textes noirs --> <text class="svg-text svg-black"> <tspan x="14" y="31.954">In purus est, mattis eget, imp</tspan> <tspan x="161.615" y="31.954">rdiet nec,</tspan> <tspan x="14" y="45.82">f</tspan> <tspan x="27.63" y="45.82">rm</tspan> <tspan x="50.734" y="45.82">ntum cong</tspan> <tspan x="111.208" y="45.82">e, tortor. Aenean ut</tspan> <tspan x="14" y="59.687">nibh. Nullam hendrerit viverra mi […]</tspan> </text> <!-- Textes rouges --> <text class="svg-text svg-red"> <tspan x="150.948" y="31.954"></tspan> <tspan x="16.964" y="45.82"></tspan> <tspan x="40.068" y="45.82"></tspan> <tspan x="100.542" y="45.82"></tspan> </text> </svg> 13. Table with unnecessary transformation sequences
Criticism:
Instead of transforming the table directly into text, and adding a grid, the software produces an unbelievable number of transformations that in reality serve no purpose except to add inaccuracies.     Improvement:
Avoid transformations. See discussion below 14. Character style transformed into path
Criticism:
The Small capital character style turns text into a path and adds a <tspan> tag, the underscore becomes a rectangle, the highlight becomes a path, the apostrophe sometimes leads to the insertion of a <tspan> tag.     Improvement:
Avoid transformations. See discussion below. Summary of areas for improvement
By streamlining the structure, optimizing the styles and simplifying the transformations, we could make this SVG file :
    More readable,     lighter,     More compatible with modern tools. By adopting these optimizations, Affinity could generate SVG files that are not only more powerful and lightweight, but also conform to modern standards, making them easier to integrate and manipulate in demanding professional workflows.
Wouldn't it be a good thing to be ahead of the game?
test-svg.afpub bad-font.svg

I don’t have much to add beyond what’s already been said (many times), but my biggest disappointment is the radio silence we’ve had from Serif (and Canva) management since the acquisition.
2.5 was an utterly botched release so that Ash could get up on stage and take part in High School Musical - Canva Edition.
I’m glad Serif are taking their time with 2.6, but that still doesn’t change the fact that in the meantime, trust in Serif and Canva for many folks continues to erode rapidly.
I don’t participate here much anymore (the website takes far too long to load after the recent forum update), and I’m tired of hearing that issues are logged with developers- often for years on end, without resolution.

I haven't used these machine learning models yet, but I just wanted to say how nice a surprise it was to see that these were optional downloads, and not simply bundled into the existing applications. I really appreciate Serif giving creatives the respect to choose whether or not they want to integrate any machine learning into their workflows. 
Also, kudos for side-stepping the blanket AI hype train and calling these 'Machine Learning Models', which is not only more accurate, but also helps to frame the discussion in a much more informed manner.

I don’t have much to add beyond what’s already been said (many times), but my biggest disappointment is the radio silence we’ve had from Serif (and Canva) management since the acquisition.
2.5 was an utterly botched release so that Ash could get up on stage and take part in High School Musical - Canva Edition.
I’m glad Serif are taking their time with 2.6, but that still doesn’t change the fact that in the meantime, trust in Serif and Canva for many folks continues to erode rapidly.
I don’t participate here much anymore (the website takes far too long to load after the recent forum update), and I’m tired of hearing that issues are logged with developers- often for years on end, without resolution.