Jump to content
tomek

Affinity Publisher Feature Requests

Recommended Posts

I know that you're hard at work with on the other cornerstone of the Affinity suite - Publisher. And having seen the quality of your work with the other two applications I have no doubt that you've done your homework. But, when doing research on this sort of development project it is easy to lose sight of things that are not on the development map. It's also easy to dismiss ideas that go against the architecture or particular implementation details. And in the end it is what is useful to the intended end user that is actually more important than the internals of the software.

 

Hence I would like to start a thread where all serious DTP experts, professionals and advanced users could contribute ideas. In particular, features that have been long standing requested of other software but haven't been implemented.

 

Anyway, I await the first beta of Publisher with much anticipation and to get started here's my first request:

 

Enable plug-in architecture similar to InDesign which would allow a whole Affinity eco system to flourish while freeing the core team to concentrate on the important bits.

 

cheers,

-tomek

Share this post


Link to post
Share on other sites

Hi rui_mac,

I don't think these two things should exclude each other.

We should definitely have a plug-in architecture mentioned by tomek as well as the facility to script the all the applications.

And you are absolutely right, this should be suit-wise.

Regards

Share this post


Link to post
Share on other sites

Well, I don't oppose to have both. However, implementing both is more complex for the programmers.
I use Cinema 4D and, in Cinema 4D, we have three main programming languages: COFFEE, python and C++

The first two (COFFEE is very similar to javascript and python.. well, it is python ;) ) can be used to create plugins and/or scripts.

The python plugins include the creation of new commands, new objects, new shaders, new expressions, etc.

Of course, coding in C++ will not allow for scripts (it requires compilation) but it is possible to create the best and fastest plugins.

I code in all of these languages but mainly in python as it provides me the best of both worlds... and it doesn't require compilation :D

 

I hope the Affinity suite gets something similar (python would be a great option).

Share this post


Link to post
Share on other sites

The plugin philosophy should be implemented suit-wise.

Specially if the plugins could be scripted in a scripting language, without requiring compilation in Xcode :)

I have to disagree whole heartedly with using a scripting language for plugins. Scripting languages should be used for what they were designed for: scripting. The way I see it a plugin adds a new feature ex. a new filter on an image and needs to implemented in pre-compiled languages as it will be interacting with vital program data. A script activates functions in the application the same way a user would by clicking something in the GUI thus allowing for automation of repetitive tasks, These are two very different things and should be treated as such IMO

Share this post


Link to post
Share on other sites

Well, scripting languages can be used to create plugins. It just depends on how they are dealt within the API.
I create fully working plugins, in Cinema 4D, using python. And those plugins include post-render filters, shaders what can produce new images or act as a bitmap filter, new objects (in Affinity Designer it would be a new type of shape) with handles and such, new commands, new tags, etc.

So, yes, a scripting language can be used to create plugins.

Share this post


Link to post
Share on other sites

Well, scripting languages can be used to create plugins. It just depends on how they are dealt within the API.

I create fully working plugins, in Cinema 4D, using python. And those plugins include post-render filters, shaders what can produce new images or act as a bitmap filter, new objects (in Affinity Designer it would be a new type of shape) with handles and such, new commands, new tags, etc.

So, yes, a scripting language can be used to create plugins.

I should clarify, I didn't say it wasn't possible to create plugins in scripting languages, only that it shouldn't be done. Especially with python which should not be used in production. Additionally scripting languages, due to their "compile during runtime" nature, are inherently slower than a native precompiled program, as well as more prone to errors due to the lack of checks before being run.

 

Finally in the case of python, python programs are difficult to distribute due to configuration and setup that are especially difficult for users who are not tech-savy and can be equally frustrating for people who are very tech-savy ie developers, due to poor configuration and setup handling that make it hard to replicate setups and even more difficult to recognize when setup is incorrect especially remotely ie a user complaining that your program isn't working.

Share this post


Link to post
Share on other sites

Well, not my experience with Cinema 4D.
I code once and the same code runs without modification in the Mac and Windows version of Cinema4D.
No problems whatsoever with configurations. I just provide a python file, and if the plugin includes icons or dialogs that I want to provide with resources instead of hard-coding them, I just have to provide the required folder structure. But it is all transparent to the user. It just needs to place a folder inside the plugins folder and restart Cinema 4D.
And let me assure you that some of the plugins are very, very complex ;)  ( http://ruimac.com/plugins.htm )
Also, python is seldom used in 3D and in studio environments, dealing with image and video.
So, python should not be disregarded.

Share this post


Link to post
Share on other sites

Well, not my experience with Cinema 4D.

I code once and the same code runs without modification in the Mac and Windows version of Cinema4D.

No problems whatsoever with configurations. I just provide a python file,

If your script runs using only the core python module i could believe you, however as soon as you start using other modules the configuration problems get exponentially worse. 

 

 

Also, python is seldom used in 3D and in studio environments, dealing with image and video.

So, python should not be disregarded.

Seeing as we are talking about python in the context of images, you would appear to be making my argument for me and arguing that I should disregard it. Additionally image rendering and graphic work is probably the most intense workload most users will put their computer under with professionals spend thousands of dollars upgrading their machines to save seconds, why would you want to use a language that is inherently (orders of magnitude) slower due to the aforementioned runtime compilation?

Share this post


Link to post
Share on other sites

Because not all users know how to deal with C++ (or Objective C) and don't want to mess with a full fledged IDE (Xcode) just to create a few tools.
If Serif could do like Maxon (creators of Cinema4D) and provide a C++ and a scripting language environment, great.
However, from my experience (I already coded lots of scripts/expressions and plugins, besides apps, of course), python is more than enough for most tasks. And I only got into speed limitations when I tried to code a ray casting shader that would have to deal with near-million polygon meshes.

I don't think that applications like the Affinity Suite would suffer from a interpreted scripting language, in terms of speed.
I really don't know how Maxon is doing it but, damn, python runs fast there :)

 

As for the modules, I'm working with lots of them, in some of my plugins.

For example, here is the first lines from one of my more complex plugins:

 

import os
import math
import sys
import c4d

import urllib2
import time
from datetime import datetime
from urllib2 import URLError, HTTPPasswordMgrWithDefaultRealm, HTTPBasicAuthHandler, install_opener, build_opener

from c4d.utils.noise import C4DNoise

from c4d import plugins, utils, bitmaps, gui, documents

 

And I haven't had to worry about including any of the modules when I sell my plugins.

Share this post


Link to post
Share on other sites

Sounds like I started something a bit contentious. Python is a fine language that is suited to both casual scripting and automation as well as developing highly sophisticated, pre-compiled plugins. I certainly wouldn't mind having Python available.

 

And yes, the plugin architecture should be suite wide, not just limited to a single app. In particular, the architecture should allow for live data exchange between the apps. So it should be possible to write a plugin that can interact dynamically between two documents open in two different apps of the suite. I can't give an example of a use case off the top of my head but my gut feeling is that this would be very useful.

 

An example closer to home of what I would like to see is that ability to interact programatically with external services. Here's my use case:

 

I am currently writing my masters thesis. I want to separate the content from presentation. I am writing the manuscript in Google Docs with the help of Paperpile. I want to use InDesign to handle graphical layout. I use DocsFlow to sync between Google Docs and InDesign. The system works really well. I'd love to be able to do something like this in Affinity Publisher, alas it feels like it won't be ready in time for me.

 

-t

Share this post


Link to post
Share on other sites

Sounds like I started something a bit contentious. Python is a fine language that is suited to both casual scripting and automation as well as developing highly sophisticated, pre-compiled plugins. I certainly wouldn't mind having Python available.

I am still going to disagree with using python for plugins, you can't compile an entire python program only modules which dramatically reduces performance, In the ipad pro thread Affinity devs are talking about how it will be faster than macbook pros due to the shared memory between cpu and gpu which will allow them to access the memory from the gpu without having to move it between discrete cpu and gpu memory a process which takes much less time than compiling human readable code to bytecode. they are focused on clock cycles and the difference we're talking about here is orders of magnitude more than clock cycles. 

 

However python IS fine for scripting IE invoking actions in the programs for automation purposes. 

Share this post


Link to post
Share on other sites

How come python is fast enough for 3D plugins (and I made quite a few that require hundreds of thousands of interactions) but not for a 2D vectorial application? ;)

 

Actually, I made a plugin a few months ago that, while testing, I tried to break it with a mesh of 16000 polygons. That means (16000 x 16000 = 256 000 000 iteractions). And, even if at the beginning, it was taking 4'19" to make all the calculations, I was able to optimize it to perform the 256 000 000 calculation in just 50".

Yes, 50 seconds is a long time, but the same code in compiled C++ took almost 20 seconds to calculate (there were complex calculations involved for each iteration).

One plugin that I'm working on creates tree-like structures. It calculates splines in 3D with up to three branching hierarchy levels. So, three levels of, lets say, 7 branches each will result in 7 x 7 x 7 = 343 segments. And each segment has several points to be able to create a curve. So, this means thousands of control points and for each branch (and branch of branch and branch of branch of branch) lots of trigonometric and vectorial calculations are required (the branches have parameters like spreading, length, waviness, bending, wind, etc).
And, even so, python calculates it in near realtime. I though that re-coding it in C++ and compiling it would make it even smoother but I only gained an extra 8 to 10% of speed.

 

So, from my experience with python at solving problems that require lots of calculations done in a fast way, it works very well.
But, this is only my experience :)

Share this post


Link to post
Share on other sites

And, even so, python calculates it in near realtime. I though that re-coding it in C++ and compiling it would make it even smoother but I only gained an extra 8 to 10% of speed.

I am not arguing that python CAN'T do it, just that we shouldn't use it that way and that the performance gain is worth it, even if it's only 8% because it adds up quickly.

Share this post


Link to post
Share on other sites

Hi,

The way I look at this is as follows:

 

1. Scripting is for automation.

2. Plug-ins are for adding new features to the software, ecosystem.

 

Certainly, there are areas that these overlap in but as a general rule they have different purpose in life.

 

We need both.

Users, should be able to string together commands to automate repetitive tasks.

Programmers, should be able to use languages like Objective-C, and hopefully Swift, to extend the software in ways not foreseen by the developers.

 

For scripting, I would like to see JavaScript, but preferably Swift. Yes, Swift has been pitched by Apple as a Scripting language too. That would be terrific. AppleScript would be a welcome feature but looking at Apple's ambivalent position on it leaves me a bit cold. Not all applications written by Apple itself are AppleScript'able. 

I would not like to see Python in any shape and form, but this is only my opinion.

 

It would be great for someone from Affinity to give us a clue whether this is even on the cards.

They are usually very upfront about features but in this particular instance they are still moot.

 

Let's hope they have something great up their sleeve.

Regards

Share this post


Link to post
Share on other sites

Well, if I have to fire up Xcode and deal with project files and specific APIs to create plugins for Affinity Suite, I will think twice before doing it.

If I only need a text editor, I will not think twice ;)

Share this post


Link to post
Share on other sites

We need both.

Yep.

 

I would not like to see Python in any shape and form, but this is only my opinion.

Me too.

 

 

Well, if I have to fire up Xcode and deal with project files and specific APIs to create plugins for Affinity Suite, I will think twice before doing it.

If I only need a text editor, I will not think twice ;)

I get what you're saying and can't say I'm any different, BUT if its important enough you'll do it anyways.

Share this post


Link to post
Share on other sites

I agree with everyone... to a point:

 

  • I agree that "low level" compiled languages provide superior performance and even enable methods that are not possible to use with "scripting" languages.
  • I don't have any particular preference for a scripting language.  A well designed plug in API could be made available in whatever language the developers choose to support and the same functionality could be accessed from C++ as well as JS or Swift or Python or Ruby. Then everyone gets to pick their favourite and the world is happy.
  • I do not want to use anything more than a text editor to write a simple script. Requiring a full blown IDE for scripting will be a big barrier to creating a rich and thriving ecosystem.

Share this post


Link to post
Share on other sites

Publisher documents should have the notion of Sections

 

InDesign documents have the notion of Chapters, if one is working on a book type document. Non-book documents do not have a section-level grouping of content. Yes, there are "sections" that one can create using the "Number & Section Options" in the Pages panel but these "sections" are not really first class citizens in the document. Rather they're more like a meta citizen.

 

In particular, there is no way to use the "section marker" in numbered lists.

 

Publisher should implement Sections in such a way that sections can be referenced in a variety of ways, and in particular section numbers should be available in numbered lists.

 

Share this post


Link to post
Share on other sites

Add ability to manipulate case in paragraph styles

 

InDesign has a tool in the Type menu which allows one to change the case of a string of text into various general formats (Title Case, Sentence case, etc). However these options are not available in paragraph styles. One can only select form a much less useful list of Normal, All caps, Small caps. This is very annoying.

 

Being able to change case should also be available in Find/Replace dialogue which needs to be at least as powerful as what's in InDesign and could be even more so.

Share this post


Link to post
Share on other sites

Would like to point that will be great to not only have colums managment but also FIELDS management, for some reason indesign, as pagemaker did, only have a good columns management but for a good rich publication will be good to be able to create the entire cross and the in between fields.

Just a thought  :)

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.