Skip to main content
Participating Frequently
December 10, 2009
Question

what's the difference between a plug-in and a script?

  • December 10, 2009
  • 5 replies
  • 12388 views

Hi everyone, can anybody explain this to me quick? I'm not programming-savvy, but I'd like to know.

thanks!!

This topic has been closed for replies.

5 replies

Participating Frequently
April 24, 2018

Is the capacity to show a preview of changes made in the user interface live and difference between scrip and plugins? or they both can show a live preview? If a script can do it can someone please instruct me how to do it. Thanks, Jean-Lou

Participating Frequently
December 11, 2009

thanks to everyone who replied. It was very interesting and helpful to read your answers, and now I feel like I could give an answer to that question which I just KNOW I will be asked. The Forums come through again!!

Jongware
Community Expert
Community Expert
December 11, 2009

Let's not forget a major plus point of scripts: they are, or can be made to be, version independent. Older scripts that don't wo

rk

anymore (--please ignore random hard returns, I'm not going to fix jive-ups!) can be made to come alive

by putting them into a "Version xx Scripts" folder -- it works for all but the utmost 'dirty scripted hacks'.

Plugins, on the other hand, are highly version-dependent. And as Adobe publishes a new SDK, with new system and environment demands, per each new version of InDesign, the programmer has to acquire that new programming environs, work through the documentation to find what changed where, and update the source code of his own plugin just to make it work for a newer InDesign. Woe unto them who write plugins for a living if they don't promptly update their plugins to work with the latest version (after all, hey, the client paid for his old one -- and it does not work anymore in the new version so why don't you fix it for free as it is clearly broken -- etc.).

Steven__
Inspiring
December 10, 2009

As someone who has recently taught myself InDesign SDK programming, here's my 2 cents,

1. Scripts can be written by hobbyists, Plug-ins must be written by Programmers with previous knowledge of Object Oriented C++

2. Scripting basics are easily acquired

    • JavaScript, AppleScript, Visual Basic have plenty of free for dummies resources
    • This forum has many knowledgeable people happy to help out anyone without charge (I can't figure how they make a living)
    • Useful scripts can be just a matter of lines
    • Script are very readable, making each one a tutorial.
    • Olev Kavern's documentation and script comments is the best I've ever seen.(many years ago, when I started scripting it got me started)

SDK basics are not easily acquired

    • Programming Guide and Solutions Guide not for dummies
    • SDK Forum only has a few really knowledgeable contributers (Dirk being the most prominent)
    • C++ code spans many files making it hard to get help, since there are many unknowns.
    • Visual Studio or XCode, SDK, Debug Version of InDesign about 3 GB of files is a commitment that takes some time just to get right.
    • Adobe Support is very expensive
    • It's hard for beginners to understand every line of the generated code, making it hard to modify.

3. Many parts of the SDK are not documented at all, requiring a lot of sniffing to figure how to make it work. Dirk has some plug-in he created just to sniff some info out of InDesign.

All in all, its hard, its time consuming, however its very rewarding.

Steven

Harbs.
Legend
December 11, 2009

Steven.. wrote:

I can't figure how they make a living)

Who says we do?

Harbs

Robert at ID-Tasker
Legend
December 10, 2009

Hi everyone, can anybody explain this to me quick? I'm not programming-savvy, but I'd like to know.

Script can speed up your manual work - i.e. repetitive tasks.

Plugin can add new features/funcionality into InDesign - i.e. CellStyles in old versions of InDesign.

After using script - there are no negative "footprints" and there is no way to check if document was edited/prepared using script(s).

When you use plugin in document - you could have problems when you try to open this document on computer without this plugin.

And don't get confused by "plugins" created from scripts It's still script but packed into plugin-shell

robin

www.adobescripts.co.uk

Inspiring
December 10, 2009

Robin, don't dare to touch the weak spot of Harbs! He insists on the label "plugin" for both ;-)

I'll pick a few features of my plugins where scripts can not compete:

Plugins can be seamlessly integrated in many more places of the UI. I've done fields and icons in the control strip to display warnings or actual values of the selection, a tool for arbitrary work in the layout, the tool is tied to the info palette to show its own information while active. I frequently reuse the native widgets in my palettes (e.g. the tree view) with full drag and drop support if required. Preferences dialog? You get the idea.

Plugins can store their values in private places, in preferences, on every object and also in non-objects such as text, rather than abuse few existing features - the color of the unused paragraph rule above comes to mind. I'd instead create my own attributes and add another sub-dialog to the style options for completeness sake.

When Robin mentions the negative "footprint", that's an issue of badly designed plugins. If the programmer does not take care, you will indeed be confronted with "missing plugin" dialogs. Be assured there are options to suppress the dialog and recover gracefully when the document was modified without the plugin.

A major advantage of plugins is the ability to tap into an enormous range of internal notifications. Follow the selection the same way as the original widgets. You do not need to wait for the user to click a button, you just update your display while the mouse is still dragging the image, or you modify the behaviour of mouse-down on your added page item handles. You can step in between before things are changed that you need to change differently - snap to your own kind of grid.

Another advantage: speed. C++ is just faster, and can itself work on smallest details where scripts have to work their way thru levels of abstraction from the runtime engine thru the scripting object model, further thru high and low level encapsulation to finally flip the single bit in the document's database. Only a small part of internal functionality is really exposed to scripts - we just talked the other day that unused swatches are available but how about styles?

Many places within InDesign are designed to be replaced or extended. Run your own composer if you think you can do better than Adobe, or have to emulate Wor(d)se. Add your own drag and drop flavor. Want an own measurement unit? Implement hyphenation services for the Klingon language. Add support for unknown image formats. Very important are the assignment hooks for interchange with InCopy, as a developer of an editorial system you redirect their function towards your database.

As Loic mentions, plugins can be closed against changes. Nothing but the required development effort prevents them to open their functionality to other plugins, or to scripts. A well known example for extensible plugins is actually Rorohiko's plugin used as the basis for many advanced scripts such as Harb's. I also have plugins that invoke scripts on events such as drag and drop from outside, or that expose their new text attributes as scripting properties.

Dirk

Harbs.
Legend
December 10, 2009

Dirk Becker  wrote:

Robin, don't dare to touch the weak spot of Harbs! He insists on the label "plugin" for both ;-)

Well, I do refer to them a "Scripted Plugins", but you have to dig pretty hard to see that...

(hint: check the read-me files)

How 'bout "extensions"?

The fact of the matter is that these distinctions are being blurred. What would you call PatchPanel extensions?

An awful lot of "real" plugins have a whole bunch of ExtendScript under the hood as well. Are those plugins, or "Scripted Plugins"?

The fact of the matter is that very few of these distinctions are important to the end user, but to the developer the distictions really are very siginificant.

Harbs

Steven__
Inspiring
December 10, 2009

see http://rorohiko.blogspot.com/2007/07/getting-started-with-adobe-indesign-sdk.html

Participating Frequently
December 10, 2009

Thanks for the link, Steven. But wow, that guy's podcast is totally over my head.

Please forgive my ignorance. I don't usually involve myself with "behind the scenes" info--I'm only an artist!!-- but tomorrow morning I am teaching some people about "extra cool things InDesign can do" and I just *know* this question will come up.

I guess I just wanted to know: from a user standpoint, what is the difference? why do we sometimes extend functionality with things called "scripts" and other times with "plug-ins"? what makes them different from one another--for example, why do I run a "script" to get cool corner effects and a "plug-in"  to do crop marks?

thanks again

Peter Kahrel
Community Expert
Community Expert
December 10, 2009

Scripts and plug-ins aim to do the same thing, namely, to provide something that Indesign can't do (yet). There the similarities stop. Everything you can script you can also do as a plug-in, but not the other way around: there are many complex plug-ins that do things which you wouldn't be able to script.

For simple things, you'd write a script because they're easier to develop and test. But being able to script doesn't mean you can write plug-ins: I for one can write some scripts but I don't know how to write plug-ins.

Another factor is that for various reasons many people don't like plug-ins, whereas they don't mind running scripts.

These seem to me to be the main differences.

Peter