Indexmatic works only on actual text. Although technically, it's possible to have it also look at every image's XML Metadata, or notes inside a private label, or a number of other ways … it may be easier to just enter your text into a frame of its own on top of (or nearby) the images, and make this text invisible by setting its color to [None].

Indexmatic works only on actual text. Although technically, it's possible to have it also look at every image's XML Metadata, or notes inside a private label, or a number of other ways … it may be easier to just enter your text into a frame of its own on top of (or nearby) the images, and make this text invisible by setting its color to [None].

Hi Steve, and welcome to the wonderful world of scripting!

If you want to change “rows 2 to x“, normally you would have to 'manually' loop over these rows, and to do that, you'd have to manually loop over all tables, and to do that, well, you'd have to manually loop over all stories … Using the fast everyItem() function avoids all this work, but — it can only work on every item, not something like 'from row 2 to the end' (hence the name :-D ).

So you have no choice, other than using the much slower loops? Sure you have! You can set all rows of all tables to your 'remaining' height value, and then change only the 1st and 2nd rows' height.

Add this line before your first one, and you should be done:

app.activeDocument.stories.everyItem().tables.everyItem().rows.everyItem().height = “20mm”;

(replacing the 20 mm with the height you need).

Hi Steve, and welcome to the wonderful world of scripting!

If you want to change “rows 2 to x“, normally you would have to 'manually' loop over these rows, and to do that, you'd have to manually loop over all tables, and to do that, well, you'd have to manually loop over all stories … Using the fast everyItem() function avoids all this work, but — it can only work on every item, not something like 'from row 2 to the end' (hence the name :-D ).

So you have no choice, other than using the much slower loops? Sure you have! You can set all rows of all tables to your 'remaining' height value, and then change only the 1st and 2nd rows' height.

Add this line before your first one, and you should be done:

app.activeDocument.stories.everyItem().tables.everyItem().rows.everyItem().height  = “20mm”;

(replacing the 20 mm with the height you need).

Why 4?

Erm. Why not? :-) James' example shows 6 digits, and if it's always exactly that, safest way would be to use d{6} — if only to prevent reacting to a line that happens to end with a single digit.

My GREP does work on James' example … (on copying you might accidentally have picked up a stray space or hard return).

I would advise not to use the any-character wildcard in .{26,30}, though. If there is a stray tab after the last item in his list, it will pick up the tab in between and the text thereafter as well. Use to [^t]{26,30} prevent this, as it will always limit the style to any text between two tabs.

Neither \w+ nor [\u]+ include the spaces between those words …

Throwing in an would even be worse :-D It would add space, but also tabs and even the hard return at the end.

(FYI: I think \w generally equals to [\d\u] — it includes digits but excludes the hyphen, which, for example, makes it worthless when looking for proper names.)

Edit Note: if posting replaces double backslashes with single ones, Edit Post ought to do the same in reverse! As it is, posting replaces two backslashes with one, edit posting replaces one backslash with zero. I dare not try what happens when you try to edit again. I don't think Einstein predicted what would happen with negative numbers of backslashes.

Our scholarly gent seems to have overseen something, though.

(?<=[^\d{1,100}]).{20,25}(?=)

A variable number of elements in the look behind does not work. It simply doesn't do anything (perhaps the GREP returns an error message, but Adobe — infinite wisdom and all — decided to not pass those through to the user, leaving him to wonder why nothing happens).

Asides, everything inside the square brackets is put inside an OR-group, and the caron at the start inverts it to a NOT-group. I'm guessing it only appears to be working: it scans for a single character not (decimal or { or 1 or comma or 0 or }).

The most reliable check you can get, for a minimum number of preceding digits n (here 4), would be

(?<=\d{4})[^]{25,30}(?=)