<nl> line breaks versus hard returns in .docx submissions

MrPixel

Just a Regular Guy
Joined
May 12, 2020
Posts
5,543
Plenty of discussion about <nl> breaks to control things like texting within a story... but... all the advice I've seen has been relative to pasting into the submission box. I use way too much italicization in dialog to put <i> and </i> around every instance of voice emphasis.

My problem is I've just written a long texting exchange. It'll read like crap if I let the LitE paragraph spacing monster do its thing. So... does anybody know for sure if <nl> breaks carry through the MSWord .docx filter? I have a bad feeling I'm stuck between a rock and a hard place on this.
 
Plenty of discussion about <nl> breaks to control things like texting within a story... but... all the advice I've seen has been relative to pasting into the submission box. I use way too much italicization in dialog to put <i> and </i> around every instance of voice emphasis.

My problem is I've just written a long texting exchange. It'll read like crap if I let the LitE paragraph spacing monster do its thing. So... does anybody know for sure if <nl> breaks carry through the MSWord .docx filter? I have a bad feeling I'm stuck between a rock and a hard place on this.
You've got to do the html coding every paragraph, because you can't predict the Lit page break (around 3750 words plus or minus). If the close html is missing, and the page breaks, your whole second page can flip to italics.

Solution: lose your love of italics, or don't be lazy (do the code).

- you can designate texting without using italics - EB texted MrPixel.
 
You can put html codes inside of a .docx. I did this (although I think I used <br>) in one of my older stories, and (I think) so did @PennyThompson more recently.
 
I always do a simple "replace" operation on my *.docx files before submitting them.

Using the "Replace" feature, I replace ^p with ^p^p to ensure that there are enough carriage returns to provide the double space between paragraphs.
 
*.RTF gives you control over bold, italics, and paragraphs. However, line spacing between lines in the paragraph would be a bitch. I don't think the indents carry through. If they do, you can make those lines much shorter, and therefore, they'd retain internal parapargh spacing. However, I've never tried it. The first line indent isn't preserved. So, my guess is it'll require HTML.
 
OK. I'll use <br> in an uploaded .docx and let 'er rip, and resubmit with all that entails if it crashes and burns.

To let everyone know where I'm coming from, I made a career in large document prep, managing typesetting departments with 20+ employees. Just trying not to anger the peculiarities of the LitE filter/conversion gods, that's all.
 
I use lots of italics - I try to restrict them to dialogue. Using find and replace to put <i> and then </i> just before submitting really only takes a couple minutes.
 
I use lots of italics - I try to restrict them to dialogue. Using find and replace to put <i> and then </i> just before submitting really only takes a couple minutes.

I am trying my damnedest to not use markup code for as much as I do italics in dialog to convey emphasis with the voices in my head. EB is right, one missed </i> and whole pages can become an italicized blob.

One thing that grated me for years in my document career was markup coding, which was the only way before WYSIWYG editing apps like MSWord. I'll succumb to the <br> as a means of getting around a conversion limitation in text blocks I need to not have broken-up. However, <i>, <b>, <u>, and their terminators are error prone and not conducive to contextual editing.

I had lots of sad experiences trying to apply after-the-fact markup like that to a fully-edited document, and having customers come down on my head because the conversion screwed it up after they'd signed-off on the proof. ...sigh... If you only knew.
 
I am trying my damnedest to not use markup code for as much as I do italics in dialog to convey emphasis with the voices in my head. EB is right, one missed </i> and whole pages can become an italicized blob.

One thing that grated me for years in my document career was markup coding, which was the only way before WYSIWYG editing apps like MSWord. I'll succumb to the <br> as a means of getting around a conversion limitation in text blocks I need to not have broken-up. However, <i>, <b>, <u>, and their terminators are error prone and not conducive to contextual editing.

I had lots of sad experiences trying to apply after-the-fact markup like that to a fully-edited document, and having customers come down on my head because the conversion screwed it up after they'd signed-off on the proof. ...sigh... If you only knew.
Paste your text into an html sandbox. That'll tell you if you've missed a /
 
I'll use <br>
I don't know about in a .docx, but in the plain text input box, <br> works IF you don't also include return/enter keystrokes in the text.

In other words:
If you enter a line<br>like this

you'll get two lines with no space between.

But if you enter<br>
a line like this

you'll get two lines with a space between them.

The <br> has to be in a line with the before-break and the after-break content, and not combined with an actual enter/return linebreak in the text.
 
Textpad, Notepad, Writepad (on legacy Windows O/S), and other text editors was what I used for GameFAQs text submissions (before they became HTML-ized to serve ads without my permission).

Apache OpenOffice uses ODT files, but you can export to text, or wrapped text as needed (not wrapping is a good idea, since LiT seems to wrap your text for you).

Apache OpenOffice Suite is free and open-sauce, FYI
 
I am trying my damnedest to not use markup code for as much as I do italics in dialog to convey emphasis with the voices in my head. EB is right, one missed </i> and whole pages can become an italicized blob.

One thing that grated me for years in my document career was markup coding, which was the only way before WYSIWYG editing apps like MSWord. I'll succumb to the <br> as a means of getting around a conversion limitation in text blocks I need to not have broken-up. However, <i>, <b>, <u>, and their terminators are error prone and not conducive to contextual editing.

I had lots of sad experiences trying to apply after-the-fact markup like that to a fully-edited document, and having customers come down on my head because the conversion screwed it up after they'd signed-off on the proof. ...sigh... If you only knew.
In the 70s I worked an early compugraphic photo typesetter. Every line, carriage return, indent etc had to be hand entered. It was displayed on a narrow crawl screen rather than a monitor. It was awkward. In the mid 90s I needed to learn web development. Took an HTML class. Boom. I had no idea HTTP was based on the mark up protocols of old. Made learning so much faster. Now I get to use those skills again. Strange world.
 
I avoid all that extra work by submitting my shit as files. I have enough sites where I need to manually add italics and line breaks.
 
I am trying my damnedest to not use markup code for as much as I do italics in dialog to convey emphasis with the voices in my head. EB is right, one missed </i> and whole pages can become an italicized blob.

One thing that grated me for years in my document career was markup coding, which was the only way before WYSIWYG editing apps like MSWord. I'll succumb to the <br> as a means of getting around a conversion limitation in text blocks I need to not have broken-up. However, <i>, <b>, <u>, and their terminators are error prone and not conducive to contextual editing.

I had lots of sad experiences trying to apply after-the-fact markup like that to a fully-edited document, and having customers come down on my head because the conversion screwed it up after they'd signed-off on the proof. ...sigh... If you only knew.
Word allows you to find italicized text for search and replace. Once you're in the Replace dialog box go to 'More' and then 'Format > Font' and select italics (or bold, etc.). Leave the 'Find What' field blank. In the 'Replace With' field, enter (without the quotations) "<i>^&</i>", or "<em>^&</em>" if you want to use the version more compatible with screen readers. That will place the tags around any italicized text without changing the formatting.
It sometimes places the closing code after line breaks, if the entire sentence is italicized, but works quite well for speech emphasis or the convention for non-English words and phrases.
 
Back
Top