Bryan Rieger

I think what I am trying to do is along the same lines. In illustrator it insanely basic you just click the line you have drawn this then sets the style (stroke and colour) for the next vector brush line you want to do, I am trying to do this but every time I click vector brush I have the settings from the last line I drew. Say I draw a blue  line, then change colour and stroke draw a new red line, then want to continue the old blue line. In illustrator I would just click the blue line and this would set my brush to continue with that style, on Designer I find I am having to either try to match the stroke and colour the same then draw or having to raw then paste on the style from before. There MUST be a way I can just set the vector brush to the style I was previously using then draw with it, what am I missing?

That is a good thing, but I still wonder if it should be the default behaviour. To me that feels more like an optional behaviour - one that would be more inline with having to use a shortcut key.
That said, if Designer (and the Affinity suite in general, ahem Publisher’s text wrap feature) didn’t leave a mess of nodes around or have an automated means to clean-up geometry this wouldn’t be an issue.

I suggest an easy way to move objects from one layer to another via contxt menu:
Right-Click on object Select "Move to layer" in the context menu Choose layer from list This has already been discussed here (and I myself started a thread here, which can be closed now).
It could look like in Inkscape:

Video.mov    
 

My intent with my threads is to make Affinity apps have the best darn support for all fonts!
I have had the privilege to make videos and written tutorials on the offical FontLab Channel and website, teaching thousands of font designers.
I want to teach font designers to use Affinity Apps and make great fonts for your apps!
-----------------------------------
As I'm making fonts and trying them in Affinity, I'm finding a certain problem.
Alternate characters don't work correctly.
Currently, I am reporting this on a case by case basis.
Case by case is not optimal. First, I'm probably missing many problems.
Second, scattered problem reporting doesn't fix the underlying problem.
--------------------------------
There are essentially two main processes that make fonts work.
Font Renderer
The renderer takes the vector outlines and turns them into pixels.
Rendering can be visualized thus:

Different operating systems and programs have different renderers.
Microsoft uses ClearType (the example above). Apple uses Quartz. Adobe apps and Acrobat Reader use a proprietary rendering.
I'm not sure what renderer Affinity uses. (Or if it uses the default Microsoft or Apple system renderers.)
The renderer of Affinity seems to work fine. 👍
However Affinity has problems with the next process.
Font Interpreting (Text Shaping)
This does something entirely different.
The confusingly named interpreter (or text shaper) reads the feature code. For example, it reads this code from the font designer:

and changes it to this panel in Affinity:

Text shaping is the process of converting Unicode text to glyph indices and positions.
The specification which it reads can be found here
https://learn.microsoft.com/en-us/typography/opentype/spec/
The feature file specification is found here:
http://adobe-type-tools.github.io/afdko/OpenTypeFeatureFileSpecification.html
Interpreter Problems in Affinity
In Affinity GPOS LookType 8 doesn't work correctly. Also, GSUB LookupType 6 doesn't work correctly.
If you look at this page there are many more types of "Lookups".
I have not tested all of these. The basic ones seem to work. The more complex ones might not.
----------------------------
What Interpreter Does Affinity Use?
Not sure what interpreter Affinity uses. However, as shown above, it doesn't seem to be working correctly.
If it is a custom solution, it seems like it would be difficult to update.
What Would Be a Good Interpreter?
A good interpreter would be:
Widely used Updated on a regular basis Open source Easy to implement Widely Used
If you think about programming languages, when something is widely used AND widely used by large companies, it seems to stay around.
Harfbuzz seems to be widely used. It is used by these UI libraries (source😞
GNOME (GTK+ KDE (Qt) ChomeOS PlayStation 4 Android Java Flutter It is used directly in these apps:
Chromium Firefox LibreOffice Scribus Inkscape Adobe Photoshop Adobe inDesign (requires script to enable) Why Frequent Update?
Opentype is continually being developed, with frequent new versions. Unicode is updated every year.
If the feature interpreter doesn't get updated frequently, the app won't be able correctly use the newest fonts.
Harfbuzz seems to be updated frequently. There is an active community here: https://github.com/harfbuzz
Open Source?
Not sure. The license is found here https://github.com/harfbuzz/harfbuzz/blob/main/COPYING
It seems to have originally been open source. It seems like there is attribution involved and some individual files have copyright notices.
Easy to Implement?
I don't know if Harfbuzz is easy to implement. I don't know much on the technical side of fonts.
I'm not connected in the font world as well as I want. However, I communicate on a regular basis with FontLab's Adam Twardoch. He originated Variable Fonts. He has been working on font technology since the early 90s.
I also know Laurence Penny, a founding member of MyFonts.com. He is also the proprietor of some websites for font developers, including this one for variable fonts. 
Between those people, I know that they could find someone to help you implement a solution like this. Or maybe any questions can be asked directly to the font people on Harfbuzz's GitHub.
Also, there might be other solutions out there.
Thank you for reading! Dave Lawrence, California Type Foundry

After using Affinity Designer for almost 9 years now and wasting what is probably months of my life cleaning up extra nodes and geometry, I JUST learned that it is indeed possible to remove nodes AND retain the original curve geometry. Apparently, this little nugget of wisdom is buried on the 'Edit curves and shapes' page in the documentation, under a disclosure triangle labelled 'to delete nodes' and placed in a little box with the following note:
It's interesting that the note is larger than the actual text entry for the label 'to delete nodes'.
I have many questions, but the main one is why isn't (attempting to) retain the curve's original geometry the default behaviour? I'm guessing most people who delete nodes simply hit 'delete' without thinking about it, and then have to spend a not insignificant amount of time redrawing what they just lost by deleting the extra nodes.
Also, if this were the default behaviour it would be much more useful on the iPad as deleting nodes via the trashcan icon and then cleaning them up and redrawing them is a rather tedious process. I know this option isn't currently available on the iPad, but if and when you get around to adding it, please consider making it the default behaviour.
If anybody has any arguments as to why the current, destructive behaviour is preferred please leave a comment. I'm really scratching my head trying to come up with use cases where deleting nodes and having your geometry distort is preferable to deleting nodes and having the software attempt to retain the existing curve(s) as much as possible (with fewer nodes).
Addendum: If you select a number of extraneous nodes in a shape/curve (not all of the nodes) and use the ⌥ + Backspace (Delete on macOS) shortcut Designer does a pretty good job of cleaning up the nodes and matching the existing geometry. It's almost as if the 'simplify geometry' feature is almost there, but the user actually needs to go in and select all of the extraneous nodes they wish to delete first. Hopefully one day this might be automated in a future update.

After using Affinity Designer for almost 9 years now and wasting what is probably months of my life cleaning up extra nodes and geometry, I JUST learned that it is indeed possible to remove nodes AND retain the original curve geometry. Apparently, this little nugget of wisdom is buried on the 'Edit curves and shapes' page in the documentation, under a disclosure triangle labelled 'to delete nodes' and placed in a little box with the following note:
It's interesting that the note is larger than the actual text entry for the label 'to delete nodes'.
I have many questions, but the main one is why isn't (attempting to) retain the curve's original geometry the default behaviour? I'm guessing most people who delete nodes simply hit 'delete' without thinking about it, and then have to spend a not insignificant amount of time redrawing what they just lost by deleting the extra nodes.
Also, if this were the default behaviour it would be much more useful on the iPad as deleting nodes via the trashcan icon and then cleaning them up and redrawing them is a rather tedious process. I know this option isn't currently available on the iPad, but if and when you get around to adding it, please consider making it the default behaviour.
If anybody has any arguments as to why the current, destructive behaviour is preferred please leave a comment. I'm really scratching my head trying to come up with use cases where deleting nodes and having your geometry distort is preferable to deleting nodes and having the software attempt to retain the existing curve(s) as much as possible (with fewer nodes).
Addendum: If you select a number of extraneous nodes in a shape/curve (not all of the nodes) and use the ⌥ + Backspace (Delete on macOS) shortcut Designer does a pretty good job of cleaning up the nodes and matching the existing geometry. It's almost as if the 'simplify geometry' feature is almost there, but the user actually needs to go in and select all of the extraneous nodes they wish to delete first. Hopefully one day this might be automated in a future update.

After using Affinity Designer for almost 9 years now and wasting what is probably months of my life cleaning up extra nodes and geometry, I JUST learned that it is indeed possible to remove nodes AND retain the original curve geometry. Apparently, this little nugget of wisdom is buried on the 'Edit curves and shapes' page in the documentation, under a disclosure triangle labelled 'to delete nodes' and placed in a little box with the following note:
It's interesting that the note is larger than the actual text entry for the label 'to delete nodes'.
I have many questions, but the main one is why isn't (attempting to) retain the curve's original geometry the default behaviour? I'm guessing most people who delete nodes simply hit 'delete' without thinking about it, and then have to spend a not insignificant amount of time redrawing what they just lost by deleting the extra nodes.
Also, if this were the default behaviour it would be much more useful on the iPad as deleting nodes via the trashcan icon and then cleaning them up and redrawing them is a rather tedious process. I know this option isn't currently available on the iPad, but if and when you get around to adding it, please consider making it the default behaviour.
If anybody has any arguments as to why the current, destructive behaviour is preferred please leave a comment. I'm really scratching my head trying to come up with use cases where deleting nodes and having your geometry distort is preferable to deleting nodes and having the software attempt to retain the existing curve(s) as much as possible (with fewer nodes).
Addendum: If you select a number of extraneous nodes in a shape/curve (not all of the nodes) and use the ⌥ + Backspace (Delete on macOS) shortcut Designer does a pretty good job of cleaning up the nodes and matching the existing geometry. It's almost as if the 'simplify geometry' feature is almost there, but the user actually needs to go in and select all of the extraneous nodes they wish to delete first. Hopefully one day this might be automated in a future update.

After using Affinity Designer for almost 9 years now and wasting what is probably months of my life cleaning up extra nodes and geometry, I JUST learned that it is indeed possible to remove nodes AND retain the original curve geometry. Apparently, this little nugget of wisdom is buried on the 'Edit curves and shapes' page in the documentation, under a disclosure triangle labelled 'to delete nodes' and placed in a little box with the following note:
It's interesting that the note is larger than the actual text entry for the label 'to delete nodes'.
I have many questions, but the main one is why isn't (attempting to) retain the curve's original geometry the default behaviour? I'm guessing most people who delete nodes simply hit 'delete' without thinking about it, and then have to spend a not insignificant amount of time redrawing what they just lost by deleting the extra nodes.
Also, if this were the default behaviour it would be much more useful on the iPad as deleting nodes via the trashcan icon and then cleaning them up and redrawing them is a rather tedious process. I know this option isn't currently available on the iPad, but if and when you get around to adding it, please consider making it the default behaviour.
If anybody has any arguments as to why the current, destructive behaviour is preferred please leave a comment. I'm really scratching my head trying to come up with use cases where deleting nodes and having your geometry distort is preferable to deleting nodes and having the software attempt to retain the existing curve(s) as much as possible (with fewer nodes).
Addendum: If you select a number of extraneous nodes in a shape/curve (not all of the nodes) and use the ⌥ + Backspace (Delete on macOS) shortcut Designer does a pretty good job of cleaning up the nodes and matching the existing geometry. It's almost as if the 'simplify geometry' feature is almost there, but the user actually needs to go in and select all of the extraneous nodes they wish to delete first. Hopefully one day this might be automated in a future update.

Thanks @walt.farrell it works fine without the artboard. One more workaround to add to my ever growing list.

Try it without the Artboard.
There was (still is?) a bug with pixel layers contained within vector layers that manifests something like that.

After using Affinity Designer for almost 9 years now and wasting what is probably months of my life cleaning up extra nodes and geometry, I JUST learned that it is indeed possible to remove nodes AND retain the original curve geometry. Apparently, this little nugget of wisdom is buried on the 'Edit curves and shapes' page in the documentation, under a disclosure triangle labelled 'to delete nodes' and placed in a little box with the following note:
It's interesting that the note is larger than the actual text entry for the label 'to delete nodes'.
I have many questions, but the main one is why isn't (attempting to) retain the curve's original geometry the default behaviour? I'm guessing most people who delete nodes simply hit 'delete' without thinking about it, and then have to spend a not insignificant amount of time redrawing what they just lost by deleting the extra nodes.
Also, if this were the default behaviour it would be much more useful on the iPad as deleting nodes via the trashcan icon and then cleaning them up and redrawing them is a rather tedious process. I know this option isn't currently available on the iPad, but if and when you get around to adding it, please consider making it the default behaviour.
If anybody has any arguments as to why the current, destructive behaviour is preferred please leave a comment. I'm really scratching my head trying to come up with use cases where deleting nodes and having your geometry distort is preferable to deleting nodes and having the software attempt to retain the existing curve(s) as much as possible (with fewer nodes).
Addendum: If you select a number of extraneous nodes in a shape/curve (not all of the nodes) and use the ⌥ + Backspace (Delete on macOS) shortcut Designer does a pretty good job of cleaning up the nodes and matching the existing geometry. It's almost as if the 'simplify geometry' feature is almost there, but the user actually needs to go in and select all of the extraneous nodes they wish to delete first. Hopefully one day this might be automated in a future update.

I'd recommend creating a Feedback post if you wish to see this as the default behaviour in Affinity, or perhaps an option could be added to set this as default when deleting nodes.
I have however requested with the team that this should be clearer, as currently it appears to only be noted within the following helpfile page under 'To Delete Nodes' -
https://affinity.help/designer2/English.lproj/index.html?page=pages/CurvesShapes/edit_linesAndShapes.html?title=Edit curves and shapes

I hope this clears things up

@Dan C OMG I had NO idea this existed? Do you know how much time I've wasted cleaning up and redrawing extraneous nodes in Affinity Designer?! This is one of my biggest pet peeves when drawing with Affinity Designer. Why isn't this behaviour the default? Why is it hidden behind keyboard shortcuts that nobody can remember?
Unfortunately I work primarily on iPad so I'm still stuck with my current agonizingly slow workflow, but knowing this exists gives me hope. Please just make it the default behaviour and available everywhere. Who really wants to delete nodes and have the geometry change drastically and unexpectedly?
Apologies for hijacking this thread, but I just want to make sure you knew how important this behaviour is.
BTW being able to merge two points is another essential feature. Right now the workarounds are so time-consuming.

It depends on whether it's a beta for 2.x where the files will not be compatible with an earlier x, or whether it's a beta for 2.x.y, where the files will still be compatible. 
When I mentioned that, Serif said they wanted a single message, and for that "may" is accurate. But perhaps they should go further and explain the details.

Every time I open an SVG exported from Affinity in an editor that uses DTDs it always flags the xmlns:serif on the svg element as having no declaration.
I also tend to run into issues with serif:id="{art board/layer name}" conflicting with actual ids of elements within the SVG doc. For example if a rect has an id="Artboard1" and Affinity then creates a group with the ns attribute serif:id="Artboard1" then the XML processor usually flags it. Both of these issues can also cause problems when trying to process SVG files using SVGOMG, usually resulting in a Load failed: SvgoParserError: <input>:5:41: Unbound namespace prefix: "serif" error.
Of course, these aren't issues that are going to impact most users, but it does make it very difficult to use Affinity generated SVG files in more complex XML based workflows where working with valid documents is essential.
Simply having a preference when exporting SVGs to omit (or include if you want an intelligent default) serif namespace tags would solve these problems.
Edit:
If you remove the xmlns:serif="http://www.serif.com/" from the SVG tag you also have to remove ALL of the serif:attributes on elements to avoid many applications (including Chrome, macOS Finder previews/Safari, etc) displaying only errors (ie: Namespace prefix serif for id on g is not defined).

No problem at all, I absolutely understand and I've additionally personally pushed for this issue to be investigated ASAP with our team - as I agree that it is less than ideal to still be present in the apps since being reported previously.
Hopefully this will be addressed as soon as possible, though I'm unable to make any specific guarantees at this time.

This issue has frustrated me for years with Affinity Designer on iPad (and keeps pushing me back to Illustrator on the iPad), as it always requires me to go back and clean everything up by hand (using the node tool and Apple Pencil).
The Apple Pencil is why many artists use the iPad today (ie. Procreate) so telling users to use their finger isn’t really addressing the issue.
Please just fix it.

Apologies, I wasn't suggesting that this should be the resolution to the issue - I was simply trying to point out the trigger for this in the current build.
I certainly understand your frustrations regarding this issue and we hope to have this resolved in a future update

Hi @Tumulte,
Thanks for your report!
I can confirm this issue is logged with our development team to be resolved, I'll be sure to 'bump' this with them now to bring it to their attention once more.
I believe this issue will occur when using an Apple Pencil with Affinity, as other users have confirmed the behaviour does not occur when using your finger as the input device.
I hope this helps

To expand on what @walt.farrell said, SVG can also use variable fonts in contexts that support it (such as modern browsers), using font-variation-settings. FWIW Illustrator does a really poor job of supporting this and I always end up going in and editing it by hand.
<?xml version="1.0" encoding="UTF-8"?> <svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 480"> <defs> <style> @font-face { font-family: 'Maru'; src: url("./maru.woff2") format("woff2-variations"); font-weight: normal; } .variable { font-family: 'Maru'; font-size: 48px; font-variation-settings: 'wght' 400, 'wdth' 200, 'ital' 0; } </style> </defs> <text class="variable" transform="translate(68.48 239.83)">This is a variable font.</text> </svg>  

Hi Folks,
I had some fun time animating a drawing I made when I was 40 years ago, when I was six years old. Animation was done in Moho Pro, but I happily used Affinity Photo for making all the cutouts and doing some stamping and tricks to make it work. And of course the great export persona (I might have used Affinity Designer for that tho, as flexible as the Affinity ecosystem is in just opening the same file with another Affinity app!)!

Hope you like it! 
 

To expand on what @walt.farrell said, SVG can also use variable fonts in contexts that support it (such as modern browsers), using font-variation-settings. FWIW Illustrator does a really poor job of supporting this and I always end up going in and editing it by hand.
<?xml version="1.0" encoding="UTF-8"?> <svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 480"> <defs> <style> @font-face { font-family: 'Maru'; src: url("./maru.woff2") format("woff2-variations"); font-weight: normal; } .variable { font-family: 'Maru'; font-size: 48px; font-variation-settings: 'wght' 400, 'wdth' 200, 'ital' 0; } </style> </defs> <text class="variable" transform="translate(68.48 239.83)">This is a variable font.</text> </svg>  

Oh, I so miss having a story editor in Publisher. I keep holding back moving content from .rtf/.docx into Publisher until it's absolutely necessary (which causes other issues) so that I can continue to edit content in a sane manner (and have access to proofing tools such as Antidote[1]). It may seem like a small thing, but when you have dozens, or hundreds of flowing text pages, being able to just focus on the text (with tools designed to manipulate text) is such a godsend.
Also, being able to link text documents (in .rtf/.docx) and be able to update them via the Resource Manager would be a fantastic addition, and somewhat reduce the need for a built-in story editor (although it would still be nice to have one).
[1] InDesign and Illustrator both have Antidote support available. It would be massively helpful to many English and French users around the world if Antidote integration were possible within the Affinity apps.

I think one of the problems here is how each of us interprets 'scripting' today.
In the early days of InDesign, and when Quark ruled the DTP world, scripting was usually thought of in relation to automation; enabling a script to complete a series of mundane, repetitive tasks that enabled users to focus on more high-value work. In the years since, the concept of 'scripting' has morphed considerably. While we still create scripts to automate repetitive tasks, we now also create scripts to create new tools, workflow and functionality that extend our existing tools, enabling us to perform complex tasks that would have taken hours or days, in seconds and minutes. Going beyond simply creating new tools and functionality (Cinema 4D, Illustrator, etc), scripts can also be utilized to create entirely new generative works (Processing Blender, Rhino, etc).
From here it's not a huge leap to see AI as the evolution of scripting. We use it today to perform tedious, repetitive tasks, (object selection, masking, etc) and to create new tools (for writing, style transfer, content-aware fill, etc) as well as to create entirely new works (Firefly, etc). Even the way we create 'scripts' is changing. While we still write scripts in various languages, we also now have tools such as Apple's Shortcuts which employ a Scratch 'block-like' interface, or tools such as Unity, Unreal, etc which also provide visual node-based/flow-control scripting tools.
I think that while focusing on matching existing scripting support from other workflows is helpful in the short-term, it could quickly lead to a situation where user expectations have moved far beyond what was considered state-of-the-art just a few years ago, and risk leaving the Affinity suite feeling further dated, and increasingly irrelevant.
In the wise words of a fellow Canadian “…skate to where the puck is going to be, not where it has been”.

What's particularly sad about this is Serif just completely redesigned the UI for v2, but chose to disregard many basic UI/UX fundamentals along with modern usability recommendations. I'm not sure having Serif go back and redesign it again will magically fix all of the issues. Hopefully, Serif are paying attention (not just here, but also in various communities across the web, Reddit, etc) and will honestly begin to work to resolve these issues in the coming v2 updates.
I'm not sure I'd be willing to fork out again for v3 if these issues aren't addressed.