Check “Replace Selected Item” …

(ID treats a text cursor inside text as “selection”, even though the length of the selection is 0.)

You are always welcome to submit your requests to Adobe, but …

1. More than 7 x 7 thumbnails per page — are you serious? And that's to “discuss the book content with my client” — who's your client? The king of Liliput and Blefescu? What page size can you possibly print this on to have something even remotely readable?

2. Apparently, the colors are just for use in the interface. Still, perhaps there is something in that idea. But your summary thing is far too specific to be of general use. Fortunately, the page label colors are exposed to the Scripting model, so it's quite possible to write a script to do these calculations for you.

If you cannot use a custom underline and you may have paragraphs of multiple lines, then alas: No.

I have the same problem with underlining: if you have an underlined formula such as E = mc², you have to manually tweak it to get it “right” (for some value of “right”).

ID CS5 still has no 'background color' for text. I sure could use it, every now and then. Honestly — it doesn't sound too difficult to add. If I remember correctly, one of the Plugin SDK samples for CS (yes — the one before CS2!) showed how to do it. They just never added this plugin to the distributed set …

It sounds as if your system is malfunctioning, and opening a PDF starts Notepad instead of Acrobat. You can test this by double-clicking a PDF in the Explorer. You can check your file extension associations and possibly repair them, or perhaps it's easier to de-install, then re-install Acrobat.

If double-clicking a PDF does start Acrobat, rather than Notepad, in the Explorer, and it's just this one file that does not work … paint me purple and call me an eggplant. The “automatically open PDF” has ID tell your system “hey! show me this PDF” — it doesn't actually start the program itself.

Eugene, editing text in the Story Editor does change it “live” in my running text, but ID redraws (part of) the screen in the Lowest Possible Quality. Strange — it doesn't do that with the Two windows trick.

Strange behavior, but it must be somehow related to the way the original document was saved.

Perhaps it's something as opaque as the exact text encoding: UTF-8, Unicode, a Unicode marker at the start that should not be there — or the reverse, starting with a Unicode marker while poor ID can't handle that.

Perhaps it's the platform-defined line endings: just a Carriage Return (Windows style), just a Line Feed (Mac/Unix style) (I might have mixed them the wrong way around), or even CR/LF pairs (uhm — very old MSDOS style).

Reason it works when re-saved on your computer (what type?) would be your plain text editor is smart enough, on the one hand, to automatically recognized the original file encoding, and on the other hand, to save it the way your ID likes it.

Actually, no way to tell without using a Hex File Viewer on one of the original files; and even then, no way to make ID read the originals … Not without signalling the problem to Adobe and awaiting an update.

(If so: Good luck trying to convince Adobe's poorly Tech Support it is a problem, as their default answer is “User error”, followed by shrugging off any follow-ups you might try with “Problem was solved per our previous mail”. Yeah, been there & done that!)

Strange behavior, but it must be somehow related to the way the original document was saved.

Perhaps it's something as opaque as the exact text encoding: UTF-8, Unicode, a Unicode marker at the start that should not be there — or the reverse, starting with a Unicode marker while poor ID can't handle that.

Perhaps it's the platform-defined line endings: just a Carriage Return (Windows style), just a Line Feed (Mac/Unix style) (I might have mixed them the wrong way around), or even CR/LF pairs (uhm — very old MSDOS style).

Reason it works when re-saved on your computer (what type?) would be your plain text editor is smart enough, on the one hand, to automatically recognized the original file encoding, and on the other hand, to save it the way your ID likes it.

Actually, no way to tell without using a Hex File Viewer on one of the original files; and even then, no way to make ID read the originals … Not without signalling the problem to Adobe and awaiting an update.

(If so: Good luck trying to convince Adobe's poorly Tech Support it is a problem, as their default answer is “User error”, followed by shrugging off any follow-ups you might try with “Problem was solved per our previous mail”. Yeah, been there & done that!)

David suggested a GREP style, so it gets applied automatically (or perhaps automagically) when and where necessary. The character style would only need the “no break” attribute selected.

If you want to search-and-replace, you can still use a character style (with No Break) so you can find/change it later on, or just set “No Break” in the Change Formatting box.

Don't use the first option if you may already have used character styles for formatting the numbers. This new replace-op will remove the former formatting style.

Don't use the second option if you have a strong dislike of the “Paragraph +”, as it only applies the No Break in the volatile 'local' way.

GREP Styles have neither of these disadvantages, plus (the biggest one of all) they get automatically applied and removed where and when necessary. All in all, if you have CS4 or newer, GREP styles are the best.