Scripting For Graphics Designers
Contents
Metapattern Codes
The Adobe Creative Suite
The terms ‘graphics design’ covers a wide range of tasks. Sometimes a graphics designer will find that certain seemingly simple tasks require a lot of effort.
The software developers at Adobe who built the Creative Suite realized that it was not possible to create the be-all and end-all toolset for every imaginable task.
Their solution was to leave the the Creative Suite ‘open ended’: they made their tools extensible in a number of ways.
That approach makes it possible to enhance the Adobe Creative Suite ‘in the field’: it can be made to automatically perform tasks that it was not originally designed for.
Graphics Designers
According to popular science, most graphics designers are right-brainers. The right side of their brains is the dominant side. As a result, they are often visually oriented, non verbal, intuitive, creative...
When right-brainers use programs like Adobe® InDesign®, Photoshop®, Illustrator®... they feel right at home. These programs are visually oriented, and they work great when it comes to doing graphics design.
These programs are very powerful to start with. Being extensible makes them even more powerful.
With power comes a price, though. Despite the fact that these tools are highly visually oriented for their main usage, their ‘extensibility’ aspect is not visually oriented at all. Extensibility of the Adobe apps is clearly a left-brainer’s area.
Many graphics designers successfully use, modify or even create scripts. However, they tend to be more of an exception rather than a rule.
Software developers
Then there are software developers. These people create programs in JavaScript, C#, C++, Java, Visual Basic, PHP, Perl, Python,...
Stereotypically, these people are often left-brainers: the left side of the brain is the dominant side. They are supposed to be more rational, verbally orientated, logical, structured, detail-oriented, rational, mathematical.
They might not know a fill pattern from a character style, or how to use Photoshop or Illustrator, but they feel right at home when it comes to the extensibility side of the Adobe tools.
In an ideal world, when faced with a shortcoming or inefficiency in the Adobe tools, a graphics designer would read the relevant documentation, and then extend the tool to do what is needed. Simple, right?
In practice, the technical documentation becomes incomprehensible word salad to a visually oriented person. The above scenario will only rarely, if ever, occur.
The solution to this dilemma is to find a way to combine the effort of two or more people. The idea is to combine the strengths of the two personality types.
The aim of this wiki is to set out a number of guidelines. These guidelines form a common ground between the left-brain and right-brain worlds. Through them, left-brainers can efficiently communicate ideas and meaning that otherwise would go unnoticed.
By following these guidelines, software developers can make the scripts they create more flexible and easier to use for graphics designers.
By knowing about these guidelines, graphics designers can use scripts, and confidently modify existing scripts to make them fit their needs.
But what about plug-ins and extensions?
This part of the wiki will only cover one of the possible approaches to extensibility: scripting with ExtendScript.
The reason why? Pokeability. Let me explain.
If a script a pokeable, it can easily be modified (poked) even by a person with little or no knowledge of the scripting language used.
When a proper pokeable script is opened in a text editor, it is self-explanatory, the areas that are open for tweaking are obvious, and tweaking can be done easily without fear of breaking the script.
ExtendScripts can be built and modified without need for additional tools: all that is needed is provided with the Creative Suite.
Things like plug-ins, extensions, C++, ActionScript, CS Extension Builder... are not covered in this wiki. These things are not very pokeable. They are much more ‘software-developer’-oriented, and go way beyond what most graphics designers would be comfortable with. They also often rely on specialized tools for building and testing.
ExtendScripts are always somewhat pokeable by nature, but by paying attention to it, pokeability can be improved. This wiki is about how to make scripts originating from a left-brained person more pokeable by other people, even if they are not a software developer.
Metapatterns
To address pokeability, this wiki contains a list of metapatterns. Metapatterns are remedies and approaches for specific issues surrounding scripting and programming in general.
In most programming literature, these are commonly referred to as ‘patterns’, but I’m referrring to them as metapatterns, for a number of reasons:
- I managed to register the domain name metapattern.info to house the online metapattern info
- The word ‘pattern’ is an overloaded word with other meanings.
As a software developer, you can choose to follow one or more of these metapatterns when you create scripts.
Of course, these metapatterns are merely suggestions. You can make up your own mind how rigorously or how loosely you want to apply any of them, if at all.
As a graphics designer, when you find a script that almost does what you want, but not quite, you can look out for these patterns. If the original creator of the script followed any of these patterns, you’ll be able to adjust the script to some extent, hopefully right up to the point where it does what you need.
Metapattern Codes
Optionally, the software developer can go one step further, and provide metapattern codes with the script.
Each of the metapatterns in this book has an optional alphanumerical code. The idea is that the software developer can list these codes near the beginning of the script.
Later on, anybody wanting to use the script can very quickly find out what to expect simply by consulting the codes. Example codes: READABLE, ALPHABETIZE, VERSIONED...
For example, a script could have the following information near the start:
// This script adheres to the following metapatterns: // // http://metapattern.info/READABLE Readable Script // http://metapattern.info/ALPHABETIZE Alphabetize functions // http://metapattern.info/REGULAR_TABS Uses spaces instead of tabs // http://metapattern.info/LOGS Has optional error logging code
If you notice a metapattern code that you are unfamiliar with, and you want to know more about it, you can go to the URL shown.
After just a brief glance on the metapattern codes, you gain a lot of knowledge about how the script is structured. That helps you to go about configuring the script for your own purposes, or making changes to the script.
A lot of the metapattern codes are quite irrelevant to the end-user or consumer of the script, and it’s up to the script developer to decide wether to list them or not.
For example, a metapattern code like LONG_INDEX is something you want to keep in mind while developing a script, but it’s not too relevant for the script’s consumer.
You still might want to list the metapattern code if you anticipate that someone else will take your script as a starting point for a future new script. Having the metapattern code explicitly listed will help them build a new script in the same ‘spirit’.
More info on the metapattern codes can be found in the ‘Metapattern Codes’ discussion.
