Lmpessoa

This is not an easy issue. Nowadays the AI file is a PDF file only serving as an envelope for the actual AI file contents. While the PDF part is well documented and easy to read/write, the AI stream is proprietary and undocumented, including an undisclosed compression method, making it harder to be read/written. AfD can read AI files by reading the PDF envelope, not the AI stream in it (but files must be saved with the option to create a PDF compatible file, even thou it is always a PDF file or you will only see garbage after importing). It would require a large effort of reverse engineering to allow any other application (not just AfD) to export AI files so I wouldn't expect this any time soon (although someone might be try and solve it if a plugin architecture were available). Right now what you can do is export the files you work with your team in another format supported by both applications like EPS, SVG or even PDF.

Just another example taken from the idea of @July-Nov of what could be accomplished with the proposed API: drawing using math properties like circles using tangents. Some kind of illustrations require precision and while one can do all the math to create it (think of the representation of the graph of a equation for a technical book, for example), one could provide an extension that solved this matter in a simpler, easier way.

I'm trying to draw a bit of attention to a very simple API but one that could be really powerful. I believe the more support it gets better the changes we are heard this time.

+1 I sure would love some of these too. For me in particular I've always missed a trim tool in similar apps (maybe it is due to my background in CAD but they sure are handy). I don't really think we need a "CAD persona" for that, all we need is a few additional tools. Some like drawing using a bit more of math could be achieved through 3rd-party extensions but it seems those aren't really a top priority at Serif.

I agree this would be a great feature and would help my work a lot and I don't think it would actually be a hard thing to implement. One can actually draw in scale using a simple equation: F = VAL * A / B where A and B are actually the scale (A:B, and usually either is 1 thus you'd only need to either multiply or divide), and VAL is the actual value we want to represent in scale. The result (F) is the size to use to draw in the given scale. An implementation would add a field called "Scale" in the top toolbar (it would always be visible no matter what panes you're using) with a default value of 1:1. Any values like X, Y, width, height, length (for lines), etc. would just use this simple formula to convert values displayed and input so we don't have to be wasting so much time doing the math ourselves. thus, for example, I may draw a line of 11 cm using the "1:1" scale and if I set the scale field to "1:50" only the UI would change tell me it is a 550 cm line; on paper it would remain an 11 cm line. Also, changing the length of the line to 100 cm in the same "1:50" scale would still reflect the value of 100 cm but on paper the line would change to 2 cm (math would be automatically done for us). The idea is not to have the object retain the scale it was build with but provide a simple helper for scaled drawings and illustrations. I'd also love to have those "Dimension" lines @Francispmc mentioned. Those would actually need to retain the scale (in order to provide lenght automatically) but I'd go for having the actual text fully editable. UPDATE: There is a feature in AD that I just got to know that the input fields of the "Transform" pane can to a bit of math. You can, for example, type "550/50" to have a line drawn with 550 cm in a scale of 1:50. It can also add (+), subtract (-) and multiply (*) thus you can also achieve scales like "5:1". We'd still have to do the math back to find out the unscaled size but it may already be a little bit of a help.

I've been following the forums for a while now since I've decided to switch from the "A" suite and, of all the features requested by users, the most are support for a given file format. Also some users have been heavily requesting for an API they could use to automate stuff (or build stuff - some ideas also came to my mind while writing this) and I think these could be handled with a little bit more of effort in building an API. Since most programming languages are object-oriented I'm also thinking in such terms while I write, however I'm not being specific on language. I believe two kinds of plugins could be allowed: SCRIPTS, which would only help in automating repetitive tasks (think about closing a document for printing) and mostly would only manipulate the document without any sort of argument, and PLUGINS, which would be developed on a chosen platform (I'm pretty sure the Affinity suite relies on .NET) and would enable usage of every feature the platform has to offer. This dual approach is adopted by apps such as ZWCAD and could be great for different uses but it is not a mandatory thing. As for the API itself, the idea would be to enable means to programmatically: access a document (either by creating a new one or retrieving one currently open), layout the document (creating slices on AD or new pages on AP, for example), create, retrieve, modify and/or objects in the document (create shapes, change attributes like colour, add text, etc.), request users to select objects or a point on the document (to ask the user where action will take place). Basically that is allowing anything on an app to be done programatically (yes, with the right script, one could simply automate a complete complex drawing, I'm not asking why would you). I'm thinking of basic object-oriented programming here: // in some pseudo language doc = new document rect = new rectangle object set brush in rect to X add rect to doc ... I'm also well aware the amount of effort and code required to implement this API so I'm not expecting this to be available tomorrow (or in the next version) but I think we'd have to start gathering ideas about this somewhere. Here are some examples of what I would expect that could be achieved with this API: import/export to X file format (PLUGIN): triggered by selecting a file in a recognised format, it would (1) read from a file and create a document and the objects in it using the API representing the contents of the file or (2) traverse a document (or a slice of it in AD) and write it to a file in the chosen format, QR code (PLUGIN): it would open a dialog for the user to enter the info on the QR code (format version, size, tint, text, etc.) and create a group of rectangle objects based on that info. After that, it is just a series or rectangles and does not depend on the plugin (of course this approach does not allow the QR code to be edited, or even its info to be viewed, but I'm sure some other approaches can be taken - like storing arbitrary metadata on objects and groupings and even restricting some of these to be undone), create a draft in PDF format (SCRIPT): this would just add the word "DRAFT" in the background of every page (in a publication - to the original or a copy of the document that exists only in memory), trigger the export to PDF function (it is already embedded on the app, so why not make it accessible) and then remove the "DRAFT" word from every page (since it is not meant to be part of the final document). This could also be done as a PLUGIN if one would like to specify the tag text and colour. Perhaps the biggest concert of Serif in providing us an API is related to security/privacy of its users and that's a noble reason for not releasing an API yet. Of course PLUGINS could be more dangerous than SCRIPTS from this point of view since they have a broader access to the native API of the platform (from enumerating/reading/writing files arbitrarily, to spanning threads, to sending data over the internet) but I've never seen anyone complaining about those issues on Photoshop or any other app that enable the use of plugins. You choose to use plugins from a reliable source and Serif could even be a curator for one of those reliable sources, but nothing mandatory. Another solution to this (and this would take a more considerable amount of time) would be Serif to create a full development platform with each and every API exposed (file access, document access, etc.) in order to minimise the existance of malicious plugins (and someone will always find a way to bypass it, trust me) and restrict programming languages to the one Serif itself choses (I'm not really fond of it but it seems the most claimed in the forums is Javascript). I could live with that with the right API. I'm not in anyway affiliated with Serif and I don't know if they have already decided on any of the issues I raised and my intent here is not to discuss the exact implementation the API will take (thou it could certainly be fun) but to gather opinions on it, specially on whether the API should use an open platform or a more strict one to prevent malicious extensions, and to gather things people would be interested in doing with the API and are not sure I covered above. I would also like if this space were to be used by Serif to talk to us about how they view the issue of the API and how/when they are planning to handle it and to it discuss with us in order to create something really useful for everyone.

+1

I've tried opening a PDF file on Affinity Publisher and could edit most of its content, saving as either PDF or AFPUB. Have you tried it? Perhaps you should be more specific as to what you're missing. As for forms, I've just seen a thread on the AFPUB forum asking for support for PDF forms, you should check it there.

With so many file format suport requests I think Serif should work on supporting additional file formats through a plugin model. I know most just want format X or Y but this would allow 3rd parties to implement such support and people could select only the format they actually need instead of getting an ever larger bundle. I'm definitely not invalidating this suggestion but only thinking that a broader approach could solve more similar issues.

To me this does not look like scaled drawing. Since any drawing is created with an associated measurement unit (centimetres, inches, pixels, etc) the feature @SpongeBob asked for should show those distances in the same unit used by the document (although I believe pixels in curves and diagonal lines would be an aproximation; maybe this feature could even be suppressed when using this unit). But yes, this would be nice to have when freehand drawing. I would go even further and do something similar when moving objects and nodes (I think knowing where it was and the distance it is from its origin could do wonders).

+1

I like this, especially when working with fine detail. I often need to zoom out and in again and again to see if the changes I made look as I expect them to and having a separate window with the zoomed out drawing would do wonders for my work.

Good to know.

As developers, we should never write software that is aimed at the most skilled of users (in any aspect); we have to think about the less experienced users first and then make sure the top users won't feel like they are being treated like toddlers. Also, even the most skilled developer might not want to have to deal with such trivial tasks such as associating additional file types with apps under their system's skin.

I have skimmed through most of this discussion so I'm not sure anyone has already asked or answered but is there any LEGAL (not TECHNICAL) reason for not supporting importing and/or exporting INDD files?

As you can see, a regular user might end up screwing things up while trying to do any of this. As a developer myself, I've been through this several times but I fail to see one reason (beyond mere will) for not letting the app tell the system what it can handle (and how) and then let the user choose via a simple and easy dialogue already existing in the system.

I think this link sumarises my issue here (plus that it describes how to do it for "IT Pros". Btw, thanks for the link. I was in need to get a bit up-to-date on the matter). According to this document, Windows 10 allows users to choose which app they want a file to be open with in two occasions: if it is the first time you try to open a file of that type, or if a new application registers itself as the handler for that file type in particular. So I may even associate my SVG files with AF Designer (by double clicking them first time, or using the "Open with..." contextual menu) but that will just create a generic file registration. In order to reap benefits of registered apps such as thumbnails and contextual menu options (both of which AF Designer does not handle right now but I sure hope it does in the near future), an app must try and register itself as a handler for those files using the Windows 10 API. Then, the next time the user tries to open that file (or use "Open with..."), the system will presen (unless it is suppressed, as stated in the same article) a dialogue so the user can choose which app to open the file with (and whether or not not ask this again for this file type). However, none of this will happen if AF Designer does not try to register itself as the default handler for SVG files.

As I noticed earlier, not in macOS versions. Windows is a whole different story.

I'm not exactly sure how to phrase that out there but I thought it was implicit when I said they could use it if they please as they please. I little bit of credit for the idea would sure be nice but not any kind of condition. I'll edit my post and try; if not fine, drop me a hint on that. I though of that too but would need to go about testing with real icon files to see how small it would be hard to distinguish the apps. Sure when the icon is all full of colour it is easy but smaller sizes such as 16x16 (and maybe 32x32 nowadays) could simply use the base logo of the app instead of any file icon.

v_kyr, I've seen now that you're a macOS user. macOS allows an app to register as many extensions they want and you can easily switch the app to use still reaping the benefits of it. However, the registration of file types on Windows is a little bit trickier and despite being possible to do the same in it, it will only register as a generic file association, usually without the same benefits. It would require a little bit more effort from Serif to do this on Windows and thus I mentioned the need for a preference dialogue.

That's the thing, they don't try to catch. They offer you the possibility to be associated with those files and thus reaping the benefits of this association. Choice is yours.

This would work mostly for macOS only since it is a little tricky to convert ICNS to ICO. I've been into this topic myself (just recently acquired AFDesigner) and agree with this but I wanted the icons to be a little bit more stylish and would like to cover the possibility of associating the apps with additional file types, if the user does not have another app for handling them (like SVG, IDML, AI or PSD). Also, it seems you didn't cover AFPhoto in your set. Well, here is my version: Instead of uploading ICNS or ICO files, I'd rather share my AFDESIGN file, fully editable and copyleft so anyone can work and enhance them and Serif may consider them as part of their copyrighted intelectual property and to use them (or any variation) if they please. branding.afdesign

Friksel, I didn't mean to use SVG as the main file format for AFDesigner, never. I know there are different purposes for each file type and I would not mix (I've played with Inkscape before, I know the drill). But as with any other apps like those, they may be used as the standard application for handling file types other than its main format. At its best, this comes in the form of a preference dialogue where the user is given the choice of which additional file types they want to be associated automatically with the app (among those it can handle). Brushes and swatches are only some of the options you would find there and you would still be able to keep SVG associated with your preferred source code editor. As for Serif to know with which program to open the SVG file, the easiest answer is to see the nature of the file (thus the suggestion to associate SVG with AFDesigner and not any other since SVG is a vector drawing by nature). I wouldn't, by default, choose to open PSD files with AFPublisher (this would be File > Place...) or INDD files with Illustrator (I think cannot even handle opening the file for any purpose whatsoever). Also, I know the SVG Explorer plugin and it's not that I distrust it but it doesn't work very well all the time and I think it could be handier if associating those files with AFDesigner worked like (better than) the plugin. Also this same behaviour could be applied to other file types for which you do not have another application to handle (you may think of AI files without Illustrator, for example).

That's the thing. I have tried only using the stroke settings on the toolbar. I'm on a Windows 10, latest update.

As far as I've seen, after version 1.7 each installed Affinity app shows up as a persona when I open any file but how will that work if I happen to have different versions of the apps, e.g. Designer 1.7 and Publisher 1.8?