Replacing paragraph break with line feed

That is quite possible. The thing to do then is to replace the spurious paragraph breaks with a space, not a line break.

  1. Click Edit > Find and Replace (Ctrl+H)
  2. Expand Other Options and tick Regular expressions
  3. In the Find field enter \.$ (that is to find all periods at the end of a line as they are more likely to be the actual end of paragraphs)
  4. In the Replace enter a character that is not likely to appear in the text, e.g.
  5. Click Replace All
  6. Repeat from step 3 for paragraphs ending with a
  • question mark, \?$ and replace with a different character (make note), e.g.
  • exclamation mark !$ (you don’t need the backslash as ! isn’t a special character) and replace with a third unusual character
  1. In the Find field enter just the end of paragraph mark $
  2. In the Replace field enter a simple space and click Replace All
  3. Replace the unusual characters with their original punctuation followed by \n, e.g. Find and Replace with .\n then click Replace All. Repeat for the others

An ingenious way of doing it. It works as long as each line ends with a fullstop or other punctuation mark.
But often in poetry or song lyrics there is no punctuation mark at the end of line, or, as in the attached document, a random selection of punctuation marks. But frequently only a paragraph break - pilcrow (u00B6).
The pilcrow is recognised by AltSearch, at least most of the time.
Typically two paragraph breaks are used to deliniate paragraphs. That’s how we did it on a typewriter!

The Stolen Child_nopix.odt (32.9 KB)

Ah well, for verse line breaks are needed. However if you read the fine print of the poetic licence, you are still not allowed blank paragraphs without reason. Stick to the AltSearch method but increase the spacing below paragraph in the relevant style to give a decent gap.

That is interesting. I thought poetic licence gave the freedom to depart from conventional rules of composition and punctuation. My copy of Stolen Child shows that Yeats intended the assortment of punctuation. So it’s all about timing.

Maybe the rules about paragraph breaks are more to do with the typography requirements of publishing houses. But on the printed page a paragraph break and a line break are the same - both white space. So too when you convert to PDF.
Am I right in thinking that the reasons for choosing line or paragraph breaks are more to do with the word processing software.

I have been unable to recreate the perceived problem with AltSearch, so I probably ticked a wrong box.

What I said about typewriters was wrong, CR/LF/LF was used to create what looked like a paragraph break!

Not quite. A line break forces jump to next line without adding any vertical space (other than the defined line spacing for the paragraph). A paragraph break ends the paragraph and the distance defined as Spacing below is inserted below the last line of the paragraph. Note that this is followed by Spacing above of the next paragraph.

This is not an immediate visual difference because it takes into account paragraph configuration. My remark is already biased by “word processing software” workflow.

Yes and no. There is fundamentally a huge difference in semantics.

A paragraph is a basic unit of significance in rhetoric. It presents a homogeneous set of sentences (if several) addressing a single idea or concept (yep, this is theory and I bet many people depart from it). By using a paragraph break, you clearly structure your text into significant and relevant units. And you can make profit of it to format and layout out automatically your document with styles.

On the contrary, a line break does not leave the paragraph. You simply return to the beginning of the next line, remaining in the same paragraph. This has application in poetry or technical books (think of a paragraph showing a term and its definition).

The difference becomes immediately obvious with styles formatting. The very beginning of a paragraph is its “first line” which can be indented separately from the rest of the paragraph. The line following a line break is an “ordinary” line which is indented the same as the rest of the paragraph (it is not a “first line”).

You may argue that the difference results from “word processing software” workflow but I think the most important point is the semantics one.

1 Like

It was not my attention to open a debate of the semantics! Just about practicalities. I did not explain myself well.
Let’s start, as I did, with a typewriter. CRLF was a combination of the two functions using a paddle.
On moving to computers there was a CRLF key, and still is, ↲. That performed the same function on the screen and printer, and still does in practice, if the paragraph style is at default (all the zeros and single line spacing). For the casual PC user it acts as a simple CRLF - on-screen and in-print.
Just as on a typewriter, a double CRLF deliniates a paragraph break.
It is only in the last few years I have discovered paragraph styling, but do not need to use it much in letters to Aunt Martha and such like.
Here is a short booklet I composed before discovering paragraph styling. It took a lot of work to make it presentable. Not a line break to be seen!

This was a convention used with text editors. The first ones used on alphanumeric CRT terminals were rather rudimentary. File format was also rudimentary where compilers and other programs were unable to handle “unlimited” lines. Their buffers were usually dimensioned for punched card data, i.e. 80 columns. Therefore you would use CR to go to next line. This key could be translated as CR, LF or CR+LF in the file. It could even be removed if lines were prefixed with their length (a pair with a fixed binary integer followed by a variable number of characters).

It was then necessary to have a special “sentinel” to distinguish between end of line and end of paragraph. This is were an “empty line” was introduced. It translated effectively in doubling the end-of-line encoding.

When human-relevant text was involved, it add the added benefit of separating paragraphs with one line-spacing blank, contributing to better readability.

The booklet you link to is unfortunately a good example of what should be avoided. It is a sophisticated text+images book upon which your worked hard and reviewed a lot (327 sessions!). Direct formatting, which is another word for using an office suite like a mechanical typewriter, made it extremely difficult and time-consuming to tune the layout. And the layout is very sensitive to editing because you have nearly no automatic context-sensitive directives to respond to flow changes, requiring again manual review to chack the layout has not been messed up.

Unfortunately I don’t understand fully what you need. It is possible to Find Enter $, or Shift+Enter \n. And it is possible to Replace \n as Enter, but there isn’t Shift+Enter for Replace.

So for checked Regular Expressions:
Find \n and Replace \n will replace all Shift+Enters to Enters.
Find $ and Replace \n will do nothing, because it replaces Enters to Enters.

So if you need replace Enters to Shift+Enters then you can try macro:

Sub EnterToShiftEnter
	on local error goto bug
	const cUndo="EnterToShiftEnter" 'string for Undo/Redo
	dim oDoc as object, oDesc as object, oFound as object, i&, o as object, undoMgr as object
	oDoc=ThisComponent
	oDesc=oDoc.createSearchDescriptor
	with oDesc
		.SearchString="$" 'find Enter     ' \n = Shift+Enter
		.SearchRegularExpression=true
	end with
	oFound=oDoc.findAll(oDesc)
	if isNull(oFound) then exit sub
	oDoc.lockControllers 'lock screen (faster)
	undoMgr=oDoc.UndoManager
	undoMgr.enterUndoContext(cUndo) 'open the control of Undo/Redo
	for i=0 to oFound.Count-1 'traverse all found parts
		o=oFound(i) 'selected part
		if o.supportsService("com.sun.star.text.TextRange") then 'found part is TextRange
			rem insert Shift+Enter
			' o.String=chr(10) 'Windows
			o.String=chr(13) 'probably Linux
		end if
	next i
	undoMgr.leaveUndoContext 'close Undo/Redo
bug:
	if oDoc.hasControllersLocked then oDoc.unlockControllers
End Sub

It is for whole document, it is possible to make version only for current selection(s).

I want to replace Enter with Shift+Enter.
Using the AltSearch extension, Search \p and Replace \n does it. But not always! I have no idea why it works sometimes but not others. I need to investigate this further.
.
Thank you for the macro, but it looks somewhat beyond me.
.
The use of Enter (paragraph break) instead of CR/LF is very common, and as ajlittoz points out it fills the document with paragraphs, which makes formatting difficult.

AltSearch can do problems for Current selection only, for Replace all it should be functional.

Run the macro isn’t so difficult, see Help → Chapter 13 Getting Started with Macros and Macro Security.

no, its chr(10) on Linux

Use of chr(13) I remember only from old text files from Mac-Users.

You can work this way on regular SEARCH&REPLACE tool:

  1. Create a line feed ↲ and copy it into the clipboard
  2. Start SEARCH&REPLACE and search all paragraphs $ (regular expressions)
  3. Leave (close) SEARCH&REPLACE - the ¶ are still selected
  4. Insert clipboard (↲) per CONTROL + V and it will replace each ¶

On Linux you may insert the ↲ as follows in the replace box:
CTRL+SHIFT+U 000a (and enter).


EDIT
In no. 3 I added: (close) - for better understanding.

@Grantler Ctrl+V of ↲ to Replace isn’t functional on Win.


Next possibility for F&R in selection is use standard F&R: Find $ and Replace @@@ that is some delimiter that isn’t used in document.
And then use AltSearch: Find @@@, Replace \n and Replace all.

First you have to “3. Leave SEARCH&REPLACE”. Then you insert ↲ in the document.

1 Like

@Grantler OK, functional :+1:

Find $ and Find All → it will select all Enters
then close the F&R dialog and Ctrl+V will replace all selections with pasted symbol

1 Like

Yes, but on my Linux machine Ctrl+Shift u000A returns paragraph break (pilcrow symbol), so does u000D and 21B2. Shift+Enter produces the CRLF symbol ↲. So is the symbol app dependant, or is it platform dependant? I am using a Debian-based Linux.

Quite complicated question.

  • The symbol and function depends on the program/app. Writer will give a pilcrow, but will not store someting like CHR(10) or CRLF as its file format is xml-based.
  • It is also platform-specific (outside writer): crlf was something used on DOS/Windows, while Unix/AmigaOS used only lf. (My own converter just ignored cr for a time until some friend got their first Mac…)
  • What happens depends on the complete chain: keyboard-driver, desktop libraries (like gtk, qt) and the software itself.

Interesting. I am not familiar with XML, though have a passing acquaintance with XTML.
Writer recognises Shift+Enter as CRLF and acts on it, and prints it as a ↲ symbol. In most typefaces.
But is the reverse not true? …ie XML does not recognise the Unicode for ↲ (of which there are more than one).

On LinuxMint 21.3 (and other versions) - Mate display


Ctrl+Shift u000A returns LF symbol ↲

inside text area and/or in REPLACE display (German: Ersetzen: in screeshot).
I wonder whether 000a or a or A does not create ↲ because the hexadecimal a (or 000a) is adequate to decimal (10).