Saturday, September 03, 2005

 

Researching Snippets vs. Libraries

I'm about to find myself embroiled in a catalog project. This is the second time around for me for this particular publication which involves presentation of a large number of complex objects that are similar to each other and yet subtly different. The last time around, I used InDesign 2, AppleScript, and a support library of object templates.

For this time around, I'll be using InDesign CS2, JavaScript and (I think) a folder of snippets (the choice is to once again use a library). Libraries have the advantage that you can directly place library assets inline to a story (although you do have to using live insertion points to do so).

OK, clearly, if I'm to use snippets, I need a script to place a snippet inline. So, let's take a look at that issue.
//DESCRIPTION: Test Script to place a snippet inline

var myFile = File.openDialog("Find a snippet:");
if (myFile == null) { exit() }
The first thing the script does is have the user find a snippet in the filing system. The File.openDialog() call returns null if the user cancels.

For now, we'll just assume that the active document has a currently active insertion point, so
var myDoc = app.activeDocument;
var myIP = app.selection[0];
So, now we can use myDoc to refer to the active document and myIP to refer to the current insertion point.

It appears that to place the snippet, I must use:
myDoc.place(myFile)
but this returns nothing, so how do I know what I just placed? It's time to actually try the script to see what happens; perhaps the placed item will be selected.

Nope. It's just sitting there on the page. So somehow I have to deduce what it is. Some experimentation suggests that after placing a snippet, myDoc.pageItems[-1] is a reference to it. While researching this, I noticed that myDoc.place() is new in CS2. In CS, you had to place on to a page. You can still do that in CS2, where according to the scripting reference:
myObj.myDoc.pages[0].place(myFile)
should give a reference to the placed object. Turns out that this is true for everything except a snippet, so there is no advantage to using that syntax.

OK, enough nosing around. Let's get on with the task of importing a snippet and making it inline. We have the insertionPoint in myIP and we know how to get a reference to the placed snippet, so it should be as easy as:
var myObj = myDoc.pageItems[0];
myObj.move(LocationOptions.after,myIP);
Oh misery me. That doesn't work. I knew that! You can't move a pageItem inline directly. You have to copy and paste. But I don't want to do that; I don't like using the clipboard for this kind of thing. It happens that there is an alternative approach using a library, but if I have to use a library in order to import my snippets, what's the point of using snippets when I can simply put the templates in the library and be done with it.

So, today's script doesn't work, but still, it has helped me make an important decision. I've also taken the chance to communicate this problem with snippets to appropriate people at Adobe.

Comments:
Dear Dave,
I read your post on Snippets vs. Libraries. I have a question to ask you. But first I need to give you some background info.
I just took over a company's graphic department where I manage a load of very technical data sheets, some consisting of 100+ pages (small in comparison to others but very technical). In the past the issues they ran into was maintaining a validated "correct" copy of each data sheet. What would happen is when a “known” error free data sheet needed to be updated, the previous graphics person/s would use a very similar data sheet and without realizing the subtle differences between the two would contaminate the correct file. This went on and on until almost all data sheets were incorrect. Some slightly and some pretty grossly. I am looking to find a way by using snippets to manage this issue. I was thinking about going the route of snippet because of the XML feature of it. I would export snippets and save them into a version tracking software where I would be allowed to make changes and in turn monitor and track the changes that were made. The need for version tracking is because of the nature of the technical data. One cannot really tell if a current data sheet is correct without first viewing the changes that were implemented in the first place. InDesign creates an XML doc and when opened up in a text editor the doc is loaded with tons of stuff making it difficult to edit. Is Adobe aware of this and if so is there an easier method to edit and make changes to the XML while tracking the changes and modifications made to the snippet available?

Sincerely,
Gordon
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?