How to Define a Plug-in

Wikipedia defines a plugin as “a set of software components that adds specific capabilities to a larger software application”. Not a bad definition.

Most software applications have very specific ways of adding functionality to the application, and this definition pretty much covers it. In InDesign, things get much more confusing, because it’s probably one of the most extensible commercial software applications in existence!

In the beginning of time (a few years back when InDesign was created), there were “plugins” and “scripts” — two very well defined concepts.

Plugins

Plugins were written in C++ using the same SDK and APIs that InDesign itself was created with. In fact, at least 90% of InDesign itself and almost all its features are implemented as plug-ins. Plug-ins are tightly integrated into the program, very efficient, and can work dynamically in the background. Plug-ins can have user interfaces which look like integral parts of the program.

Scripts

Scripts are implemented in one of the three supported scripting languages: ExtendScript (Adobe’s version of Javascript), Applescript (on Macintosh), or Visual Basic Script (on Windows). Scripts were classically slow, each action showed up separately in the undo list, they must be manually invoked, and they were limited to clunky, static user interfaces.

Although InDesign had incredible scripting support (there’s almost no native functionality that can’t be accessed through scripting — and better), there were many clear use cases where a true plug-in was the clear (and only) choice.

On the other hand, scripts are much quicker and inexpensive to develop, as well as easier to debug. Additionally, a buggy script is much less likely to crash InDesign than a buggy plug-in.

Things Got Muddled

As InDesign matured, the scripting engine became more powerful and capable. Each version of InDesign brought a quicker, more efficient scripting engine. In recent versions, except for the most demanding procedures, you can hardly tell the difference between the performance of a “native” plug-in, and an optimized script. Of course the performance of the script will highly depend on how it was written, but a veteran script writer should know how to write scripts that run efficiently.

On top of that was the introduction of events, and Script UI. Events allowed for scripts to run dynamically in the background and Script UI allowed for user interfaces which reacted dynamically to user input and context.

The division between “plug-ins” and “scripts” became very blurred. The only clear differentiating point remained the language the add-on was written in. Plug-ins are written in C++, while scripts are written in one of the higher level scripting languages.

The only two use cases where “plug-ins” remained the clear winner, is where functionality was needed that didn’t exist at all in InDesign, or very high performance was critical.

Hybrid Plug-ins

These distinctions are further blurred by the fact that an add-on does not need to be 100% “script” or 100% “plug-in”. It’s quite possible to mix C++ code with scripting code to create a seamless product (and quite a few of these products exist!) The starting point of such code can be a “script” or the whole thing can be compiled into a single plug-in. It is entirely invisible to the user whether a specific feature is implemented as a “scripting feature” or as a “plug-in feature”. In fact the implementation can be split up into a custom implementation like was done with APID (which we utilize in our products).

Enter: “Extensions”

In CS5, Adobe introduced a new concept: “Extensions”. Extensions can be written using the CS SDK. They are programmed in Flex and ActionScript, and compiled as swf applications. These extensions are an entirely new class of “add-ons”. They have all the capabilities of AIR applications, and all the functionality of integrated scripts. Script Bay is one example of such an extension. Mini Bridge, CS Review, and Kuler are other examples.

Extensions have many of the UI advantages of plug-ins, and can be contained inside native panels. There are quite a few new events in CS5 which allow even tighter integration into the program. In addition, “extensions” can work across the different programs of the Creative Suite.

Conclusion

The basic fact remains. There’s many ways to extend InDesign, and there is no clear “right” way to do it. Sometimes it makes sense to implement a feature as a plug-in. Other times it makes sense to do it as a script, other times, a hybrid, or custom solution is required.

In many situations, it is even difficult to define whether a specific add-on is a “script” a “plug-in” or something else. That fact is, that to the user, it doesn’t really matter that much what the definition of the product is. The technology used to create add-on functionality is mostly a developing consideration. From a user perspective, it’s just important that it allows the user to do what they need!

If you are purchasing a commercial “add-on” don’t concern yourself too much with the technology used to create it.

If you need a custom solution created, things are a bit different. Make sure that whoever you hire is familiar with all these technologies, or you might end up paying extra money for a product which could be created cheaper using a different technology.

The most obvious improvement is the way settings are set. In previous version of Column Flow, the column settings had to be set by changing the style names. Now column settings can be set using a much more intuitive dialog:

But beyond that, there’s a whole pile of tricks that you can now do with Column Flow that was not possible before. Just to illustrate some of the improvements, we will show the previous configuration dialog followed by the new one:

Old Column Flow Settings

New Column Flow Settings

However to really appreciate what Column Flow can do for you we’re going to discuss the Span Columns feature of CS5 a bit.

When we first learned about the Span Columns feature of CS5, we had some real doubts about updating Column Flow for CS5 compatibility. Span Columns is the feature that people have been asking for years, and we developed Column Flow to fill that need. Now with Span Columns, Column Flow is no longer needed. Or so we thought…

After studying Span Columns however, we came to a very different conclusion. In our opinion, the Span (and Split) Columns feature is perfect for newspaper and advertisement layout. For long-document layout however, we believe it falls short of being the needed solution. Here’s why:

• Span Columns works dynamically. This is great, you say. Right? Well for short articles, yes it is. But for long stories? Not so much. Very long stories can have quite a few column breaks along the way. Even with the incredible job the engineers at Adobe did to optimize the code of breaking the columns, it can be very processor intensive, and editing text at the beginning of a long story can quickly become a very tedious job! Additionally, dynamically created column spanners can be very difficult to adjust. To change the spacing on specific pages would require paragraph-style overrides (if it can be done), which makes the file error prone.

• Span and Split Columns gives very little control over keeps options, and very often keeps are completely ignored to prevent columns from having no text. This can make flowing text correctly extremely difficult!

• Trying to use Span Columns to create a section of text which will always stay together (i.e. keep all paragraphs together) is virtually impossible. InDesign does not have the ability to leave a text column empty. To force a whole section of text to the next page would require manually resizing the text frame — which defeats the whole point of Span/Split Columns.

• There’s no way to ensure that a section of text starts on the baseline grid. You need to set the paragraph style to Align to Grid. This is not a solution which will work for headings which must be aligned to grid only at the top of a column.

• There’s no column-balancing functionality included in Span/Split Columns. If it balances, good. If not? Try to balance it yourself.

• Span Columns only helps within a single story. There’s no way to do cross-story spanning.

• Span Columns does not supply a solution for boxed sections of text.

• Because Span Columns uses one text frame for all the text, transparency settings cannot be applied to headings.

Column Flow addresses all these issues:

• Column Flow does not work dynamically, and we believe that for long documents this apparent disadvantage is really a plus!

• Column Flow gives very precise control over keeps with three different levels of strictness to give you your preferred balance between type-fitting and adherence to keeps rules.

• Column Flow gives an option to keep specific numbers of columns together as a unit, so it will not break across pages.

• Column Flow gives precise control over whether text sections are snapped to the baseline grid. This ensures proper alignment of heading text which is normally not baseline aligned.

• While Column Flow will not balance columns in every situation, Column Flow does performs more column balancing than Span Columns. It can even make pages one line long or short if necessary to balance the columns.

• Column Flow can create spanned headings even across different stories when the Story Tools plugin is used to set up Story Strings.

• Column Flow allows for boxed sections to be created with a border or background.

• Because Column Flow creates a separate text frame for each section, transparency effects can be applied automatically to headings specifically.

Additionally:

• When Column Flow is used in conjunction with AutoFlow Pro, master pages can be automatically applied.

Right now, Column Flow can be downloaded as part of the Layout Tools package here.

Full information on the plug-in may be found in the manual here.

Here are some screen-shots displaying some of the advanced functionality of Column Flow, with and without other In-Tools plug-ins included in the InBook plug-in package:

Illustration of several InBook components working together

Boxed Text Section Created by Column Flow

Hebrew layout

Besides providing CS5 support, our newest update for Formatting Tools includes a new function.

You can now convert all instances of All Caps in your document (or story, selection, etc) to proper small caps.

This brings the formatting functions included in Formatting Tools up to 8 very useful tools!

1. Conditional Paragraph Style Changer: changes paragraph styles based on the beginning contents of the paragraph.
2. Style Between Delimiters: applies character styles to text between specified delimiters without having to break your head with GREP expressions.
3. Create Multi-line Styles: applies paragraph styles to paragraphs with the specified number of lines.
4. Restyle Consecutive Paragraphs: applies a different paragraph style to the first and/or last paragraph of a run of consecutive paragraphs.
5. Apply Next Styles: applies the “next style” settings of the selected paragraph styles in the whole document — enabling you to quickly apply styles to massive amounts of text.
6. Create Hyperlinks from URLs: Intelligently creates proper hyperlinks from URLs in your document.
7. Change Case by Style: allows character case to be changed en-mass based on character or paragraph styles. It also can applys Smart Title Case.
8. Convert All Caps to Small Caps: Converts all caps to small caps and optionally applies a character style.

The newest version can be purchased from the product page and downloaded from here: Macintosh Windows

There’s quite a few new features in many of the InBook/InSefer plugins. We’ll try to get some documentation up over the next few days.

We’ve done only basic testing so far, so these should be considered public beta.

For now here’s direct links to download the updated plugins:

For CS5 compatibility you need the newest version of APID available here:
Macintosh Windows

• InSefer: Macintosh Windows
• InBook: Macintosh Windows

• AutoFlow Pro: Macintosh Windows
• Drop Words: Macintosh Windows
• Formatting Tools: Macintosh Windows
• Layout Tools: Macintosh Windows
• Power Headers: Macintosh Windows
• Proper VJ: Macintosh Windows
• Reflective Objects: Macintosh Windows

The existing version of World Tools should work with CS5 as-is, but we will soon be releasing a new, improved version.

These are both very commonly requested features, and we’re really happy to finally getting them added. This brings the total number of really useful utilities included in Formatting Tools up to seven. (“Conditional Paragraph Style Changer”, “Style Between Delimiters”, “Create One and Two Line Styles”, “Restyle Consecutive Paragraphs”, “Apply Next Styles”, “Create Hyperlinks From URLs”, and “Change Case By Style”.

You can download the new version of Formatting Tools from here for Macintosh and here for Windows

Installation:

Unzip the files, and drag the whole “Formatting Tools” folder to your plug-ins folder. If you don’t have APID installed, make sure to download it from here and install it.

Create Hyperlinks from URLs will automatically create hyperlinks from any text it recognizes as a valid URL. It’s very smart, and will ignore manually inserted line breaks on long URLs as well.

You can select the character style to apply as well as the scope of text to change (Document, Story, or Selection).

Change Case by Style will change all text with the specified style(s) to the selected case.

There are four different options: UPPERCASE, lowercase, Smart Title Case, and Sentence case. Uppercase, lowercase, and sentence case are the same results you would get by changing the case manually. Smart Title Case, is (as the name suggests) very smart! It will automatically convert text to title case based on complex rules!

The rules which the title case uses are as follows:
The first and last words are always capitalized, as well as any word following a period (full stop) or colon. Any compound word separated by a “/”, “.”, dash or m-dash will have the letter immediately following the separator capitalized. Any other word will be capitalized unless it appears in the _title_lowercase.txt file. Any word appearing in the file will be lowercase only if it is not a “starting” word. For example: In the title, “The Last of the Mohicans”, the first word “the” will be capitalized, while the second time “the” appears will not. This is because the first word is the beginning of the sentence. Similarly, in the title, “Lion: The King of the Jungle”, the first word “the” will be capitalized because it follows a colon. The lowercase word file can be edited to include any words you like. All words should be separated by a single space.

Any word appearing in the _title_specialcase.txt file will always be capitalized exactly as it appears in the file, regardless of position. This is useful for words like “InDesign”, “USA”, “UK”, etc., which have capitals in the middle of the word. This file can also be used to force lowercase on specific words and override the default rules. So, let’s assume you would like the word “a” to always be lowercase, even if it is the first word in your header text. You would simply put the word “a” in your special case file, and it will always be lowercase. When a word appears in both files, the special case file supersedes the lowercase one.

The Smart Title Case of Formatting Tools uses the same logic as the Smart Title Case of Power Headers, and you can (and should) use a single set of text files for both plug-ins. If the text files are placed anywhere within the plug-ins folder, they will work. You can also place the files somewhere on your hard disk, and create shortcuts/aliases in the plug-ins folder to the files.

You can select a paragraph style, a character style, or both for options of which text to convert. You can also select what scope of text to convert (Document, Story, or Selection). If neither a character style or paragraph style is selected, all the text in the selected scope will be converted.

This update fixes various bugs, and all users should update.

Please download the update from the downloads page.

Beware that this is an advanced topic and not for the faint of heart! It is a complicated setup, but it does a good job of demonstrating the deeply powerful capabilities of Power Headers.

Here are the problems:

1. The headers must contain the range of both the chapters and the verses which appear in the text. Because there a ranges for both chapers and verse, but the verses are contained in the chapters, the headers can appear in two forms:

The red arrows show the chapter numbers, while the green arrows show the verse numbers. When there is only one chapter on a page, the format is: 1. Chapter number-slash, 2. first verse – hyphen, 3. last verse.

When there are two chapters on the page, the format must be: 1. First Chapter number-slash, 2. first verse, 3. N-dash, 4. Last Chapter Number – slash, 5. last verse. Being that there are a minimum of at least four different variables which might or might not appear on the page, this is a seemingly hopeless situation!

2. To further complicate matters, there are sometimes one, and sometimes two verses per line. When there are two verses per line the verse numbers appear with a dash separating them like this:

If we were to simply use a First and/or Last instance, we would sometimes end up with text that looks like [verse_a]-[verse_b]-[verse_c], so we need a way to pick up the first number if it’s the first instance, but the second number if it’s the last instance.

Solutions:

If not for problem #2, we could automate this with three variables, and even factoring in that problem it would probably be possible with four variables (or three with an additional variable-level GREP Processor), but for simplicity sake, we will use six variables to make each instance a separate variable. Since each variable adds time to the updating, you would normally want to do it with as few variables as possible, but we wanted to keep this how-to as simple as possible.

Step #1: Create six different character styles — one for each variable:

Step #2: Right click on the header frame and give the header frame a label:

Step #3: Create the chapter variables.

The first chapter variable should be a “Current Instance” variable which will display the previously found chapter unless the chapter number is at the start of the new page — in which case it will display the one appearing at the top of the page.

The chapter header adds text after which will act as a separator between the chapter number and the verse number:

The second chapter variable should be a “Last Instance” variable.

The chapter header adds text after which will act as a separator between the chapter number and the verse number, as well as a dash to act as the separator between the first chapter/verse and the second one:

Step #4: Create the four verse variables.

Variable 1

Variable #2

Variable #3

Variable #4

As you can see, we inserted a dash (Hebrew “makaf”) to serve as a separator between variables #1 and #2, and between variables #3 and #4.

Step #5:We now have the basic setup for all our variables. We will insert the variables on the master page, and see what these variables produce:

To insert the variables, we put the text cursor in the header frame and right click:

Repeat the process for each of the headers in their correct order:

Step #6: Update the headers to see what they produce:

Verse Range

Chapter Range

As you see, all the information appears in the header, but it makes no sense in any context. When it’s a verse range, the entire second half of the header should be removed, and when it’s a chapter range, we need to do “surgery” to remove the third and fifth variables.

Step #7: Add conditional text to variable “ChapterB”:

To enable the removal of the last three variables on a page where we will have a “verse range”, we insert a “Conditional Text” of “Remove”. This text will be inserted on any page which does not contain a chapter number (which by definition means it will need a “verse range” as apposed to a “chapter range”.

Step #8: Create the first Global GREP Processor

Global GREP Processors run after all the variables are updated, so we can use them to assess the general state of all the variables as they interact with each other. This Global GREP Processor is actually quite simple. It will remove all text from the word Remove until the end of the header frame text:

Now let’s check that it worked:

Before

After

Great!

Step #9: Create Global GREP Processors for chapter ranges.

To fix up the “chapter range” headers shown above we will need two different Global GREP Porcessors. One will remove the third variable and the other will remove the fifth variable. Once those two variables are removed, our “chapter range” headers will appear as they should:

Remove Third Variable

Remove Fifth Variable

These GREP queries are actually a lot simpler than they appear. The fact that they are search right-to-left text make them much harder to read than they would be if they were in Latin letters.

The first GREP query is as follows:

([\x{05D0}-\x{05EA}]+)?[\x{05D0}-\x{05EA}]+(?= — )

Because of peculiarities of using GREP with right-to-left languages, we used the unicode notation of the GREP string instead of the actual characters. The unicode value of the first letter of the Hebrew alphabet is o5D0 and the last is 05EA. Basically this string searches for any number of Hebrew letters which it saves as a saved group. This is followed by a Hebrew makaf (dash) followed by any number of Hebrew characters with a positive look-ahead for a space, em-dash, space. A rough equivalent in English would be: ([a-z]+)-[a-z]+(?= — )

The GREP which removes the fifth variable is similar: ( — [\x{05D0}-\x{05EA}]+ / )[\x{05D0}-\x{05EA}]+?(?=[\x{05D0}-\x{05EA}])

After creating these two GREP Processors and updating the headers we get what we need for the “chapter ranges”:

Before

After

Step #10: Fix a hole in the logic:

There is one problem with the logic we used to identify “chapter ranges” and “verse ranges”. When a page starts a new chapter, there is in fact only one chapter on the page, so it needs a verse range, but since ther was an instance of a chapter number on the page, the extra chapter variable was not correctly removed:

To fix this problem requires two more GREP Processors. The first one fixes the content, but a second one is required to fix the formatting. The second one is needed due to a peculiarity of InDesign’s GREP functionality: When you use GREP to remove content in text of mixed formatting, the formatting can get messed up under certain circumstances.

The first GREP Processor finds Chapter numbers which repeat themselves:

The GREP query for this is: ([\x{05D0}-\x{05EA}]+)( / [\x{05D0}-\x{05EA}]+) ~_ \1 /

The “\1″ is used to locate the text found in the first group which will find chapter numbers which repeat themselves.

This will result in a header which looks like this (notice the bold letters in the first half of the verse range):

This requires this GREP Processor to fix up the formatting which searches for text strings unique to the verse headers and applies one of the verse header character styles:

We now end up with a correctly formatted “verse range”:

Step #11: Fix Verse Ranges:

The only step left to do is to fix the cases where we more than one verse per line,

and by consequence, a source range in the source text which results in a header like this:

If we were not using the Hebrew makaf to separate the ranges, this would not be a problem, because we could just use “First Word” and “Last Word” variables. The problem is that Hebrew makafs are identified as regular word characters.

To fix this, we need to create variable-specific GREP Processors. The difference between variable specific GREP Processors, and Global GREP Processors is that the variable-specific ones are run on only the text specific to that variable, while the global ones are run on the entire header frame after all the headers are updated.

We will create one for variable VerseA:

and another one for variable VerseB:

Now after updating, the headers are all correct:

There you have it! Simple as pi!

After the release of Power Headers 2.0, a few issues came up which we have fixed in version 2.0.1. Please download the newest version. Here’s the download for the Mac version, and here’s the Windows version.

Don’t forget to download APID version 1.0.47 if you haven’t already done so.

Issues fixed:

• We fixed bug which prevented the use of the context menu to label header frames before a variable was defined.
• We fixed a bug which under certain circumstances caused the “Current Instance” to show the wrong text.
• We fixed a bug where the separator was inserted on pages with one instance when Current and Last or All Instances was selected.
• We changed the default “inclusion option” setting to display headers on pages which do not contain source text.

Problems:

In the manual there are two levels of header styles: Section Headers and Sub-Headers. The Section Headers are shown in green, while the sub-headers are shown in orange.

We wanted both the section header text and sub-header text to show in the headers, but the section headers should only be shown when it is the sub-header of the shown section. Additionally, we wanted a forward slash to be displayed to separate the two, but it should appear black, and not orange or green like the main text.

Here’s how we did it:

1. We set up two variables:

2. The first variable was very straight-forward:

We basically just set up a “First Instance” variable, with everything basically at the default values.

3. The basic setup of the second variable was pretty simple as well:

The main difference between the two variables in the basic settings dialog was that we added “text before” of a space-forward slash-space.

Now, here’s where things get interesting!

4. We needed to make sure the forward slash gets its color changed to black, so we created a GREP Processor:

5. We set the GREP Processor to find forward slashes, and change the character style to “Black”.

Now we need to make sure that the sub-headers will not show if they are not a sub-header of the currently displayed section header text. here’s how we do that:

6. We created a “Resetter Style”:

7. We set the styles of the Resetter to Character Style: Any, and Paragraph Style: Section Header.

8. The options in the Resetter Styles can be a little confusing. There are two separate settings: One setting is for the behavior on pages where source text is found, and the other is for pages which follow a page where source text is found. In the first option, we selected to use instances after the first resetter style. This means that Power Headers will disregard any instances of Sub-Headers which appear before the first instance of Section Header on the current page. So, in a situation such as the one pictured:

the instance of Sub-Headers will be disregarded, and you will get this:

However in situations wher you have a sub-header following a section header, like this one:

You will get a header which looks like this (notice the black forward slash):

The “Reset After Page” option will similarly wipe out any instances of Sub-Header which appeared before the last instance of Section Header from pages following the current page.

We hope that this demonstration is useful to help understand some of the awesome power of Power Headers!

Please read the manual for some more info on the awesome features of Power Headers. Here’s a direct link to download the manual.

Power Headers combines with InDesign’s built in variables to provide a remarkably advanced solution for creating content-reflective headers for all kinds of documents. Power Headers version 2.0 offers close to 30 new features which enable the user to easily create headers of extreme complexity in any kind of document.

With Power Headers 2.0, setting up headers is now remarkably simple, incredibly flexible, and updating headers is foolproof.

Power Headers 2.0 adds the following functionality to InDesign:

• Power Headers provides versatile source options for creating headers.
• Power Headers provides the ability to include text based on various conditions.
• Power Headers provides the ability to create spread headers and column headers in addition to basic page headers.
• Power Headers provides the ability to create headers based on any number of alternate styles.
• Power Headers provides the ability to easily create multi-line and multi-paragraph headers.
• Power Headers provides the ability to alter the content and formatting of your headers using regular expressions (GREP) saved within the variable definitions.
• Power Headers provides the ability to create hierarchical headers.
• Power Headers provides many other advanced features such as Smart Title Case, localized formatting, paragraph numbering, as well as many other features.

Pricing and Availability:
Power Headers licenses can be purchased from the Power Headers product page for the price of $59 (USD) for use with InDesign CS2, CS3, or CS4, on a single Macintosh or Windows workstation. Power Headers is also available as part of the InBook and InSefer plug-in packages. When purchased as part of the InBook or InSefer plug-in package, use is allowed on up to two personal workstations. A 30 day fully functional Demo is available for download. In-Tools is offering a FREE upgrade to all licensed users of Running Headers version 1.0 (the original version of Power Headers). Power Headers is available for both Macintosh and Windows, and works with Adobe InDesign CS2, CS3, and CS4.

More information:

Please see the Power Headers product page for more information.