No joy there. GREP's “start of line” and “end of line” markers are for paragraphs, not for single lines.

You could make the entire thing a table — one single row to auto-grow, two columns, where the left one has a solid white fill. But I bet you are going to say, “Doesn't work — single cells do not break over pages!”

Not with this version of InDesign … (And I wouldn't hold my breath for the next either.)

The GREP styles are “just” some sort of fancy automated search-and-replace, so theoretically you can use the regular search-and-replace to fill in the character style you need. But it's not possible to do automatically.

Thought #1: ah, that dirty mind of mine! Change the paragraph return to a soft line break … (and don't do that if your text is justified…)

Thought #2: I have no experience at all with line styles. No idea why that would work, but — on the other hand, I've ben surprised before by off-the-wall tips with these.

Not with this version of InDesign … (And I wouldn't hold my breath for the next either.)

The GREP styles are “just” some sort of fancy automated search-and-replace, so theoretically you can use the regular search-and-replace to fill in the character style you need. But it's not possible to do automatically.

Thought #1: ah, that dirty mind of mine! Change the paragraph return to a soft line break … (and don't do that if your text is justified…)

Thought #2: I have no experience at all with line styles. No idea why that would work, but — on the other hand, I've ben surprised before by off-the-wall tips with these.

So let's see how this would work in our world. Say we put in fold marks outside the trim. If they don't touch the inside of the page trim, then they would fall off if we did not indicate slug in the document setup?

Correct.

I just tried it out (usually I work with plain text pages ;-), and contrary to what I believed before, it seems you have to phyisically set the Bleed to more than the Slug — i.e., the Bleed value includes the Slug and does not add to it.

So initially I had set both bleed and slug to “5mm” and was surprised to see only one additional 5 mm edge around my test doc. After setting the Slug to “10mm”, I got the extra space around bleed.

So let's see how this would work in our world. Say we put in fold marks outside the trim. If they don't touch the inside of the page trim, then they would fall off if we did not indicate slug in the document setup?

Correct.

I just tried it out (usually I work with plain text pages ;-), and contrary to what I believed before, it seems you have to phyisically set the Bleed to more than the Slug — i.e., the Bleed value includes the Slug and does not add to it.

So initially I had set both bleed and slug to “5mm” and was surprised to see only one additional 5 mm edge around my test doc. After setting the Slug to “10mm”, I got the extra space around bleed.

“Best”, as in safest, or “best” as in smallest file? That's why there are two options ;-)

These are really a remnant of old Postscript drivers and printers that could not handle raw binary bytes spoon-fed to them. Even then though, it was usually not a problem, and the last decade or so I've been using Binary with no problem at all.

(Background: this sets the output — storage — format for all data streams; not particularly plain text, more stuff like fonts and images. If you choose “ASCII”, the binary contents of these files are written to the output file in hexadecimal format (0123456789ABCDEF …), or a modern equivalent such as ASCII-85. That's to ensure the receiving party — a printer, or perhaps some really backwards mail protocol — will not try to 'handle' binary codes as End of File (Ctrl-Z, dreaded by programmers ever since the Days of DOS) and end-of-line codes (Carriage Returns that get converted to CR/LF pairs, or the other way around).

Binary is just that: the literal binary bytes, Ctrl-Zs, CRs and LFs and everything else you can throw into a binary file.

Nowadays, the receiving end can't ever get confused of what's what; both types of data are clearly and loudly announced in the file before the actual data stream starts.)

“Best”, as in safest, or “best” as in smallest file? That's why there are two options ;-)

These are really a remnant of old Postscript drivers and printers that could not handle raw binary bytes spoon-fed to them. Even then though, it was usually not a problem, and the last decade or so I've been using Binary with no problem at all.

(Background: this sets the output — storage — format for all data streams; not particularly plain text, more stuff like fonts and images. If you choose “ASCII”, the binary contents of these files are written to the output file in hexadecimal format (0123456789ABCDEF …), or a modern equivalent such as ASCII-85. That's to ensure the receiving party — a printer, or perhaps some really backwards mail protocol — will not try to 'handle' binary codes as End of File (Ctrl-Z, dreaded by programmers ever since the Days of DOS) and end-of-line codes (Carriage Returns that get converted to CR/LF pairs, or the other way around).

Binary is just that: the literal binary bytes, Ctrl-Zs, CRs and LFs and everything else you can throw into a binary file. 

Nowadays, the receiving end can't ever get confused of what's what; both types of data are clearly and loudly announced in the file before the actual data stream starts.)

Using Transparency forces the display to use “accurate colors” for your current Document Color space. Since not every color can be converted accurately from RGB to CMYK (InDesign's default color space), ID converts them to the nearest possible value.

You are not printing the document — which does need it to be in CMYK space –, so you can simply change the blend space to RGB. It's in the File menu, I believe.