I agree it cannot be scripted to automatically adjust bounding boxes. A script doesn't have access to the 'contents' of a placed image, thus it cannot check if it's just whitespace that got cropped, or an incredibly important atom just got deleted.

A script can be aware of an image being cropped, but (fortunately!) you thought of mentioning that might also be valid. So you are correct: only all cropped images can be flagged, and it's up to the operator to decide whether it's wrong or not.

Hold on while I do some testing. (Insert telephone waiting muzak here.)

…

(di da di da … got something … almost done …)

Okay — finding suspicious items is not the problem. How they should be marked, however, is. This javascript creates a bright red “Warning” color and a “Warning” object style with a thick fat red line, and applies it to the frame. So — do not use this if you are already using another object style on your images! (In that case I'd like to hear from you what other options there are to mark items…)

try { app.activeDocument.objectStyles.add({name:”warning”}); } catch(_) {}

try { app.activeDocument.colors.add ({space:ColorSpace.RGB, colorValue:[255,0,0], name:”Warning”}); } catch (_) {}

warningStyle = app.activeDocument.objectStyles.item(“warning”);

warningStyle.properties = { enableStroke:true, enableFill:false, strokeColor:app.activeDocument.swatches.item(“Warning”), strokeWeight:5, strokeAlignment:StrokeAlignment.INSIDE_ALIGNMENT};

imageList = app.activeDocument.allGraphics;

found = 0;

for (im=0; im<imageList.length; im++)

{

try { if (isImageCropped (imageList[im].geometricBounds, imageList[im].parent.geometricBounds))

{ found++; imageList[im].parent.appliedObjectStyle = warningStyle; } } catch (_) { found++; imageList[im].parent.appliedObjectStyle = warningStyle; } 

}

alert (“Found “+(found?found:”no”)+” suspicious frame”+(found==1?””:”s”));

function isImageCropped (img, frame) {

if (img[0] < frame[0] || img[1] < frame[1] || img[2] > frame[2] || img[3] > frame[3]) return true; return false; } 

Oh, now I understand. No, you should not run my first GREP and then my 2nd. The 2nd try does (or rather, “should do” :-) ) all the work at once.

Perhaps that's why you got a “not found”, where it worked for me — I started with your original data again.

Now that's odd. I never noticed it before, but it appears you are correct: Align to Grid simply does not work in footnotes!

I have always thought the current way of adding Footnotes is a sort of dirty “hack” from the Adobe programmers. There are lots and lots of problems, such as not able to span or ignore columns, numbering is limited to the utmost basics, totally ignores text-wraps, etc. etc. etc. And, with CS5, it seems the programmers at Adobe got themself into even more problems with adding span-over and split-into column paragraphs (see elsewhere on this site for how big these problems are!).

Join our select little club of academic book-makers, and complain: Improve Footnotes Please (use the link in that discussion to send a formal Feature Request to Adobe).

As for your problem … All you can do is set the leading of the footnote text to exactly your baseline grid distance, and make sure the Minimum Space Before and all other dimensions are also in baseline grid distances.

(I'm fairly sure you made your default text frames already an exact multiple of baselines, so working bottom-up should not be a problem.)

Now that's odd. I never noticed it before, but it appears you are correct: Align to Grid simply does not work in footnotes!

I have always thought the current way of adding Footnotes is a sort of dirty “hack” from the Adobe programmers. There are lots and lots of problems, such as not able to span or ignore columns, numbering is limited to the utmost basics, totally ignores text-wraps, etc. etc. etc. And, with CS5, it seems the programmers at Adobe got themself into even more problems with adding span-over and split-into column paragraphs (see elsewhere on this site for how big these problems are!).

Join our select little club of academic book-makers, and complain: Improve Footnotes Please (use the link in that discussion to send a formal Feature Request to Adobe).

As for your problem … All you can do is set the leading of the footnote text to exactly your baseline grid distance, and make sure the Minimum Space Before and all other dimensions are also in baseline grid distances.

(I'm fairly sure you made your default text frames already an exact multiple of baselines, so working bottom-up should not be a problem.) 

You would think that's not possible, would you? So did I :-)

But, amazingly, this seems to work!

Find:

^(?=[^t]{22,})([^,]+,) ?(.*t)

Replace with:

$1n$2

Other than using CS4? No.

It's (somewhat) similar to the situation of CS2 users, when CS4 came out — no direct route. The INX hack that worked for this combo was exactly that: a hack, no guarantees, etc., and it never has had Adobe's seal of approval.

Good news is, there simply must be programmers out there that sit up and see $$ signs.

Other than using CS4? No.

It's (somewhat) similar to the situation of CS2 users, when CS4 came out — no direct route. The INX hack that worked for this combo was exactly that: a hack, no guarantees, etc., and it never has had Adobe's seal of approval.

Good news is, there simply must be programmers out there that sit up and see $$ signs.

From beginning of line to first tab, with 22 characters or more of non-tabs, replacing that tab with a soft return:

Find

^([^t]{22,})t

Replace

$1n

(although you might want to add the tab again in the replacement line, so your next data is aligned the same as non-soft-returned lines).

It won't work perfectly; if there is a single name with lots of i's and no m's, it will broken while not necessary; and if you have a single long name with lots of m's, you'll need to spot those by eye. But I think these stand out of the crowd, and in any case there shouldn't be much of these (if there are too much remaining, decrease the number of minimal characters).