Lmpessoa

Thanks for the reply, but I was speaking more broadly and forgot to mention my intention was to build a plugin (or two) for Affinity Designer, not Photo. Fixed that.

So still no capability for us to develop plugins for Affinity Designer, right? Not just scripting, real plugins. Sad.

I made my own solution to making icons since we cannot rely on Serif for everything. It is and open source project I called MakeIcon (yes, it is my own). If Serif had support for plugins/extensions, I would certainly try and work out how to convert this project into one so I didn't have to export the images before creating the icon but they don't.

Let me add my 2p of disappointment then. Unfortunately not everyone can buy the book since they do not send it to anywhere in the world and thus I'm one of those unfortunate. It would be very much nice if we could have a digital version of those books so people from other parts of the world could enjoy it too.

I know Blender is free but I don't work with it. Maybe it is time I take a look at it (for various reasons).

I've been recently working on a technical project that required brand signage to be shown in 3D modelling but neither software I work with can read more than raster images, requiring me to re-vectorise it on the software. If I could be able to export the brand mark to DXF or DWG, that would have at least give me an advantage to properly work it on my 3D software. I would never mind having a separate Affinity software for CAD (Affinity Drafter or Affinity Canvas? who knows) but being able to read/write DXF/DWG files is not only in the intention of turning AfD into a CAD software.

+1

I don't believe this is a hard thing to implement since they already support creating TOC I don't see a reason why not use the same tool to create bookmarks on PDF export.

+1

If plugins were available (for Affinity Designer) it would be easy to create one to export shapes designed in it to a font format. Anyway, no plugin support for now...

@Patrick Connor Indeed might appeal a lot to technicals like us and I actually believe this is what would make it a successful move. Serif would keep it just as useful as it already is for creatives, maybe even easier since you would not need to manage three different apps, and technicals could step in at what they do best and solve minor problems such as file format support without the need to be post of Serif's payroll. Have you used SketchUp? It is a little more constrained as to what can be done with plugins but it does not alienate creatives, it helps us by creating new tools to help solve specific problems the developer does not think are problems for the community. As for marketing the feature, I don't see SketchUp shifting is focus from a creative tool into a development platform for that. Also, as a developer, I'd suggest taking a look at Eclipse: it has a broader aperture for extension but it allows devs to literally create even new products within the original without having to change the actual source (which is available but does not need to be). I am thinking of an Affinity Studio as something in this sense, that could be transformed into tools even Serif didn't think of or have the resources to provide. The core could be continuously refined/optimised, keeping focus on the main personas and leave the extras to us. @mac_heibu I didn't start the conversation with the expression, I actually ended my first iteration with it and I know everyone posting their needs and ideas here is expecting a light from Serif just as I am, after the very first iteration. I just made it explicit.

You know @mac_heibu, you are most probably right. From what I have seen in this forum over the past year, Serif might just be the kind of kid who does not even consider the opinions and ideas of others kids they play with and just takes the ball home, leaving those other kids to play empty handed unless they have another ball. So yes, I might just be wasting my time here talking about ideas that will never come to light but this is the space we were given for it and I'd rather believe what I took careful time to express will reach at least someone at Serif that might think this is it and perhaps at least once try to push it forward. Otherwise I'd rather just try and find another ball to pay with. About the only thing in my post that drew your attention, I don't know how familiar you are with English idioms but to say "the ball is in someone's court" is a very common expression and means it is up for someone to make a decision, to make the next move. But again, who am I to be teaching English, right.

I'm a developer and I like studying other apps and how they are structured, something people call software architecture, especially for software product lines, theme of my masters thesis. This suggestion is based on the knowledge I gained through multiple projects throughout my life and also the Affinity suite itself. I'm also aware the following is true only of the Windows versions for reasons will be made clear ahead but I doubt the approach is different on the macOS version. Here it goes. --- While licensed as separate applications, the core of the Affinity application is contained in a few files (a few DLLs) shared between the multiple apps. Nevertheless, this actually means that when licensing the different application we are actulally licensing the usage of a few parts of an existing API for a particular purpose, depending on the app itself. Thus, Affinity Publisher - with both Designer and Photo functionalities incorporated - is the whole application and the easiest part of what I call Affinity Studio in this idea. So, the whole of my idea is to drop this separation in multiple applications and incorporate them all into a single one (Affinity Studio) with the ability to receive plugins that could explore the entirety of its funcionality through the existing API. I know most people thinking about scripting and plugins on this forum are demanding languages like Python or JavaScript but the reality is that a part of the Affinity suite (including the aforementioned DLLs) is developed using .NET and it would be easier to enable plugins developed in it: makes the lives of the developers (both at Serif and those writing extensions) easier because developing tools are already avalible (Visual Studio has a free community edition and is probably the same tool Serif already has licensed) and exposing the API is a lot simpler (most of it can be seen by incorporating the those DLL to any .NET project). Limits could be stablished but I see everything could be created: new tools, personas, functionalities, file formats, and so forth. Also, despite being mostly centred around C#, .NET allows for a multitude of languages to be used to develop projects (including Python and Javascript). Before anyone can ditch my ideas as unfeasible because of the macOS version, I must remind that .NET Core is already cross-platform (although with some limitations) and can run on macOS and even Linux and if I'm not wrong .NET 5 (droping both Core and Framework from its name) will be released by the end of the year and may have complete support for fully cross-platform desktop applications, dropping also the need to support a separate version for macOS and opening the door to a Linux release with little to no extra cost for Serif. Also, I don't remember exactly where but I've already heard from someone from Serif that the file format for all applications, despite the different file extensions, is exactly the same (go ahead, change the extension of a file and open it, I'll wait) so files are really not an issue but I'd suggest reducing to a single extension for simplicity (I'd go for .afp ). And we don't need to have access to the details of the file format If the exposed API provides the means to incorporate file importers/exporters (read files and create objects on the canvas and vice-versa) that could solve the biggest issue I see in the forums, support for multiple additional file formats, which anyone should recognise it may be an impossible task to accomplish by Serif alone no matter how big their team is. With this approach, Serif could focus on providing one fully capable application worrying only about its core functionality and leave the rest for the community. No matter how big the API currently is, all we would need is a simple "hello world" so we know where to start and how to incorporate these into the finished product. Plugins are also a means to create software product lines, which is my field, and is a means used by many applications over the years. I know with my knowledge I could be providing some of the funcionality requested in the forums and many many more with the proper means to. I know many in this community feel the same and I cannot wait to see what could come out of this (even scripting with Javascript or Python could be achieved throgh this). If your concert is security/privacy of users, I'd state I don't really remember any platform using plugins being overly concerned about it, which I understand could be a big issue depending on Serif's values but I believe this is something the community could regulate on their own: some more concerned would work on evaluating extensions and providing feedback to us all about which are safe to use and which are not and word will eventually spread. If Serif is really concerned about security, they could incorporate the means to remotely block (blacklist) harmful plugins (please, don't tell me you dont know Apple and Google can do that on your phones). Sorry for the long post but I see a big potential in applications like the Affinity suite given the proper means for expansion and I would love to work these ideas out without having to be part of their team itself. I think the ball is in your court now, Serif

I believe it is already possible to export your asset library (you can build one, yes) to a file of extension .afassets. I downloaded several months ago a file with the assets for that skull island example but never really explored the feature, so I do not know if updating the asset library would update the used symbols in a document.

I just loved this one. +1000

Well, it's been almost a year after that comment and a minor update (1.7 -> 1.8, not counting bug fixes) and still no sign of it.

Many years ago I worked on an experiment to read Fireworks PNG files and convert their vector information into SVG files. I still have that code but it is an incomplete work. If Serif were to allow us to create proper plug-ins for its tools, I could resurrect my old code and provide this plug-in, but it seems this is not a priority for them (although it would reduce the number of claims to provide support this or that file format).

+1

I would not count with support for any existing plugin for any other app. Adding support for plugins is already hard enough; adding the same support provided by another platform requires an additional layer of code translating what the plugin expects to what the program actually provides and little can be done if there is anything the program cannot/will not support. When plugins are supported by the Affinity suite, I expect nothing different from it supporting their own set of plugins and providers of existing toolsets may choose to port their code or not. But remember once the door is open others may provide similar or even better extensions.

Sorry but I would vote you down. I'm much more fond of Javascript/Typescript than Python. It will be much hard for Serif to choose one language that will please everyone so I wouldn't be bothered by whichever language they choose (even if they were to introduce one of their own). I think the choice in the end will be which one will be easier to incorporate into the apps.

Have you tried Affinity Publisher? It's been suiting my needs regarding PDF editing. I'm aware, however, of limitations such as no support for Acro Forms, for example, but I seldom need it too.

It works from inside InDesign so it does not need to know the format of INDD files but relies on being able to programatically create InDesign documents from within. If the specs for AFPUB files were public, one could create a plugin to convert these to/from INDD just the same way and I think that could work for some. Just to note, Affinity Publisher does not need a plugin for opening PDF files for editing.

That makes at least a market of two.

As with AI files, INDD files uses a propriety and undocumented (at least not publicly) format which would require a huge effort to reverse engineer by trial and error (thrust me, I've been trying) so I would not expect support for either format in the near future. I'd go with @fde101 for now.

I don't really think it would disrupt any workflow with the correct management. Some (me included) have been asking for support for scaled drawing, which could be seen as part of this "CAD persona", but could benefit even more. I have also seen a lot more requests in the same direction, some that could be achieved using a plugin architecture like math-based/technical drawing some that really depend on Serif. I sincerely do not expect Serif to add a persona for technical drawing or even to fork it into a fully fledged app for that but I understand some few helper tools could be added seamlessly to everyone's workflow to achieve the same result. As we speak, I'm going through the experience of creating a full technical drawing document (CAD like) using AfD and as of right now I miss only some few tools to be able to work better/faster: scales: a simple math can be done by hand to have scales but having this math done by the app makes working with it faster vector textures: AfD already supports raster textures but being able to define a real vector texture would be nicer leaders: can be achieved by using separately a line and a text but these are either two separated objects or a group, which is a little more tricky to handle, or even a symbol dimension lines: as with leaders, can be achieved with individual objects, or a group, or a symbol trim: can also be worked around using geometry (AfD geometry tools are way better than Illustrator, working as I expect them to), it is more a bad habit I got from the very first time I messed around a CAD but sure comes in handy sometimes, even in non-technical drawings offset: Illustrator has a tool to convert the border of an object into another independent object but AfD cannot With the right set of API available, most of these tools (leaders, dimension lines, trim, offset) could be created by 3rd-parties with no further need for Serif's involvement. To some of these, there are already some suggestion topics going on, I suggest following and supporting them: I'm also a strong supporter of Serif adding an API so we could create extensions to Affinity apps, which could be used to add lots more tools (like means to support more math-based drawing tools or even some of the tools I mentioned to be missing) and even support for reading/writing DWG files (and well as many others). I'd also suggest supporting this: One could say we're trying to transform AfD into a CAD but both are (for the most part) only drawing apps sporting a different set of tools so they are not worlds apart. An example of that is, as I already mentioned, I'm working full technical drawings using AfD and it is already not that hard to be done. Have you tried doing anythink like this? Have you missed any other tools I have not mentioned?