Jump to content

Lmpessoa

Members
  • Content count

    36
  • Joined

  • Last visited

Everything posted by Lmpessoa

  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.
  2. Lmpessoa

    Scripting

    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.
  3. 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.
  4. 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.
  5. That makes at least a market of two.
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. Lmpessoa

    API Think Tank

    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.
  11. 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.
  12. +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.
  13. 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.
  14. Lmpessoa

    PDF Editor

    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.
  15. 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.
  16. 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).
  17. 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.
  18. I think a lot of people here use Affinity Designer to work with SVG files thus I'd like to suggest enabling associating SVG files with Designer by default. Also, since Windows itself cannot preview those files, it could show a preview instead of a file icon.
  19. 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.
  20. 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?
  21. 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.
×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.