Scripting

[Peter Kahrel]

> Those of us who would love to experiment with it early would send an invaluable feedback to the devs, which in my opinion is as important as the release itself. And those who love living on the edge would start using it early and learn what works what what doesn't.

Absolutely. Good point.

[Tim France]

On 1/12/2024 at 9:03 PM, kimtorch said:

Speaking of import/export, is there any news on whether there will be some form of text tags for scripting formatted text?

Hi @kimtorch,

Could you clarify on what you mean? Are you referring to parsing some text with tags in them or do you mean tagging text frames / individual bits of text with a tag and then have a script use those tags to find and manipulate bits of text? I'm assuming the latter because the former doesn't require app support - it would just be a case of writing a script to parse the text. If you mean tagging bits of the DOM (like text frames) or individual glyphs within a story, that is something we're already considering. Could you describe a standard use case?

[kimtorch]

31 minutes ago, Tim France said:

Hi @kimtorch,

Could you clarify on what you mean? Are you referring to parsing some text with tags in them or do you mean tagging text frames / individual bits of text with a tag and then have a script use those tags to find and manipulate bits of text? I'm assuming the latter because the former doesn't require app support - it would just be a case of writing a script to parse the text.

I truly hope you're kidding. It DEFINITELY requires a filter for import, parsing complex text and trying to format with style runs belongs back in the 90s... The sort of text munging you're talking about would be primitive and horrible.

Surely the folks at Affinity are familiar with Quark tags or Indesign tags? Scripting without proper tag support would be like a car without fuel. If you want Publisher to be seriously considered an alternative to InDesign (or Quark) it has to at least support the things publishers need.  A short example of InDesign tags:

<ASCII-MAC>
<vsn:7.5><fset:InDesign-Roman><ctable:=<Black:COLOR:CMYK:Process:0,0,0,1><C\=100 M\=0 Y\=0 K\=0:COLOR:CMYK:Process:1,0,0,0>>
<pstyle:><pta:Left><ct:Bold><cs:50.000000><cl:48.000000><cf:Helvetica Neue>Historic boat shed saved in Putney<ct:><cs:><cl:><cf:><pta:>

It allows text to automatically format on import either manually or via script. Importantly this covers any inline formatting Eg. a single word in italic, a few words underlined etc.

Tagging frames etc is also crucial so you can properly address the target of your function. As I've described before on here, InDesign has script labels which are simple metadata for frames - they can be set via script so you can do things like: (pseudo code)

tell active document
create frame with properties (100,100,0,0 label:"Putney123", color:"None", text:"this is some text")
tell Putney123
set story 1 to Bold
end
end 

This means a page can have multiple frames but they can easily be targeted by label.

I can't believe that more than five years after this thread was started we're answering questions about features (tags) which were raised in the very first post of the thread. My confidence in Affinity doing this properly is now basically zero as it appears they have no idea what is actually required.

[Jon W]

Hi @kimtorch.

We are doing our best to engage with our users and understand their requirements.  

Our primary focus is to expose existing application features to scripts/plugins; text support is just one part of this. We are software developers, not publishers, and although we often liaise with the Publisher team regarding text matters, they are not really scripting experts. So you might have to explain some things that may seem obvious to you. 

We are aware of InDesign text tags: as I understand it, they are primarily used to map to text styles on import.

What we're trying to understand, and I hope you can explain, is how this relates to scripting. I would guess that perhaps you envisage a script which would run as a tagged text import filter, overriding the tag -> style mapping which would normally be set up manually in the app?

[kimtorch]

15 minutes ago, Jon W said:

Hi @kimtorch.

We are doing our best to engage with our users and understand their requirements.  

Our primary focus is to expose existing application features to scripts/plugins; text support is just one part of this. We are software developers, not publishers, and although we often liaise with the Publisher team regarding text matters, they are not really scripting experts. So you might have to explain some things that may seem obvious to you. 

We are aware of InDesign text tags: as I understand it, they are primarily used to map to text styles on import.

What we're trying to understand, and I hope you can explain, is how this relates to scripting. I would guess that perhaps you envisage a script which would run as a tagged text import filter, overriding the tag -> style mapping which would normally be set up manually in the app?

Here's a typical workflow for us (we're a newspaper/magazine publishing company). Editorial is written in a (proprietary) app running MySQL (most editorial systems do similar). The writers never open InDesign.

A section will be applied to stories (Front Page, EGN, Real Estate, Features, Entertainment, Sport etc) In our particular case, we apply styles based on section. EG. Front page heading might be Helvetica Black at 120/110 where basic news might be Helv. Bold 72/70. Captions will be different as will Bylines and Intros. This general style is set as soon as they select the Section but editorial staff can also add styles to any word or text run and custom tags will be added to the text. If we want a word in Bold for instance, it might be simply enclosed in <b></b> tags which are interpreted by the app into correct InDesign tags before insertion into the database. This is all handled by the app - editorial staff never have to enter any tags. It also calculates depth and shows previews so they can be sure sizing is correct (they can manually over-ride a heading for instance)

Once the story is saved to the database, a companion app is used to call stories onto the page. It creates (by script) the required frames and labels them with the Story_ID, partID (Heading, Sub Head, Caption, Intro, Body, pull-quote, Cross Head etc). Then the story is placed (by script) and the tags are interpreted by InDesign so the text is formatted exactly to style - regardless of which section they've chosen. Editorial staff know nothing about styles, they simply allocate stories to the correct section.

The real beauty of this is it requires NO styles to be set-up in InDesign - so no, it doesn't map existing styles - it is totally independent of character or paragraph styles and can be done on a brand new machine with a clean install and still work.

It also handles updates and corrections. If a journalist changes a story, removes words, changes sections or italicises different words in a story that will all be reflected when the story is re-imported and the text will always be formatted correctly. Updated stories are flagged in the Place app so prepress people know they need to be updated.

I should point out it places images and brings them in with styled captions. It has functions to send directly to Wordpress (and Apple News) and the styles are automatically translated - although these are mapped to the existing styles on those platforms.

Everything I've said, importing text, setting styles, linking captions with their images, styling heading, sub headings, intros, bylines and body text is ALL done with scripting and tags. Scripting in professional publishing isn't about creating fractals and pretty lines. It NEEDS to be able to manage large quantities of text and format it seamlessly.

Here's another example. Someone builds a 400 page catalog. All the data is in a database with tags. It can be flowed onto pages, frames created and labeled based on sku numbers, text formatted, images placed and styles and colours applied based on the section of the catalog. You could potentially build the entire thing in a few minutes.

I appreciate you're trying to get this working but I'm not sure exactly which users you're trying to engage with. This has been one of my concerns since starting this thread - many of the people commenting sound like they have never scripted Quark or InDesign - they seem more intent on pushing their favourite programming language.  

I'm sorry if I'm sounding harsh but I'm staggered the functionality of scripted document production and tagged text needs to be explained. It's really automated publishing 101.

The line in your post I find most interesting is "We're software developers not publishers". This is why you need to be talking to publishers. Do you think Adobe created InDesign without speaking to Quark users?

The reason our system works so well is because it was written by someone who had more than 20 years experience in publishing before starting it. You're never going to satisfy users if you don't know what they need.

[Seneca]

Surely, scripting will not help with importing tags if there is no tag import/export support in the software itself in the first place.

So rather than asking for scripting support for tags you should be asking for Tags import, export support in Publisher first, like what we have in inDesign and QuarkXpress.

Then scripting will expose all that capability to us users/scripters and you can craft your script in the way you described above.

Personally, I don't think you sound harsh, you want to make sure that we have that capability in Publisher as well, which I sincerely hope so too.

[Petar Petrenko]

33 minutes ago, kimtorch said:

Here's a typical workflow for us (we're a newspaper/magazine publishing company). Editorial is written in a (proprietary) app running MySQL (most editorial systems do similar). The writers never open InDesign.

Do you want (and do you use) something like WordsFlow from EmSoftware?

[chessboard]

1 hour ago, kimtorch said:

The line in your post I find most interesting is "We're software developers not publishers". This is why you need to be talking to publishers. Do you think Adobe created InDesign without speaking to Quark users?

Did you read the line:

Quote

We are software developers, not publishers, and although we often liaise with the Publisher team regarding text matters, they are not really scripting experts.

Both Jon and Tim are part of the scripting development team, not the publisher development team. They develop the scripting feature for all three applications: Designer, Photo and Publisher. I find it quite understandable that they are specialists in their field and not for photographic, design, illustration and publishing software issues.

[Affinityconfusesme]

I hope we will know soon what version of affinity this will become available even if the team needs another six months or even longer.

[MikeW]

7 hours ago, kimtorch said:

I truly hope you're kidding. It DEFINITELY requires a filter for import, parsing complex text and trying to format with style runs belongs back in the 90s... The sort of text munging you're talking about would be primitive and horrible.

Surely the folks at Affinity are familiar with Quark tags or Indesign tags? Scripting without proper tag support would be like a car without fuel. If you want Publisher to be seriously considered an alternative to InDesign (or Quark) it has to at least support the things publishers need.  A short example of InDesign tags:

<ASCII-MAC>
<vsn:7.5><fset:InDesign-Roman><ctable:=<Black:COLOR:CMYK:Process:0,0,0,1><C\=100 M\=0 Y\=0 K\=0:COLOR:CMYK:Process:1,0,0,0>>
<pstyle:><pta:Left><ct:Bold><cs:50.000000><cl:48.000000><cf:Helvetica Neue>Historic boat shed saved in Putney<ct:><cs:><cl:><cf:><pta:>

It allows text to automatically format on import either manually or via script. Importantly this covers any inline formatting Eg. a single word in italic, a few words underlined etc.

...

Personally, I prefer QXP-style text tagging as it is less verbose.

Both ID's and QXP's tagged text import routines are actually scripts wrapped in a Plug-in/XTension wrapper. So a script could actually handle both the creation of primitives and placement/formatting of text. Em Software's Tagged Text Plug-in/XTension are also script-based...but take the capabilities further than native ID/QXP.

That said, it would be a major job to write. I highly doubt Em Software would also build a plug-in for APub due to what would be poor sales. Plus, they likely would use SaaS as the selling method like they do for ID.

I would recommend that @Jon W and @Tim France download Em Software's Tagged Text PDF manual(s) to understand what such a Plug-in is capable of--then extend it even further than Em did.

[kimtorch]

9 hours ago, Seneca said:

Surely, scripting will not help with importing tags if there is no tag import/export support in the software itself in the first place.

Precisely, but I didn't think it would need to be explained when Quark and Adobe have been doing it for decades.

For  @Jon W and @Tim France , the reason this is important is the script code which needs to be written. If you don't have the ability to read tagged text then parsing and trying to assign styles has to be done in the script code which would be horrendously bad. I'd go as far as saying people simply wouldn't do it.

If you can read tagged text through an appropriate filter an entire formatted, aligned, coloured and styled text block can be done with a single line call:

place tempfilepath on myFrame showing options no given «class rtfo»:yes

 

[kimtorch]

9 hours ago, Petar Petrenko said:

Do you want (and do you use) something like WordsFlow from EmSoftware?

No. We don't use Word.

[kirk23]

I need scripting I could  use chatGPT4 for .   Not just any scripting.     So far  Chat GPT is good  for writing python scripts for Blender . Not sure it's open source nature  or it have just been trained well on Blender  but it's where  it actually works.   

Persuading  it to write you  3d max script is its own challenge  for example .   For photoshop it may take days  with miss and hit  before Chat would write you java script that actually works.

So please do something ChatGPT would proficient with.     Not another  " Thank you for buying our product. Now kindly hire a programmer"

 

[chessboard]

I assume that chatGPT generates Blender scripts quite well because there are many references on the web that chatgpt has "learned" from, due to the open source nature of Blender and therefore a large number of users who know how to script and share their scripts on the web.

Similar knowledge cannot be expected for affintiy scripts, as chatGPT does not learn to script. It does not "know" anything about scripting logic and scripting languages, nor does it understand how to read API documentation and combine this information with knowledge of the rules of a particular scripting language. It simply can't think. Instead, it simply collects scripts that others with knowledge of the scripting language have already written and can combine them into new scripts. This works all the better the more often the tasks set have already been solved and published on the web. If you ask chatGPT to create a script for a very specific and unique purpose, it is more likely to fail.

Scripting in Affinity will be so new that chatGPT will not immediately find enough scripting input. If scripting in Affinity becomes popular, the later versions of chatGPT will probably also be able to generate scripts for the Affinty applications. It is not a question of which scripting language is used. There just needs to be enough sample material available.

[kirk23]

10 minutes ago, chessboard said:

I assume that chatGPT generates Blender scripts quite well because there are many references on the web that chatgpt has "learned" from, due to the open source nature of Blender and therefore a large number of users who know how to script and share their scripts on the web.

Similar knowledge cannot be expected for affintiy scripts, as chatGPT does not learn to script. It does not "know" anything about scripting logic and scripting languages, nor does it understand how to read API documentation and combine this information with knowledge of the rules of a particular scripting language. It simply can't think. Instead, it simply collects scripts that others with knowledge of the scripting language have already written and can combine them into new scripts. This works all the better the more often the tasks set have already been solved and published on the web. If you ask chatGPT to create a script for a very specific and unique purpose, it is more likely to fail.

Scripting in Affinity will be so new that chatGPT will not immediately find enough scripting input. If scripting in Affinity becomes popular, the later versions of chatGPT will probably also be able to generate scripts for the Affinty applications. It is not a question of which scripting language is used. There just needs to be enough sample material available.

It's might be true   but much to my surprise  ChatGPT4 actually suggests  ideas how to solve things  if something doesn't work.  I subscribed for a month  and see the difference .     Looks a bit  like thinking  actually.   It's just pretty tiresome to check its ideas  since only one  from 10 works .   It did me a few nice  Photoshop scripts I couldn't do  myself . But it took me a whole weekend.    More approaches it did to workaround something slower it starts to work  , up to so slow you wait half an hour for each new piece of code  . And if the code still doesn't work  it starts to do useless detours and back rounds  and you constantly need to focus it  on exact task.     

[CM0]

1 hour ago, chessboard said:

I assume that chatGPT generates Blender scripts quite well because there are many references on the web that chatgpt has "learned" from, due to the open source nature of Blender and therefore a large number of users who know how to script and share their scripts on the web.

Similar knowledge cannot be expected for affintiy scripts, as chatGPT does not learn to script. It does not "know" anything about scripting logic and scripting languages, nor does it understand how to read API documentation and combine this information with knowledge of the rules of a particular scripting language. It simply can't think. Instead, it simply collects scripts that others with knowledge of the scripting language have already written and can combine them into new scripts. This works all the better the more often the tasks set have already been solved and published on the web. If you ask chatGPT to create a script for a very specific and unique purpose, it is more likely to fail.

Scripting in Affinity will be so new that chatGPT will not immediately find enough scripting input. If scripting in Affinity becomes popular, the later versions of chatGPT will probably also be able to generate scripts for the Affinty applications. It is not a question of which scripting language is used. There just needs to be enough sample material available.

People have demonstrated you can simply point it to the documentation for any set of apis. Since it already knows javascript, it should perform just as well for Affinity as anything else.

[chessboard]

@CM0

I really doubt that this would work. But we will see. Would be nice if you could give some links to see how they did this.
 

[CM0]

4 hours ago, chessboard said:

@CM0

I really doubt that this would work. But we will see. Would be nice if you could give some links to see how they did this.
 

I have seen claims such as this, haven't tried it myself but it should work. There is a lot of focus on getting LLMs to be able to read your own docs, PDFs etc. Should be able to feed it some documentation and perform tasks with that information.

 

[Affinityconfusesme]

The question is when it will become available?

[kirk23]

ChatGPT 4

 

Affinity Photo is going to support java script soon . Do you think you would be proficient with making scripts for Affinity Photo or it would require a whole new training and unlikely?

 

ChatGPT

The introduction of JavaScript support in Affinity Photo is an interesting development. As a language model trained by OpenAI, I am proficient in JavaScript and have a strong understanding of programming concepts, which would be directly applicable to creating scripts for Affinity Photo, assuming its JavaScript implementation follows standard practices.

Affinity Photo likely has its own specific application programming interface (API), which means that while the core JavaScript language would be the same, the specific functions, methods, and processes to interact with Affinity Photo's features might be unique to that software. Learning these specifics would be necessary to create effective scripts for Affinity Photo. This would involve understanding how the API allows a script to interact with the software's features, such as image manipulation, layer management, and other photographic or graphical editing capabilities.

The process would be similar to learning any new API or software library: understanding the documentation, experimenting with basic examples, and gradually building more complex scripts. Given my existing programming knowledge and ability to learn from written materials, adapting to create scripts for Affinity Photo would be feasible. However, since I cannot execute or test scripts in real-time environments, I would primarily be able to offer guidance, pseudocode, or untested script examples based on the provided documentation and API references.

 

[Dan C]

1 minute ago, tzvi20 said:

The question is when it will become available?

-

On 11/16/2023 at 11:13 AM, Tim France said:

The team has been making good progress. I don't have any updates on a release date but please be assured we are not sitting on our haunches - we want to get this feature out as much as you want it out!

(...)

Please be patient. We know you all want scripting available yesterday, but we're getting there!

I am sure the team will be first to update this thread, once an estimated timeframe is available

[muchitto]

Uuu, didn't know this is something that is actually worked on.

This is one of those things that has been missing from Affinity products. Other products give you ability to extend the functionality and there are so many useful plugins for those that fill in the gaps.

One of the missing features that I would like to script is a perspective grid tool for Affinity photo. So that would entail an UI for selecting which type of perspective it should be, maybe some widgets on the drawing area which you could easily move to determine the vanishing points (and also remove the "movability" of those widgets, aka lock them) and then somehow override the current snapping to use a specific programmatically created rulers.

Either way, very excited for this!

[chessboard]

Me:

Quote

Affinity Photo is going to support java script soon . Tell me why you would not be proficient with making scripts for Affinity Photo and give reasons.

ChatGPT:

 

Quote

 

As an AI developed by OpenAI, I don’t have the ability to directly interact with software like Affinity Photo or any other external software or hardware. Here are the reasons:

1. No Direct Interaction: I can’t directly interact with software or hardware. I can provide information, answer questions, and generate content based on the information I was trained on, but I can’t execute scripts or perform actions in other software or systems.

2. No Real-Time Capabilities: I don’t operate in real-time or have the ability to perceive or react to events as they happen. This means I can’t respond to changes in Affinity Photo or any other software in real-time.

3. No Personal Experience: I don’t have personal experiences or subjective consciousness. This means I don’t have the ability to learn from direct interaction with software or environments, which is often crucial for proficiency in tasks like scripting.

4. Limited Training Data: While I was trained on a diverse range of data and can generate responses on a wide array of topics, my responses are only as good as the data I was trained on. If I wasn’t trained specifically on scripting for Affinity Photo, my ability to provide accurate and helpful information on that topic could be limited.

I hope this clarifies why I wouldn’t be proficient with making scripts for Affinity Photo. However, I can certainly help answer questions or provide information to the best of my abilities based on the data I was trained on! If you have any questions about JavaScript or scripting in general, feel free to ask! 😊

 

You can get any answer out of ChatGPT if you're asking for it. As is says at point 3: "I don’t have personal experiences or subjective consciousness."

[kirk23]

13 minutes ago, chessboard said:

Affinity Photo is going to support java script soon . Tell me why you would not be proficient with making scripts for Affinity Photo and give reasons.

ChatGPT 4

 

 

Affinity Photo is going to support java script soon . Tell me why you would not be proficient with making scripts for Affinity Photo and give reasons.

 

ChatGPT

As an AI developed by OpenAI, I am not capable of directly creating or executing scripts for specific software applications like Affinity Photo. Here are a few reasons why I would not be proficient in making scripts for Affinity Photo, especially considering its upcoming support for JavaScript:

1. Lack of Direct Interaction with Software: I don't have the capability to interact directly with software applications. My functionalities are limited to providing information, advice, and coding examples based on my training data. This means I cannot test or run scripts in Affinity Photo or any other software.

2. No Real-time Feedback and Debugging: Script development often requires real-time feedback and debugging. Since I can't run scripts or interact with the software, I cannot provide real-time debugging or feedback specific to the environment of Affinity Photo.

3. Limited to Pre-2023 Knowledge: My training includes knowledge only up to April 2023. If there have been specific updates or features added to Affinity Photo after this time, I wouldn't be aware of them. This limitation affects my ability to provide current and accurate advice for scripting in the context of the latest version of the software.

4. Generic JavaScript Knowledge: While I can assist with general JavaScript coding advice, Affinity Photo may have specific APIs or frameworks unique to its environment. Without specific knowledge of these, my assistance would be limited to general JavaScript programming practices.

5. No Personalization to User Preferences: Effective script writing often involves understanding the user's specific needs and preferences within the software. As an AI, I lack the ability to understand and incorporate individual user preferences and workflows in a script tailored for Affinity Photo.

However, I can certainly help with general advice on JavaScript, explain programming concepts, and provide examples that might be relevant to a scripting context. This could be useful as a starting point for someone looking to create scripts for Affinity Photo once it supports JavaScript.

 

Chat 4  is already  not that sure it doesn't have its own consciousness  😀 .      It wrote me exporter from Blender  to our custom game format  today.  

[michalmph]

On 1/15/2024 at 1:43 PM, kimtorch said:

Here's a typical workflow for us (we're a newspaper/magazine publishing company). Editorial is written in a (proprietary) app running MySQL (most editorial systems do similar). The writers never open InDesign.

@Jon W@Tim France@kimtorch Guys, this is it. This is probably the most important event in this thread, next to the actual feature announcement.

I understand Kim's irritation. Let's just get over this and work towards a good scripting system that recognizes client's needs.

I come from the graphic design side. I barely dealt with in-line text formatting. The 400 pages catalog took 24-27 minutes when rendered to viewport in InDesign CS6. This process required saving every 15 pages so InDesign would clear an internal memory buffer, otherwise it could crash randomly. I couldn't get it to work headlessly or by generating the IDML, and there was never time to refactor.

To give you a scope of the problem:

I had no idea about the text formatting tags. No one taught me that. I didn't find it in the documentation. I didn't know it existed. I used InDesign's built in formatting tools to set styles (line numbers, paragraphs, etc). I can write an RPA that syncs multi-user input from Photoshop and Illustrator, merge them into an individual asset, and push it to a desired position in an InDesign doc. Or do automatic asset management if you need to develop POS for 30 store locations, each with different dimensional requirements. I could stack hundreds of regexes to process stuff without conflicts. But I didn't know about the text tags up till now. (thanks btw :D).

I'd suggest you guys figure out how to get meaningful feedback that would let you write a feature spec and gather necessary documentation reference. This thread is peanut gallery, and we need an actual need assessment, and features based on the results.