Bob, change this line

fr = pg.textFrames.add(reportLayer, {geometricBounds: gb, textFramePreferences: {verticalJustification: VerticalJustification.CENTER_ALIGN}});

(12th from the bottom up) to this

fr = pg.textFrames.add(reportLayer, {geometricBounds: gb, textFramePreferences: {verticalJustification: VerticalJustification.CENTER_ALIGN, ignoreWrap:true}});

— I didn't try, but I'm pretty sure that'd do the trick.

I've never used LabelGraphics so I can't recommend something off the top of me head for that.

This is a simple table after all ;) As in: you should see what I (ab)use tables for! Up to block diagrams and even mathematical equations …

It takes some practice to get what you want, but the basics are pretty much what you see in here: rows and columns, lines, fills, and cells, which may be merged horizontally or vertically.

It's a well-known problem (well, for me it is ;) ), but everyone seems to run into it every once in a while. See, for example, this recent Adobe Forum thread: https://forums.adobe.com/thread…..?tstart=30

The problem is not the font itself, but it's in the Document Fonts folder — that's the problem! Install this font into your system, and then rename the Document Fonts folder to something else, so ID won't try to use these fonts.

(Adobe knows all about this issue. There were some rumours one of the CS5 updates fixed things, but I really haven't ever checked up on that. Try updating, nevertheless — you never know.)

The merged cells appear both in the first row and in the next one. It's kinda hard then, for InDesign, to decide what to repeat. Set your repeating rows to the first two, and you'll be fine. (It's also kind of hard to visualize what you'd expected to see, with merged cells to appear at the top of the next page.)

… Hang on. You are talking about vertically merged cells, are you? 'Cause horizontally merged cells never have been a problem for me, header or no header.

“Gay” is definitely something else than what you probably meant: “guy” :) (no offense, though).

It's possible to find each specific kind of white space — the regular space, the tab character, the fixed spaces (there are two of them), the hard return and the manual line break, and even every single kind of “fixed width” space (en, em, thin, hair, punctuation, digit … did I forget one?).

InDesign comes with a standard set of GREP queries, and one of them is “Multiple Space to Single Space”. This looks for each of the 'normal' spaces I list above, and replace them with a single regular space. This does not include regular Paragraph Returns and Forced Line Breaks. Is that what you are after?

BTW. These “font discs” weren't anything like this one: https://www.flickr.com/photos/s…..217486415/ (I used those 8″ disks later — they stored about 288K of data). No, they were quite literally “a disc with a font on it”: https://www.flickr.com/photos/s…..217486482/

It worked like this: the imagesetter (physically!) moved the disc closer to or further away from the photographic paper to make the image smaller and larger. (Of course there were upper and lower limits to the font size, also in a quite physical sense.) Then it rotated the disc to the correct character and flashed once or possible multiple times (we could do that to mimick Poor Man's Bold).

It went like “ricketytickety” for several minutes (typically, about 15 min. per would-be page), then rewind and beep for the operator's (me) attention, either to swop disks and re-do for the next font, or declare the job finished and develop and fixate the paper.

I was already typing a long answer, but let me check this first …

Inside InDesign when using GREP, you have to escape each special character with a backslash to make it non-special. But the backslash is also a special character for Javascript! So to get a single backslash inside a GREP expression (to make the next character special), you have to insert two of them in a Javascript string (because JS itself will replace it with one 'regular' backspace).

In your script, as seen above, it would seem that you only used single backspaces, which is a common pitfall when copying a working GREP expression into a non-working script. But (there is always a “but”) … this forum software eats backslashes for breakfast, and to see a single one you need to insert two in your post!

So … is there one backslash per backslash, or did you have two (and the forum ate one), or …?

A good way to check is to remove the two commands at the very end of your script, which reset the Find/Change box to its default state. When removed, the Find/Change dialog will show the exact settings it used; and you can even press the “Find Next” button to check the Find What is still valid.

.. there is a slight glitch. If I apply a soft return to the paragraph ..

Yep — noticed this before. It seems a soft return is also picked up by “^” as a new line. Well … technically it is a forced new line, of course. The odd thing is that GREP sees it as a new paragraph, whereas InDesign treats all as a single paragraph, and always has done so. Perhaps it's a mere oversight by the programmers when they added GREP.

If I apply a soft return to the paragraph, ie. in order to force a word to the next line ..

Avoid that. Use non-breaking spaces (there is a default shortcut for that) or No Break (no shortcut by default, but since it's so useful I added one to my own KB set).