Little Known Facts About InDesign Plug-Ins - There is More To It Than Meets The Eye

Installing a plug-in for Adobe InDesign is normally fairly straightforward.

• Quit or exit out of InDesign.
• Navigate to the folder that contains the InDesign application file.
• Find the folder called 'Plug-Ins'.
• For neatness, create a subfolder inside 'Plug-Ins' - e.g. 'Third Party Plug-Ins'. Drag the plug-in icons (and possibly any associated files) into that subfolder.
• Relaunch InDesign

That's fairly easy.

But when it comes to upgrading things might become a bit more complex.

In short, you might want to first remove the previous version of the plug-in, then start and immediately exit InDesign, and only then install the updated version.

In other words - perform an 'empty' start/stop of InDesign before installing the updated plug-in.

Whether this is really necessary depends on the plug-in - most plug-ins won't need this. But if you're battling a mysterious problem, this is worth a try.

Here's what might happen.

Each time you launch InDesign it will scan the Plug-Ins folder and its subfolders, looking for any new plug-ins. If it cannot find any new plug-ins, nothing special happens - we have a bog-standard, normal InDesign launch.

But when InDesign does find a new plug-in - a plug-in it has not 'seen' before, things are different, and the launch takes longer than normal.

Most people won't notice it - the difference in launch time is not very large. If you're really observant, you'll also see some extra messages flash by in the InDesign splash screen.

Behind the curtain, InDesign is analyzing the new plug-in and extracting information from it.

For example, information on how the new plug-in can be scripted, and information about the wording on the dialogs and palettes the plug-in can display.

A lot of this extracted information is then stashed away by InDesign for 'later reference' - this to avoid having to re-analyze the same plug-in on each re-start.

So, the next time InDesign launches, it again checks for new plug-ins. If no new stuff can be found, it relies on its information stash (also known as 'cache'), and it can launch faster, because it does not have to spend time analyzing any plug-ins.

This 'trick' is called 'caching' - caches are used in many situations, to avoid needless effort to re-obtain data that has been obtained before.

For example, your web browser does it too - the first time ever you access a particular web page, it will be a tad sluggish, especially when there are a lot of graphics. Navigate to that same page a little bit later, and in most cases it will come up a lot faster.

The browser has cached the page content and instead of accessing the web site far, far away, it is showing you a copy of the page it had cached in its local web file cache. The web page comes straight off your hard disk, which is a lot faster than pulling it through the internet.

So, keep in mind: to improve launch times, InDesign caches a lot of information that is normally stored inside of the plug-in files.

Now suppose you have a plug-in installed. It's working fairly well, but there are some issues.

Some time later the software developer releases an updated version of the plug-in, which should fix the issues. You download the new version, and overwrite the old version with it.

Done? Is it that easy? Not always!

The problem is that InDesign might not scan the updated plug-in: for all it knows, it 'saw' file 'xyz.pln' before, and it still sees 'xyz.pln' - InDesign might feel no urge to re-scan 'xyz.pln'.

As a result, InDesign might be relying on the outdated info from the previous version of the plug-in that it has in its information stash.

And weird things might start to happen - things mysteriously don't work well on some computers, but work fine on others, that kind of stuff.

Morale: it might be a good idea to force InDesign to re-scan the new plug-in. To achieve that, you can use the following procedure:

0) Exit out of InDesign
1) Completely remove the plug-in you're about to upgrade
2) Launch InDesign (without the plug-in installed). It will notice the plug-in is missing, and it will erase any cached data it had extracted from it.
3) Exit out of InDesign
4) Install the updated version of the plug-in
5) Launch InDesign (with the updated plug-in installed). It will see the 'new' plug-in and re-scan it - so the cached data is now up-to-date.

Keep in mind: this info is quite general, and might not apply to your situation. But if all else fails - give it a go!

Cheers,

Kris

Some baffling behavior in InDesign CS3 scripts explained - beware of relative object references

Lesson learned: be careful with references to page items in InDesign ExtendScript CS3 - you might be referring to the wrong object!

The issue described below seems fixed in InDesign ExtendScript CS4 - but if you need to support CS3, you should be aware of it.

Look at this code snippet:

var itemB = app.activeDocument.pageItems.item(1);
alert(itemB.id);
... do some stuff that does not affect itemB ...
alert(itemB.id);

What would you expect to happen? You'd expect to see the same id value displayed in two alerts, right?

itemB refers to a particular page item, and should continue to do so. Turns out that is not the case in InDesign CS3.

Try this:

Create a new document, and create three rectangular frames on the first page.

Create the following script:

var itemA = app.activeDocument.pageItems.item(0);
var itemB = app.activeDocument.pageItems.item(1);
var itemC = app.activeDocument.pageItems.item(2);
alert(itemB.id);
itemA.remove();
alert(itemB.id);

You would expect itemB not to be affected by removing itemA - but it is! Run the script and you'll get two different id values displayed in the dialog.

I don't really know for sure what is going on but I have a theory - it looks like itemB has 'become' itemC.

I suspect that InDesign CS3 does not really keep a 'hard' reference to any particular item in the itemB variable - instead it has what I'd call a 'relative reference'.

In other words, itemB is not fixed - it always remains equivalent to 'app.activeDocument.pageItems.item(1)' - and if the page item list changes 'underneath', then itemB suddenly will refer to another item.

After the remove(), the page item list of the document has changed - the item at index 1 is now a different item. So the variable itemB suddenly refers to a different item.

Can we create hard references that don't suffer from this issue? Turns out we can - so there is a solution.

Change the script to read:

var itemA = app.activeDocument.pageItems.item(0);
var itemB = app.activeDocument.pageItems.item(1);
var itemC = app.activeDocument.pageItems.item(2);
itemB = app.activeDocument.pageItems.itemByID(itemB.id);
alert(itemB.id);
itemA.remove();
alert(itemB.id);

That looks like a do-nothing: replace the reference to itemB with another reference to itemB

But internally, InDesign will now refer to 'the item with id=1234' (assuming itemB had an id equal to 1234). itemB.id uniquely identifies itemB, and it is not affected by items being added or removed from the page item list.

So this updated script works as expected - we see the same id displayed before and after the remove.

We can write a small helper function for this:

function FreezeReference(theItem)
{
// Harbs improved my original attempt by
// appending .getElements()[0] - thanks
// Harbs!
return theItem.parent.pageItems.itemByID(theItem.id).getElements()[0];
}

var itemA = app.activeDocument.pageItems.item(0);
var itemB = FreezeReference(app.activeDocument.pageItems.item(1));
var itemC = app.activeDocument.pageItems.item(2);
itemB = app.activeDocument.pageItems.itemByID(itemB.id);
alert(itemB.id);
itemA.remove();
alert(itemB.id);

This also works as expected.

Uncovering this issue was not as straightforward as it might seem - at first, it looked like I was struggling with a bug in our APIDToolAssistant plug-in: Harbs (www.in-tools.com) who is an advanced user of APIDToolAssistant reported some issues with the 'move into' function provided by APIDToolAssistant.

This particular ExtendScript enhancement allows you to move one page item into another very quickly; much faster than could be achieved with pure scripting - you'd do something like this:


// Some 'magic' numbers - C++ meets ExtendScript
const IID_IACTIVEPAGEITEMSCRIPTUTILITIESEXTENSION = 0x90B6C;
const kOpCode_MoveInto = 10016;

...

function MoveItemIntoItem(newParent,newChild)
{
app.callExtension(
IID_IACTIVEPAGEITEMSCRIPTUTILITIESEXTENSION,
kOpCode_MoveInto,
newParent,
newChild);
}

var itemA = app.activeDocument.pageItems.item(0);
var itemB = app.activeDocument.pageItems.item(1);
var itemC = app.activeDocument.pageItems.item(2);
alert(itemB.id);
MoveItemIntoItem(itemA,itemB);
alert(itemB.id);


app.callExension() 'calls into' the APIDToolAssistant plug-in to perform the move.

He noticed that he got invalid object references after calling this function in CS3.

Turned out APIDToolAssistant was not the culprit - after some digging I finally figured out what was going on.

Hope this is useful!

Cheers,

Kris

VMware Fusion and TimeMachine

Been a while since I blogged; swamped in work.

This quick post to share a solution I found on Mac OS X to make VMware Fusion (or Parallels) and Apple's Time Machine backup work better together.

I use a fair amount of virtual Windows and Linux machines, and these tend to be primarily stored in large virtual hard disk files - 40GB, 60GB,... pretty massive.

Because Time Machine finds and copies any modified file, and the mere act of running the virtual Windows machines caused these large files to be marked as 'modified', I was faced with endless copies of massive virtual hard disk files to my Time Machine hard drive.

Figuratively speaking, a one-byte change in one of those massive Windows virtual hard disk files would cause a 60GB copy operation - which also indirectly forced older backup files to be erased from the Time Machine drive to make room for these behemoths.

Initially, I put all my virtual machines in a single folder, and explicitly excluded that folder from the Time Machine backup - not a good solution, but at least, my backup drive was not swamped with those big files.

But then, a few days ago it dawned on me - I could have my cake and eat it too!

The solution is to use the 'snapshot' feature of VMware (Parallels also has it) - you can make a snapshot of a virtual machine, so you can always 'undo' whatever happened to that virtual machine since the last snapshot.

The way VMware handles this is by 'freezing' the underlying virtual hard disk, and storing any changes made since the snapshot to the frozen hard disk in separate files.

And that's the solution: I first make sure my virtual machine is in a useful, stable state, and then I make a snapshot (I call it 'Base').

That effectively 'locks' the massive many-GB virtual drive - so running VMware does not cause it to be modified any more, and any changes from then on are kept in a bunch of much smaller snapshot files.

Time Machine now makes a copy of my 'frozen' many-GB virtual drive once, and from then on only backs up the changes that are kept in the snapshot files - which results in a much smaller backup set.

After a while, when the snapshot file size grows to many GB in size, I make a new snapshot, and delete the old snapshot. That 'merges' all changes that occurred 'between' the two snapshots into the main virtual drive, and starts with a fresh slate.

After I do that, Time Machine backs up the behemoth once again, and from then again only backs up the changes in the new set of snapshot files.

I now have a good backup of my virtual machines again without having to jump through hoops!

Cheers,

Kris