JavaScripting InDesign

When InDesign CS4 hit the streets, I thought that PopTabFmClip was obsolete. I said so on my web site and basically abandoned it. But it turns out that there's one thing that PopTab did that isn't available in native InDesign. If you want to copy the content of one InDesign table into another (target) table without losing the formatting of the target table, then PopTab is the answer.

So, over the holidays, I decided to rework PopTab to make it available for users of CS4 and later. And I also decided to release it in source form so people are free to read its code if they wish. I'll examine the code here in this blog too to explain the techniques it uses. But the purpose of this blog entry is to announce the availability of PopTabUnleashed -- there's a link at the left of this page you can use to download it.

Here's how the script describes itself in the introductory comment at the head of its code:

This script is provided as-is. Use at your own risk.

The script populates a table, or part of a table, with the text/values on the clipboard without changing the formatting/styling of the target table. The effects of running the script can be undone using Edit/Undo Populate Table.

The content of the clipboard is expected to be a table or part of a table. It can be a selection from Excel or any other application that exports table data, but you hardly need this script to support external applications because since CS4, InDesign provides this functionality: just paste into an existing table.

PopTab comes into its own when you're copying from one InDesign table to another. That is not natively supported because the formatting of the source table is included when you paste.

The selection is required to be in a table. It can be text in a cell, a cell, a range of cells, or a complete table. Selecting text in a cell is regarded as the same as selecting the cell.

As always, just move the script into your Scripts Panel folder so it is visible in your Scripts Panel. To use it, copy appropriate content to the clipboard, make a selection in your target table and then trigger the script to move the clipboard content into the table.

Now that CS4 is with us, it's time to start a list of changes (as opposed to out-and-out new features) that might affect existing scripts. The first one I ran into affected my WrapNudger product.

The TextWrapPreferences property previously known as textWrapType is now called textWrapMode. This change affected the function I use in WrapNudger to determine whether or not the selection has a text wrap. Here's the revised version of the function which shows how I made the script work with either CS3 (InDesign version 5) or CS4 (InDesign version 6):

I was working on a job this morning (actually in CS4, which is released for download today) when I realized that the text frame I was looking at was on the wrong layer. Indeed, all the frames in my story, except for the first few, were on the wrong layer. This must have been the result of my leaving that wrong layer active when I saved the template. I've now fixed the main script that created this situation, but to solve the issue in the document on which I was working, I wrote this quick script:


The script is contained within an anonymous function which starts out by checking that there is a selection. If there is, it confirms that the selection has a parentStory property, and if so, it moves all the text frames that constitute that story (textContainers in CS3 and CS4) on to the same layer as the first frame of the story.

I was called upon the other day to write a script that required that the selection be an orthogonal graphic line. That is, one that was either perfectly horizontal or perfectly vertical.

A graphic line is not necessarily straight. It appears to be any object that has exactly two points, no matter how it was drawn. For example, anything drawn with the Line Tool is a graphic line; any two-point path drawn with the Pen Tool is a graphic line; any ploygon or rectangle that has been reduced to two points by deleting points from its original shape is a graphic line.

This means that finding an "orthogonal" line is not as simple a looking at the coordinates of a graphic line and checking to see if the two x-values or two y-values are the same as each other.

Here's a framework:

//DESCRIPTION: Framework for operating on selected orthogonal lines
(function() {
  if (app.documents.length > 0) {
    for (var j = app.documents[0].selection.length - 1; j >= 0; j--) {
      if (app.documents[0].selection[j] instanceof GraphicLine &&
        isOrthogonal(app.documents[0].selection[j])) {
        processOrthogLine(app.documents[0].selection[j]);  
      }
    }
  }

  function processOrthogLine(theLine) {
    var delta = 0.00001;
    var vert = Math.abs(theLine.paths[0].entirePath[0][1] - theLine.paths[0].entirePath[1][1]) > delta
    alert("The selected line is " + (vert ? "vertical." : "horizontal."));
  }

  function isOrthogonal(gl) {
    // By definition, a graphicLine has just one path with two pathPoints
    var myPath = gl.paths[0];
    var entirePath = myPath.entirePath;
    if (entirePath[0].length > 2 || entirePath[1].length > 2) {
      // one or other of the path points has control handles
      // thus, the line is not straight
      return false;
    }
    var delta = 0.00001;
    if (Math.abs(entirePath[0][0] - entirePath[1][0]) < delta ||
      Math.abs(entirePath[0][1] - entirePath[1][1]) < delta) {
        return true;
    }
    return false;
  }
}())


It is possible that lines drawn with carefully positioned control handles could result in a straight line, but we make the assumption that the lines we're looking for have no control handles.

Most of the time, I pay scant attention to how long a script takes to run because most of them are so quick it hardly matters, but every now and then a simple script comes along that takes serious time to run. I just hit one as I sit here working on a catalog. I'm getting near the end of the job, making corrections and changes (mainly changes).

I realized that I've done so much dickering around to get things to fit on the page in earlier passes that it's time to reset the space before/after of every paragraph. Well, that's easy:

//DESCRIPTION: Restore vertical paragraph style spacing

if (app.documents.length > 0 &&
       app.selection.length == 1 &&
           app.selection[0].hasOwnProperty("baseline")) {
 restoreParagraphSpacing(app.selection[0]);
}

function restoreParagraphSpacing(myText) {
 var myParas = myText.paragraphs;
 for (var j = 0; myParas.length > j; j++) {
   myParas[j].spaceBefore = myParas[j].appliedParagraphStyle.spaceBefore;
   myParas[j].spaceAfter = myParas[j].appliedParagraphStyle.spaceAfter;
 }
}

If I were just running this on the odd page here and there, it wouldn't take too long, but document has 43 pages and the story has 782 paragraphs, so this loop interacts with InDesign 1564 times.

Clearly, we could cut that in half by changing the loop to this:

  for (var j = 0; myParas.length > j; j++) {
   myParas[j].properties = {
     spaceBefore:myParas[j].appliedParagraphStyle.spaceBefore,
     spaceAfter:myParas[j].appliedParagraphStyle.spaceAfter
   }
 }

But this still requires 782 interactions with InDesign. And all of them happen even if the script does nothing because I'm running it for a second time. There's one more thing worth trying:

//DESCRIPTION: Restore vertical paragraph style spacing

if (app.documents.length > 0 &&
       app.selection.length == 1 &&
           app.selection[0].hasOwnProperty("baseline")) {
 restoreParagraphSpacing(app.selection[0]);
}

function restoreParagraphSpacing(myText) {
 var myParas = myText.paragraphs;
 var mySBs = myParas.everyItem().spaceBefore;
 var mySAs = myParas.everyItem().spaceAfter;
 for (var j = 0; myParas.length > j; j++) {
   if (myParas[j].spaceBefore != mySBs[j] || myParas[j].spaceAfter != mySAs[j]) {
     myParas[j].properties = {
       spaceBefore:myParas[j].appliedParagraphStyle.spaceBefore,
       spaceAfter:myParas[j].appliedParagraphStyle.spaceAfter
     }
   }
 }
}

The script still does a lot of interacting, but most of it is reading. It only writes a value into the document if there is a change needed, so right now the script runs very quickly because there are no longer any changes to be made.

Ah well, back to work!