Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

Hello all!

 

I am trying to automate the creation of  my POD (Print on Demand) designs.

1 design with a variable item.

using CSV lists of veriables

then exporting batches with automated naming of exported images

See link for reference:

https://youtu.be/1F8488bNrGQ

 

The person in video is using Adobe scripts and a product such a as Google Sheets .

Is there a way to do this with one of the Affinity products?

I have them all.

print on demand and automation is huge.  
I would like to use Affinity products for this.

If not, I  welcome any recommendation for any external apps that may work with Affinity software  in order to achieve this.

 

Thank you!!

 

Link to comment
Share on other sites

49 minutes ago, Ninjas said:

Is there a way to do this with one of the Affinity products?

I have them all.

We can do all that with the exception of the Naming of the files via the spreadsheet/CSV file.

Use Publisher to Merge the Month name and Year.

Use Designer to export the individual pages from the Publisher file as individual PNG files. Won't have March 1985 as a name it will be Slice12 or Page12 or some such vanilla name. If you are familiar with python you can write a script which would take the Month name and Year from the CSV file and rename the PNG files from Designer.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

1 minute ago, Ninjas said:

Do you know if there are any pre-made scripts available somewhere that I can tweak?


Does a script translator exist that will convert an Adobe Script to Python script?

 

No I don't know of any pre-made scripts.

Not to my knowledge.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

Survey results – A rich collection of statistics & diagrams about spread languages, tasks, plans, gender, et al…  https://www.jetbrains.com/lp/devecosystem-2021/

Quote

The State of Developer Ecosystem 2021
This report presents the combined results of the fifth annual Developer Ecosystem Survey conducted by JetBrains.
31,743 developers from 183 countries or regions helped us map the landscape of the developer community.

Just 3 samples…

1233137623_programminglanguageprimary.jpg.f6682543e829611644916d95cce9ccee.jpg

104815886_programminglanguagemigrateplans.thumb.jpg.10399195c1b8e72a144f44e76153cf0b.jpg1296582740_programminglanguageglobal.thumb.jpg.b7732c549fccb312d23b8c6f10568a01.jpg

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

On 9/10/2021 at 10:28 AM, thomaso said:

Just 3 samples…

SQL is a domain-specific language that does not really belong in a comparison with the others.  It is like comparing the popularity of apples, oranges and Japanese.  That alone likely skews the results to the point of being less meaningful than a proper comparison.

Ignoring that I do find it to be a sad reflection on the state of our culture that so many programmers today tend to favor some of the worst programming languages in existence that none of the more reasonable ones (except SQL which again doesn't really fit with the others) even make it into the lists.  People are in so much of a hurry to produce fast sloppy coding with cryptic syntax that no one is taking the time to produce solid, readable code.

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

+1000 for scripting support in any affinity package (photo or publisher preferred for me)

 

Here's our current use case with scripts I made for Photoshop:

We built an online system that captures info about projects. Name of the project, dates, the amount of images and their names, the version of the image, the location of the files in Google Workspace etc. When ready our online system spits out a csv for us, for each image.

In Photoshop I then run my script which brings up a custom UI, where I go and select the various CSV files. It then reads the info from the csv, opens up the relevant template from Google Workspace depending on the type of image, then it does a datamerge into the template, adds text, version info, injects metadata etc. Then it saves the image in jpg, tif and pdf in various resolutions into the correct project folder on Google Workspace. Then it computes the next csv in the list etc.

 

It all is fully automated. Only thing I do is open Photoshop, run the script and select the csv files. EVERYTHING then happens by itself. I dont need to go search for files or browse to folders or resize things or copy paste export or anything. My script does it all.

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

Pleeeeeeeeeeeeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaseeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!

Any language, I do not care, I just want to have it.

The reason for me is: As by no doubt there is considerable lack of programming resources at Serif, such a feature would take off quite some burden from Serif, i.e. many feature requests would vanish or never be asked for. So, I think, Serif themselves would profit the most from it.

Just to add some specific points: Join scripting with macros, i.e. macros for all programs and make macros scripts (that can be edited, not like now, which drives me crazy). And I recommend to have a well designed user forum to share and exchange macros (OK, I am old school and hope this won't be NFT macros then... 😉)

Link to comment
Share on other sites

+1, please open the apps up for any suitable scripting language. I don't much care which one either. If you do it will extend the usefulness of the applications immensely.
We have several hundred scripts we use for InDesign, about 20 of them every day, and it is all functions that are customised to the way we work, doing exactly what we need, saving hours and days of work on almost every file we process. Without them, we would step back about 10-20 years in processing. If InDesign didn't "have scripting" it would be rendered useless for us and we would need to ask our clients to please send us something else. 
I work with tech/layout support for translation, but there are so many other professional use cases in DTP and publishing where scripting is the "absolutely necessary" feature.

Link to comment
Share on other sites

  • 3 weeks later...

Sad, 2022 no scripting yet. 
It's a blocking feature, I do use affinity designer for editing and making small stuff, but when it comes to prod, especially on big projects with a lot of layers and multiple resizing and specific export process, I still use other softwares. there is no way I waste 4 hours of work doing the same thing again and again (resize, apply filters, export layers with specific names...), no way I would spend hours killing my brain neurons.

Please add scripting, no matter what language or how hard it's made it should be fine.
Thanks

Link to comment
Share on other sites

As the OP, I'm amazed that nearly 4 years later there is zero information or progress on this. The second post in the thread suggest Affnity had plans for scripting but after 4 years there's nothing.

As I've said before, I expect Affinity are happy for Publisher to be the 'backyarders' publishing program because without scripting it's unlikely to ever supplant InDesign in professional production environments. It's truly disappointing.

Link to comment
Share on other sites

6 hours ago, kimtorch said:

As the OP, I'm amazed that nearly 4 years later there is zero information or progress on this. The second post in the thread suggest Affnity had plans for scripting but after 4 years there's nothing.

The fact that it is pinned indicates Serif recognizes the keen interest that certain users see in this area, and if experience is any guide, this is one of the projects that they hope to get to, if they haven’t already begun. The problem is that this would be a huge effort to make the software scriptable, and while they apparently agree the effort will be justified (based on my starting assumption due to the pinned thread), they also have other popular big requests. Footnotes is an example of another big request with a lot of people requesting it or even saying it is a deal-breaker.

As Serif has only small teams (and appear to always be looking for more programmers to hire), they can’t do it all at once, and I would suspect they are prioritizing those projects that have the best return on customer satisfaction as compared to development time in their estimation. Footnotes versus scripting, for example: we have public confirmation that Serif has been working on that for some time. It turns out footnotes can actually have a lot of complexity when you start to think about it, if it is done well (and I have every reason to believe they do mean to do it well). However, I still think scripting would be the larger project. So of the two, I would not be surprised if Serif may have chosen footnotes before scripting, all the while meaning to do both.

So that is just some perspective for understanding. I don’t think Serif is holding back for any reasons other than available resources, and they are trying to prioritize to balance all the requests. I understand it is disappointing that we do not have scripting yet (I want it too). But I can understand the why, and it does not hurt my view of Serif. I also want footnotes… and a multiline composer… and column span and split… and running headers based on text styles (variables)… and a book feature… and on and on. I understand I can’t have it all right away. Four years is not right away, but we still have a large list of features clamored for by different groups of people, all of whom say that these requests have been going on for several years. So Serif can’t really win in this case: someone is going to be unhappy even as others finally get what they asked for.

Link to comment
Share on other sites

  • 4 weeks later...
On 8/30/2018 at 6:20 PM, kimtorch said:

Are there any plans to add scripting support?

I notice there is no Applescript library at all but am interested to know if there are plans to add Applescript or perhaps Javascript support. Virtually everything we do as far as creating PDFs, packaging, placing images and text, formatting, proofing, sending pages to print etc is done via script.

Tagged text goes hand-in-hand with scripting so I think this needs to also be supported.

Yes, even there are plentiful of indesign prodcutivity scripts/plugins available that greatly enhances productivity. Please add scripting/plugin capabilities to rival indesign .

Link to comment
Share on other sites

  • 3 weeks later...

It is not hard to understand that InDesign is a real beast to compete with. It would be great to see some steps being taken in the right direction though .
I understand it is complex and all that, and also of course, we need to understand that it took a few years even for a giant like Adobe to push InDesign to supersede Quark in this respect, even though it was launched as a "Quark-killer", with a very modularised buildup, promising fast development of plugins from third-party developers. But while Quark had its XPress Tags, it had nothing like InDesign's ESTK.

The way forward for Affinity? Maybe it could be good to utilise extended javascript, like Adobe did. I am not a developer, I just "cheat". It sounds like a lot of work making the DOM and parts of the interface available for a scripting language. But since we have other possibilities today, maybe it would be smart to look at, for instance, Lua? Python would be another possibility, having been used a lot for similar things, and being just as easy, if not easier, to learn than Javascript. It may feel more "worth it" in these days to learn Python, for an inexperienced would-be Publisher automator developer.

To continue with the more technical aspects: the big big change for InDesign and usability/automation friendliness came when they switched from INCX/INCD to ICML/IDML. Every collection of objects (one or many) in a document could be replicated in any other document by the use of so called snippets (INDS), supporting every possible object you can think of making inside inDesign, save for the actual document "framework". Best of all, the code is valid XML, not just some tagged text.

The same goes for every collection of objects in a text frame/story. The code is very wordy, and a bit strange when you look at it, but the way they solved it, everything in a story is viewed as a "text style range", so there is no hierarchy with paragraphs and such. This also means the underlying "tagged text" is totally portable. But very hard to read for a human being. I can heartily recommend a look at the code in an InDesign snippet, or an exported InCopy Story. It is totally readable (although, as I said, very wordy) in any text editor. 

Link to comment
Share on other sites

  • 1 month later...
On 6/6/2019 at 8:50 PM, v_kyr said:

Related to the overall fruitless scripting debate here, it doesn't matter what sort of language finally would be used, as far as the chosen one is powerful and fast enough to express the kind of things and algorithms people have in mind to build for the tools. So more important is to map a rich reusable set of the internal functions into that language then and also offer integration hooks into the UI.

It also should be a secure language to prevent security issues and malware attacks.

Link to comment
Share on other sites

There is no such thing as a secure language. There may be safe or unsafe implementations of code or of a run-time compiling of it, but that is up to the developer. I think all the languages that might come up for discussion already have HTTP and file system access, and necessary limitations of them, built in anyway.

This would, or so I think, in 99% of the cases be run locally on a computer, for controlling objects within documents. It would be run as an extension of the application, using whatever is available in the DOM. People will want to do batch processing, so there has to be at least rudimentary file system access. But most jobs done by scripted extensions can be done without even a network available, as long as the files have ended up on the user's drive before processing starts.

Or were you thinking of security as in "somebody might steal my code"? That is usually done by compiling (or whatever you like to call it). For comparison, ExtendScript has .jsxbin, for those that like to use it. Personally I don't care much for that. It is better to have the code editable immediately if you want to make small changes, as you will want to.

Link to comment
Share on other sites

3 hours ago, zixdesign said:

There is no such thing as a secure language.

This is basically true. You have to be aware, if you do a search, for secure (or insecure) programming languages, which are the 'bad' ones. If you find out that C is very insecure, it is not the language they are referring to but the number of bugs found in C code. That is the fault of the programmers, not the language itself. It's easy to write bad C code, and plenty of people have and (still) do, but it is even easier to write bad PHP code. I lost count of the number of badly written and insecure PHP scripts that I have encountered over the years and I have only a limited knowledge of PHP. The barrier to entry for writing PHP is very low, so you end up with a lot of low grade programming.

There are languages around which are considered 'safer'. Tcl is one of these and it's a scripting language. What's Tcl? Nobody uses Tcl, I hear you say. Not so! It is imbedded in just about all Cisco routers and F5 load balancers. Service checks on F5s are usually written in TCL. And one time I recall totally bamboozling a network engineer when I did something in a Tcl loop on his big Cisco which he was doing line by line.

Go is a more modern implementation of C and it has some features which make it safer. But it's not a scripting language so is probably not suitable here.

Link to comment
Share on other sites

1 hour ago, LondonSquirrel said:

That is the fault of the programmers, not the language itself.

Yes, but the first mistake most of those programmers make is choosing to write code in a language which promotes the creation of bad code.  Languages such as C and its ilk are among those, providing easy access to lots of ways to quickly shoot yourself in the foot.

Not only that, but the code is so cryptic that it is very easy to miss a lot of those mistakes when reading the code.

Languages such as Ada were specifically designed to prevent a lot of those problems by making it much harder to make the mistakes to begin with, while also providing a much more readable syntax which makes it much easier to spot errors when they are made.

There are a lot of tools out there to do semantic checking of C code and the like to spot many of the more common errors, but I've seen even those tools miss things completely that, had the code been written in Ada instead, never would have made it past the compiler to begin with - and if it had, it would have triggered a runtime error pointing directly to where the problem was instead of corrupting data structures in memory and leaving a programmer scratching his head and spending hours trying to find out where the issue was.

A lot of programmers seem to think that because they can write code faster in a language like C with its shorter cryptic syntax it will save them time - but in reality, over the lifetime of a project, a lot more time is spent finding and fixing bugs or in reading old code and trying to figure out what it did than is spent in writing it in the first place.  Those things are much faster in languages such as Ada and the overall time spent on the project decreases when using a language which makes bugs harder to get past the compiler and code easier to read, rather than focusing on how quickly bad code can be created and added to a project.

Some security issues are the results of bad design, and that is something the language won't be able to help with, but many of them are the results of bugs, and the choice of language can have a huge impact on weeding out those bugs before they ever make it into production code.

Link to comment
Share on other sites

Well C is a pretty old language, developed around 50 years ago and thus those days created with completely other criterias in mind, as one would nowadays expect here from more modern, newer programming languages. Programming languages evolved a lot over time and the modern/younger ones do take programming related things into account former languanges didn't in the same manner. - Times do change, requirements too, as do the development tools which help to write (hopefully) better code and so on.

With older programming languages like C/C++, it was and still is solely the responsibility of the programmer who uses the respective language, to ensure that the code is clean, syntactic good readable & maintainable and ideally also as error-free as possible etc.

In contrast to that, modern languages like Rust/Go/Swift/Kotlin/C# etc. do partly already address certain of the weaknesses of older prog languages like C/C++, aka the lessons learned from certain former programming languages problems here. - Adding to that then over time also a fair amount of more evolved software technics knowledge, about using the right design patters & performing good refactorings, reusing good conceived frameworks, doing agile development for complex team developed software etc., can overall lead to better maintainable and more error free software.

Security is a very broad concept and difficult to handle in every imaginable aspect everywhere. It is difficult (if at all) to guarantee absolute security and it is always the responsibility of the developers to implement this as well as possible.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
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.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | 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.