Check this out: https://creativepro.com/numbering-paragraphs-side.php

It’s probably not a clean solution for you, but it might help.

Sure!

If you have a basic understanding of HTML, then this will be easy. If not, it might take time to wrap your head around it, but bear with me.

Any text that you want to display as code you have to enclose it in ‹code› tags.

Example: Let’s say you want to take the following statement: “I am 23 years old”, and ‘codify’ the number ’23’ so it is displayed as code. So immediately before the ’23’ you have to type in an Opening Code Tag (‹code›) and immediately after the ’23’ you have to type in a Closing Code Tag (‹/code›). As you probably noticed, the difference between the opening tag and the closing tag is the forward slash (/) immediately before the tag name.

So what you basically did is enclosed the number ’23’ in (‹code›) tags.
So it will look like this: I am ‹code›23‹/code› years old. But when you submit the post, these tags or omitted from the actual text in your post, and instead you see the predefined code formatting on all the text that you enclosed in the ‹code› tags. So it will look like this by the rest of the world: I am 23 years old.

I hope I was clear enough, if not feel free to ask me.

So I’m afraid it’s just a bug. We need Peter Kahrel here.

@David: But why can the positive lookahead handle the Standard Carriage Return (~b)?

Interesting.

But it’s not the special characters starting with a tilde (~) that’s the problem. I tried using just the Standard Carriage Return special character (~b) in a positive lookahead and lookbehind respectively and they both worked fine.

I’m afraid it’s because the page break is in the previous text frame and InDesign doesn’t regard it as being technically ‘before’ the text. But again, this is only in a positive lookbehind so I’m not sure what causes this.

I agree. Sometimes I rack my brain to solve someone’s issue and I don’t get any response. Not positive nor negative. But in all fairness, usually posters to acknowledge the advice given.

I can’t answer your general question, but the reason why the placed PSD looked ‘ok-ish’ is becuase in InDesign all vector graphics are treated as raster when coming from a Photoshop file. To maintain the vector outlines you have to export first as a PDF from Photoshop, and then import this PDF in InDesign.

I believe it happens because you set it up to be all caps through the Character panel options or character style options. While that does give you all caps, be aware that they are not ‘real’ all caps. To prove that, just turn off all caps and they return to how they were before. So this is just like applying a paragraph rule to a paragraph, which can get lost when exporting to an ebook because the paragraph rule is merely a ‘presentational’ attribute so to speak. The same goes for the ‘fake’ all caps.

The solution to this is to convert it to ‘real’ static undoable all caps. You do that from the Type menu > Change Case > UPPERCASE. This changes it to real static all caps. If you have to do a lot of them this can get exhausting. And unfortunately, as far as I know, you can’t do that through Find/Change (unless, of course, you type in the actual replacement in all caps. But for variable chapter names this can be exhausting).

I think the best way to do it is like this:

Define a new shortcut for the Change Case to Uppercase menu (such as Shift+Ctrl+5). Then fire up the Find/Change dialog box. In the Find What field enter the string that you need, Or just use the Find Format option. Then hit Find Next. When any text gets selected in the document hit the shortcut (such as Shift+Ctrl+5) to change it to all caps. hit Find Next again, and hit the shortcut again. Do this over and over until all instances have been changed.