Scripting

[affi.usr]

I can't understand why the most people think about using one language for scripting in place make this independent?

Solution

1. Create Affinity Controler App

2. Create API to interact with controller

3. Using GET / POST request with your favorite language to control Affinity Suite without bodering about what language is used.

 

1) Affinity Controler App - is local webserver. When someone is calling it's function it is start controlling choosen app.

2. API is local adress with choosen port to make calls fx.

localhost:2019/ad/open/file&name=test.afdesing

localhost:2019/ad/export&format=pdf&preset=print&rasterdpi=300

It is powerful. It need some effort to make inside call in Affinity Suite, not only Publisher, but it is worth. You can share script between platforms in easy way. You can automate workflow using another system too fx. save data from client on Samba server, from Linux call computer with Windows to open and run application to make template filled with photos (fx. Atlas of mushrooms) and after preparation designer will have to work with text.

3. Calling local API for application is simple way to avoid locking possibilities for specific branch of person. I skip ActionScript in Photoshop, because I do not have time to learn it when I need fast work done. I use another software to prepare files as it was simpler and faster when clock ticking...

 

At the end

I suggest using seperate application for calling all apps, because in my vision Affinity Suite can send virtually data between fx. create some part in Photo, add in Designer and create final PDF with Publisher.

[fde101]

5 hours ago, affi.usr said:

is local webserver

Wow...  this opens up all kinds of complexity.  Now you introduce the possible issue of creating port conflicts, the inefficiency of shuttling control information across a simulated network connection, the need to generate a web service call from an interpreted language followed by the need to parse that request from within the app...

 

And gain... almost nothing.  With a well-designed plugin kit, arbitrary scripting languages could be wrapped as plugins and make calls into the app directly without needing any of that overhead.  Yes, this would mean some extra development work for each one, but it would be much more efficient, cleaner, and simpler to deal with.  For that matter, if you really want the overhead of a built-in web server... that could be developed as a plugin too if the plugin development kit is well-designed...

[affi.usr]

 

On 6/9/2019 at 3:49 AM, fde101 said:

this opens up all kinds of complexity

Yes, it is. From other hand it can be simple. Escape using one language by using text file with steps to do:

file.new(type=print, colour=[colour_format=rgb/8, colour_profile=sRGB], include_margins=[left=5, right=5, top=5, bottom=5])

file.export(JPEG, Size=(7015px,4960px))

Passing to app with std in (print to console with something like that:

printf("file.new...")

print('file.new'...)

In app is loaded as plugin so app knows that will be receive data. Your script / program only have to be runable. You can use any style of language. Primary syntax is simple - write in style of description of GUI 

file - menu file

new - submenu in file => file.new

(options)

[tabs / sections]

= value

or something similar. For low level using you have to write code in style you will be clicking something in GUI. It can be possible add shortcuts from keyboards in something like that:

sendkey(Ctrl+J)

On this low level API you can create any abstraction for your favorite language. You can pass option directly of make custom Objects style with class Image and passing data to it if you wish. You can add plugins which get data from network if you wish in the same style too. So you can make universal text based API which you can code if you only know bunch of rules how translate actions in menu without getting into abstraction like construction of Affinity Team classed for Affinity Designer.

API is implementation of universal caller. You can call inside Affinity app operation by text file, by generating comands in your script or passing to script from network. At the end my final thought is make universal structure for interaction with data without deep into and stuck with one language. With adding special command to create gui inside Affinity apps you have universal tool.

User job is only choose his favorite editor (like Notepad) or coding language if he needs something with more interaction (loops, conditionals). 

Community can build libraries to automate commons task, setting defualt options, share and that is all.

Why not one language?

Now trending is Python, but after ten years it can be lua, new version of C etc. So why not avoid stucking with lang which can be abandon in the future, because of technical change? If you know Python you can write code in it, but if you good in vbs you can do the same in it.

[fde101]

29 minutes ago, affi.usr said:

User job is only choose his favorite editor (like Notepad) or coding language if he needs something with more interaction (loops, conditionals). 

This approach would likely mean needing to trigger the scripts from outside of Publisher.  The benefits over using the OS scripting support would be minimal, since you can also trigger the OS scripting capabilities from within other languages by numerous means, and it would eliminate the overhead of running a web server inside of a page layout tool - really doesn't belong there.

 

On the other hand, if the Affinity plugin API is thorough, it might be possible to extend much more functionality to a scripting language to add even things like export filters and the like by using a plugin interface to hook a script into the plugin API.  This would offer some possibilities that would be very unlikely in the type of configuration you are suggesting.

[Peter Werner]

Running a web server for an API (or a web browser or Flash Player for dialog boxes) is exactly the same type of bloat that we all criticize Adobe for. They, too, are running at least one local node.js web server in the background even if none of their applications are active. You may have noticed it because it occasionally hangs, crashes or blocks system shutdown.

Scripting isn't that performant in the first place, and running single command through a full-blown set of script interpreter, API in that scripting language wrapping and parsing the HTTP communication, HTTP server, system TCP/IP stack and what not is such a colossal waste of resources, not to mention it opens up the entire system to security vulnerabilities.

If you really have a compelling case why you absolutely must automate Affinity applications over an HTTP API, you could easily implement the relevant parts of such an API yourself, either via a native C++ plugin, or even easier, with a Python script and Flask (a combination which by the way could probably replace InDesign Server with a desktop version of Publisher for quite a few use cases).

1 hour ago, affi.usr said:

Now trending is Python, but after ten years it can be lua, new version of C etc. So why not avoid stucking with lang which can be abandon in the future, because of technical change? If you know Python you can write code in it, but if you good in vbs you can do the same in it.

This is by no means about what is trending, but what makes the moste sense in terms of providing an efficient, robust, powerful, extensible and future-proof scripting workflow. Besides, Python has been a staple of application scripting in the VFX industry (among others) for decades, and for a reason. This is by no means just a "trend" and there is no indication whatsoever that it will go away any time soon. As an established solution, there are a lot of companies invested in it so continued development is pretty much guaranteed for the foreseeable future.

Lua is indeed great for smaller quick and easy scripts and easy to integrate in a C++ program, but not that suitable for more complex solutions (hello, Adobe Lightroom Classic mess) and its object-oriented language features are lacking compared to Python. C is not even a scripting language and does not scale too well, which is why it has been replaced by C++ as the language of choice for larger native software projects decades ago. It is also not true that the complexity of implementing one solution in different languages is always the same – it is true for very, very simple code, but as solutions become more complex, some languages, and their ecosystems, are significantly more powerful than others. As someone who has worked with both Python and VBScript I can tell you that there are some things that would be a nightmare to write in VBScript and a five minute exercise in Python.

We don't need a hundred haphazardly integrated scripting solutions so everyone can avoid spending 30 minutes to learn a few basic new syntax rules, but one great scripting solution that is well thought-out, seamlessly integrated, simple and easy for basic tasks but powerful enough for the most complex requirements that arise, and interfaces well with the outside world (AppleScript/COM, network/HTTP APIs, third party libraries and applications, native code etc.).

[rui_mac]

I arrived late to this thread but the subject of adding scripting abilities to the Affinity suite has started a long time ago.
I can't wait to be able to make my own scripts inside any of the Affinity apps.

And I think python is, definetelly, the best way to go.
Multiplatform, lots of libraries available, easy and fun to code, very efficient,etc.

Having coded in BASIC, assembler, C, C++, javascript and python, I think python is the best one for scripting.

[angelhdz12]

On 6/8/2019 at 4:20 PM, affi.usr said:

I can't understand why the most people think about using one language for scripting in place make this independent?

Solution

1. Create Affinity Controler App

2. Create API to interact with controller

3. Using GET / POST request with your favorite language to control Affinity Suite without bodering about what language is used.

 

1) Affinity Controler App - is local webserver. When someone is calling it's function it is start controlling choosen app.

2. API is local adress with choosen port to make calls fx.

localhost:2019/ad/open/file&name=test.afdesing

localhost:2019/ad/export&format=pdf&preset=print&rasterdpi=300

It is powerful. It need some effort to make inside call in Affinity Suite, not only Publisher, but it is worth. You can share script between platforms in easy way. You can automate workflow using another system too fx. save data from client on Samba server, from Linux call computer with Windows to open and run application to make template filled with photos (fx. Atlas of mushrooms) and after preparation designer will have to work with text.

3. Calling local API for application is simple way to avoid locking possibilities for specific branch of person. I skip ActionScript in Photoshop, because I do not have time to learn it when I need fast work done. I use another software to prepare files as it was simpler and faster when clock ticking...

 

At the end

I suggest using seperate application for calling all apps, because in my vision Affinity Suite can send virtually data between fx. create some part in Photo, add in Designer and create final PDF with Publisher.

This! OMG! Never thought about this! This way, developers can control Affinity programs in any language flavor they want. I would use Python and Typescript. <3

[affi.usr]

 

2 hours ago, angelhdz12 said:

This way, developers can control Affinity programs in any language flavor they want

This is key what I think about. Create scripting with inbuild macro recording it is not new thing. I prefer go ahead competitors and ask about:

1. How make scripting in Publisher and Affinity Suite more problem solving oriented in place learning new path tool? 
2. How make it OS idendepented and open for intergration for data providers like servers, e-mails etc. for creating worflow oriented on fitting Affinity Suite with data?
3. How make it user friendly that after 5 minutes reading introduction I can create solution for my typical problems (like automate boring stuff in the easiest way possible) without digging in docs?
4. How use aproach less code more possibilities?

22 hours ago, Peter Werner said:

This is by no means about what is trending, but what makes the moste sense in terms of providing an efficient, robust, powerful, extensible and future-proof scripting workflow. Besides, Python has been a staple of application scripting in the VFX industry (among others) for decades, and for a reason.

After few year experience with coding in Python I can say the best with it is the simplicity. You can code with less code lines and it is minimal with extra ; or {. Dear Peter you should think about possibilities that after Python in the future it can be easier and more powerful language. I like using it, but when I start coding with Turbo Pascal when I found C++ I think that it is the best tool on the Earth. VBA, JS, Assembler 8086, PHP are some of langs which I try before I stay with Python for longer time. For some scenarios Python libraries can make faster results than coding in my earlier favorite C++.

9 hours ago, rui_mac said:

Having coded in BASIC, assembler, C, C++, javascript and python, I think python is the best one for scripting

I have the same opinion. Afifnity Team use inside Java Script for testing Affinity Suite so they can prefer it as they have some experience with it. Python it the most universal tool now from web developing to data analysis.

Future

Today a lot of people think about graphics like only creating retushing, vectors or DTP publishing. Now it is changing. Data analysis blured line between interactive programming and showing visualistation in real time for information. I see few niches to go inside and take advantage with creating something really new.

Scenario

Client need poster with financial statistics for company. Using Python Pandas we can create analysis of data and with bokeh library create visualisation. Now using OpenCV we can recognise elements in PDF for vectorise it without designer interaction in Affinity Designer. After that we need text classification for typical client document so we can use C++ library for Nvidia Tesla to improve sentimental analysis of text and get thinal thought about how people feel about products. Using C++ is dicted by specific of Nvidia card and better for performance reason. With PHP we can grap form SQL database financial data to get view how many cost new product and put this to Affinity Designer to create graph. Using in other place JS (jquery) we can grap from menager data about marketing strategy because he can add photographies of last events to summary template in Publisher. With machine learning photography are selected for quality like sharpness and avoiding two previous emploees with awful public opinion what support company create with R.

...

For start it's seems strange and too more complicated why not using e-mail or FTP to sharing data, but now automation is in progress. Creating workflow where computer in real time can add data from few other source to graphic project is very interesting start. As designer you can use infrastructure created by someone else and concentrate how creativly improve visual communication and make your work better. If retoucher work with similar projects like party events photography using templates for drafting can make work easier. Creating base for integrating other tools for working inside Affinity Suite it is not only choose language but make it easier for anyone. If programmer with 20 years old experience in C++ can create solution in place learning for X project python it is big deal.

 

Summary

When 70 years old man with basic computer experience will can create script / working solution for his problem because has basic understaing how Affinity Publisher or other apps from Affinity Suite works it will be pass test for simplicity script tool what I suggest here.

[angelhdz12]

19 minutes ago, affi.usr said:

 

This is key what I think about. Create scripting with inbuild macro recording it is not new thing. I prefer go ahead competitors and ask about:

1. How make scripting in Publisher and Affinity Suite more problem solving oriented in place learning new path tool? 
2. How make it OS idendepented and open for intergration for data providers like servers, e-mails etc. for creating worflow oriented on fitting Affinity Suite with data?
3. How make it user friendly that after 5 minutes reading introduction I can create solution for my typical problems (like automate boring stuff in the easiest way possible) without digging in docs?
4. How use aproach less code more possibilities?

After few year experience with coding in Python I can say the best with it is the simplicity. You can code with less code lines and it is minimal with extra ; or {. Dear Peter you should think about possibilities that after Python in the future it can be easier and more powerful language. I like using it, but when I start coding with Turbo Pascal when I found C++ I think that it is the best tool on the Earth. VBA, JS, Assembler 8086, PHP are some of langs which I try before I stay with Python for longer time. For some scenarios Python libraries can make faster results than coding in my earlier favorite C++.

I have the same opinion. Afifnity Team use inside Java Script for testing Affinity Suite so they can prefer it as they have some experience with it. Python it the most universal tool now from web developing to data analysis.

Future

Today a lot of people think about graphics like only creating retushing, vectors or DTP publishing. Now it is changing. Data analysis blured line between interactive programming and showing visualistation in real time for information. I see few niches to go inside and take advantage with creating something really new.

Scenario

Client need poster with financial statistics for company. Using Python Pandas we can create analysis of data and with bokeh library create visualisation. Now using OpenCV we can recognise elements in PDF for vectorise it without designer interaction in Affinity Designer. After that we need text classification for typical client document so we can use C++ library for Nvidia Tesla to improve sentimental analysis of text and get thinal thought about how people feel about products. Using C++ is dicted by specific of Nvidia card and better for performance reason. With PHP we can grap form SQL database financial data to get view how many cost new product and put this to Affinity Designer to create graph. Using in other place JS (jquery) we can grap from menager data about marketing strategy because he can add photographies of last events to summary template in Publisher. With machine learning photography are selected for quality like sharpness and avoiding two previous emploees with awful public opinion what support company create with R.

...

For start it's seems strange and too more complicated why not using e-mail or FTP to sharing data, but now automation is in progress. Creating workflow where computer in real time can add data from few other source to graphic project is very interesting start. As designer you can use infrastructure created by someone else and concentrate how creativly improve visual communication and make your work better. If retoucher work with similar projects like party events photography using templates for drafting can make work easier. Creating base for integrating other tools for working inside Affinity Suite it is not only choose language but make it easier for anyone. If programmer with 20 years old experience in C++ can create solution in place learning for X project python it is big deal.

I Agree on Python, because its power, and syntax simplicity. But if they go the HTTP requests route and let developers choose their own language, I would choose Typescript or C# because I love static typed languages.

Let's say:



Something like that. Beautiful!

[fde101]

15 hours ago, angelhdz12 said:

Beautiful!

I think that looks ugly.

 

If you like languages with strong data typing, nothing beats Ada, and it is much more readable as well:

procedure Select_Shapes(doc : in Document) is

    ab  : Artboard := Current_Artboard(doc);
    lay : Layer;

begin
    for i in 1..Layer_Count(ab) loop
        lay := Layer(ab, i);

        if Is_Shape(lay) then
            Select(lay);
        end if;
    end loop;
end Select_Shapes;

 

[angelhdz12]

58 minutes ago, fde101 said:

I think that looks ugly.

 

If you like languages with strong data typing, nothing beats Ada, and it is much more readable as well:

procedure Select_Shapes(doc : in Document) is

    ab  : Artboard := Current_Artboard(doc);
    lay : Layer;

begin
    for i in 1..Layer_Count(ab) loop
        lay := Layer(ab, i);

        if Is_Shape(lay) then
            Select(lay);
        end if;
    end loop;
end Select_Shapes;

 

Why it looks ugly? Because it's not your language of preference? Because it has brackets to open and close blocks instead of tabs?

I've seen a few people preaching about ancient languages in here, trying to make it relevant. One preaching about Haskell, others about Lua or Cobol, don't know, and so on.

So your opinions are biased, favoring personal preference and not a generalized overview on users needs and simplicity, accessibility, maintainability, compatibility, etc.

Top programming language of 2019

• Python
• Javascript
• Typescript
• C++
• C#
• PHP
• Java

 

[fde101]

15 minutes ago, angelhdz12 said:

Why it looks ugly? Because it's not your language of preference? Because it has brackets to open and close blocks instead of tabs?

For one thing, you didn't indent the code at all.

Yes, the braces to open and close blocks is a bit cumbersome as it is not particularly clear, particularly without good indentation.

There are also some issues with the fact that an "Artboard" is being treated as an array of objects when an artboard obviously consists of more than that (it has a size for example).

You also seem to assume that every "object" on an artboard is magically a shape.

 

Ada is one of the best compiled languages out there, period.  The syntax has a lot to do with that, but it is really its data type model that caused me to bring it up here.  If you want code that works by design, none of the languages you listed can even come close...  I've never seen any other language defined that can match Ada for its tendency to result in correct code.  Even Swift, which claims to be designed for that purpose, doesn't really compare.

 

Ada is not, however, a scripting language, and not a language I would be quick to recommend as an embedded scripting language for an application.  Neither are several of the others on your list.

 

I'm one to ignore popular things (languages or whatever) and look for something superior.  I'd rather choose something because of its technical merit than its popularity.

[affi.usr]

4 hours ago, fde101 said:

I'm one to ignore popular things (languages or whatever) and look for something superior.  I'd rather choose something because of its technical merit than its popularity.

You forgot about learning curve. The most people use the easiest to follow tool for job. It is why InDesign was better that QuarkXPress and the sam is for programming. Who remember now Delphi?

Python like syntax is easier for me to follow:

doc = AffinityAPI.document()
current_artboard = doc.artboard[0]

for i in current_artboard:
    shape = current_artboard[i]
    doc.set_selection(shape)

I will be going with these that people are more interested in making working things than in learning  new inside script languages. I think more abstracted API prepared for any language is good shot. Why not use ADA 95 if you like? For very low level Affinity Team have to use compiled language, but for high API I will be use abstract to only creating settings what do. It is how website are created. You do not think how HTML is implemented but how use it. It's way to use Affinity in easy way for every case.

[v_kyr]

And what does the above example calls do in case there isn't any artboard? First you have to test if you indeed got a "doc" reference back and then also if there are any "artboards" at all (return values are not nil/null), before trying to do something with those. Thus an API also needs to have functions like "bool hasDocuments()" and "bool doc.hasArtboards()", "int doc.artboardCount()"... etc.

All in all here a too lax API mapping would be in usage pretty error prone. Further I believe, that only few people will be able to adapt their preferred prog language in a more or less usable manner to a general API alone then, since most people here are plain users and don't have much experiences with programming or certain programming languages. Thus as said before, more important is to map a rich reusable set of the internal functions into that API language then and also offer good integration hooks into the UI for an API.

[affi.usr]

17 hours ago, v_kyr said:

First you have to test if you indeed got a "doc"

Yes, definetelly is it a problem. I will be resolve it by inside Affinity Host Controller. If artboard is missing it simply not running function associated with artboard. The simplest for developer is run with error and stop executing with message like "Artboard have to be first created". Other stuffs it is user responsibility. If inside language use conditionals (if-else, for loops etc) it is really doesn't matter if you are developer or not. You will be always has learning curve. Only solution is make abstract syntax with option use them directly with fx. text files with step by step and possibility wrap generate in other language. 

V_kyr, it is your solution mixed with mine. I stand on possition make possible use any language with internal API. It is not problem create file to internal interpretaror and use another language to create wrapper about it by simple use code fx. inside C++ / Python classes to generate text file output. Typical user will in my opinion prefered run macro recording and only edditing some parts. It is the simplest solution. For generating effect it is the simplest way to achive goals without coding.

[fde101]

12 minutes ago, affi.usr said:

Only solution is make abstract syntax with option use them directly with fx. text files with step by step and possibility wrap generate in other language. 

This doesn't mean what you think it does.

The "language" in the proposed solution consists of the service calls that Affinity publishes over this internal web server.

Whoever wanted to script this in some "arbitrary" language would in effect need to learn two languages instead of one: the language of the service calls, and the language they are using to try to access them.

It would add the burden of managing the client-side connectivity to the service on top of the need to deal with the interfacing.

While it would theoretically be possible to create client modules/units/packages/libraries for an assortment of languages, how would this be any better for the typical user than using an equivalent module/unit/package/library that wrote out AppleScript code and submitted it using the OSA tools or vbscript code and submitted it using the Windoze equivalent, while at the same time opening up the system-level scripting libraries to make this work coherently with other applications in the way that the OS authors intended?

 

This "solution" is adding some illusion of familiarity for a small subset of users at the cost of massively increased complexity and overhead, not to mention worse performance, for the majority of users.  This doesn't actually solve anything.

[v_kyr]

Basically for a more variable usage the software itself only needs a good external accessable C/C++ API for interface connectivity. Everything else (services, some language access etc.) can be mapped and build on that one then. If it would be half way good documented then even by third parties. - For casual users an internal API with a hooked on powerful scripting language implementation would be probably enough.

Also, in either case, the whole thing lives and dies with the quality of an implementation and related useful documentation.

[heavyboots]

I'm super late to the discussion, but I'm pretty happy if it turns out to be Javascript. Everyone knows it, it's easy to interact with on the Mac since Applescript supports it at a system level, etc. Plus, personally, Python has always given me the heeby-jeebies. Anything where the *indenting* controls which items are in the loop… well, it's just not for me. I cut my teeth on Pascal and I much prefer the somewhat more verbose style of code languages with braces produce.

I have thousands of lines of Applescript InDesign code, but now Apple supports JS natively, I suspect it's not long for the world and will soon go the way of Dashboard.

[evtonic3]

This is such a lengthy topic that I can’t help but wonder what are people’s goals here to have scripts added to the app? I mean what can one do to better the app that the devs aren’t already doing? Just curious.

[fde101]

30 minutes ago, evtonic3 said:

I can’t help but wonder what are people’s goals here to have scripts added to the app?

No matter what features the devs add to the app, there will always be people with more specialized use cases who can leverage scripting to automate tasks that would otherwise be repetitive.

There are largely two categories of use cases with different sets of requirements:

• One is a need to automate tasks within the application itself.  If someone is repeatedly doing something basic that may well be specific to their line of work which would not be a good fit for a general feature of the program, a scripting language integrated into the application can often create specialized functionality that could help to avoid repeatedly doing the same task for those users.  This is the use case that most of the people who are arguing Python vs. Lua vs. Javascript etc. are likely thinking of.  This feature would benefit more of the individual layout artists and designers compared to the other bullet point below, as it would enable them to more efficiently tailor the software for their individual needs and workflows.
• The other major use case is the need to integrate multiple applications by tying together programs that each do some specialized task.  This one cannot be handled by a programming language that is integrated into the application but rather by having the application support the OS-provided scripting languages so that multiple applications can be tied together by a script to automate tasks that no one of the programs could do by itself.  This is the use case that the AppleScript users are mostly thinking of (or OS-provided JavaScript/VBScript - OSA/WSH/etc.) as it enables control of multiple applications from within the scripting language, a case that could not be readily handled by an embedded Python, Lua, etc. interpreter.  This is a critical capability in some production environments and would benefit some individual artists/designers as well.

In both cases, it boils down to providing support for more specialized needs without otherwise bloating the functionality of the app itself trying to handle every little corner case that every possible user might come up with, and both sets of requirements will be important to different users.

 

11 hours ago, heavyboots said:

I have thousands of lines of Applescript InDesign code, but now Apple supports JS natively, I suspect it's not long for the world and will soon go the way of Dashboard.

Dashboard is still there.  If AppleScript does fall into disuse, it is more likely to lose out to Swift than to JavaScript, at least in the Apple world.  (Yes, Swift can be used as a scripting language...)

[affi.usr]

On 6/21/2019 at 1:33 PM, evtonic3 said:

This is such a lengthy topic that I can’t help but wonder what are people’s goals here to have scripts added to the app? I mean what can one do to better the app that the devs aren’t already doing? Just curious.

1. Automate boring stuff - fx. preparation for specific type of project. When you create the same type layout when you have to change the same details you can use generator for it fx. calendar on current year.
2. Add functionalities / change internal workflow - fx. you want add custom icon execution loading last project based on it's dates fx. you create for the same company baner each month and after few month you mix few baner in one as quartal poster. Adding this funcionality add benefits preparing for job in less time.
3. Extend exist workflow - you can add support for unsupported file format by auto convert source file supported by Affinity Suite.
4. Semicreative - fx. add cloud generator with colors matched from dominant colors on the picture
5. New filters
6. ...

You do not have to be a professional programmer. Sometimes you need only clever thought how make stuff working better and googling. In some languages like Python using libraries can make hard problems simplified to few lines of code. It is why important is create working system easy to follow for everyone.

[RM f/g]

On 6/21/2019 at 1:33 PM, evtonic3 said:

This is such a lengthy topic that I can’t help but wonder what are people’s goals here to have scripts added to the app? I mean what can one do to better the app that the devs aren’t already doing? Just curious.

Scripts can really speed up the process.

Working with large bodies of text, the first thing I do after importing text (in InDesign) is run a script which deals with a lot of sloppy typing. It searches and replaces for example double spaces, double tabs, tab + space, carriage return + tab, tab + carriage return, carriage return + space, space + carriage return, space + ")", "(" + space.

About 40–50 find/replace actions done in a seconds. Imagine having to perform those one by one yourself.

[fde101]

16 hours ago, RM f/g said:

 Scripts can really speed up the process.

Working with large bodies of text, the first thing I do after importing text (in InDesign) is run a script which deals with a lot of sloppy typing. It searches and replaces for example double spaces, double tabs, tab + space, carriage return + tab, tab + carriage return, carriage return + space, space + carriage return, space + ")", "(" + space.

About 40–50 find/replace actions done in a seconds. Imagine having to perform those one by one yourself.

This is also a great example of why these features should be in user-provided scripts rather than integrated into the software.  The specific corrections are highly specific to the subject material.  Running those corrections on a document which includes programming language code could in some cases change the meaning of the code, rendering the document incorrect.  Particularly with snake-language (err, Python) as the spacing in front of the code is part of the syntax.

Similarly, if the document uses tab stops to format table data, removing "double tabs" could cause data to show up in the wrong column of the table.

This may work extremely well for some kinds of input, but it is not generically safe.  If it is known that the incoming documents are safe to run these corrections on, then allowing the user to write such a script is a great solution for this.

[garrettm30]

18 hours ago, RM f/g said:

About 40–50 find/replace actions done in a seconds. Imagine having to perform those one by one yourself.

Yeah, that's what I am doing now. I am hoping for the ability to save find/replace searches, but if some sort of scripting were created, I would probably take great advantage in the same way you suggested, and my need for saved searches would be greatly reduced.

[Old Bruce]

I would use these sort of scripts in something outside of Publisher, then import the text.