How can I add hard return (i.e. newline) to conditional text field in LO Writer MailMerge

I dislike the inbuilt method for skipping a blank field (i.e. using “hidden paragraph”) as it is not logical to me and, worse, an additional logical construct beyond just putting in a conditional field.

I would like to be able to add merge field(s) with the “conditional text” fields function, but there seems to be no way to print the field AND a hard return (i.e. newline) .

I have tried adding \r\n or \n (in which chase the field doesn’t print at all).

I have tried adding a “hidden” control character by pressing Alt+013 (which closes the dialog as if I had actually pressed enter).

I have tried a bunch of other ideas and nothing seems to work.

Is there a way to add ASCII control characters to dialog boxes like this? If not, where is the best place to request this.

If fully fledged, this functionality would almost immediately erase power-user concerns over Writer’s maligned mail-merge issues. I would be thrilled to write a detailed tutorial but for this one issue.

Thanks in advance for any insights.

No; what you are asking for is itself not logical, and tries to merge different entities into single item not suited to serve both.

The merge field if just that: a field that holds merge data. It is not expected to also hold data not taken from the data source (i.e., a paragraph break) which you are asking for.

On the other side, doing that at paragraph side is perfectly logical: you put some variable content into a paragraph, and control if the content is not empty, to also control the paragraph visibility.

You are trying to simplify one use case: when a paragraph only contains a single field, without, say, a label. But that is just one case; and your proposal is unusable in any other scenario. If you use labels, or put two or more fields in the paragraph, then you’ll need to control the paragraph visibility on a higher level (where the existing solution is flexible enough, allowing you to hide whole paragraph with labels, or use complex conditions using multiple fields).

And if your proposal is implemented, you will have yet another option in addition to already bloated set of doubling features. This leads to user frustration when one cannot undo a setting (like hiding paragraph), just because one didn’t look into yet another corner that controls that.

I am not sure about which “power-user concerns over Writer’s maligned mail-merge skipping fields issues” you are talking about (a reference would be useful), and also why your suggestion would “erase” them (I doubt that - for one, because a malicious creator doesn’t need to adhere to your new proposal if it is implemented; but also if your proposal itself doesn’t hold a potential for malicious usage, still needs to be shown).

Doing it “at the paragraph side” is “logical” if you think suppressing a whole bunch of empty paragraphs makes sense. Keep in mind, this makes the control logic step “backward” within the merge process for each and every record.

Making a field (and line control character) display conditionally only when not blank allows a report (in this case labels) to be built (in most cases entirely) “forwards” for lack of a better way of describing it.

Where does one best ask for feature enhancements?

I’m editing my original question, because it is not just the “skipping fields issues” with which people have an issue. There are posts all over the web showing people to have problems with merge and labels. One really good example is how label margins can not be edited after the fact and that one has to create a new label document to “edit” margins of labels.

Reference? Here’s just one of a great many I have found.
David points out how illogical suppressing blanks is and even submitted a bug report. Rather than accept his input and try to slog through this issue which so many seem to have, the bug report has been marked “RESOLVED INVALID” – really?

What? A report about “Documentation needs improvement” that states “I’d be happy to contribute something nicer than my angry blog post”, and after that OP gets silent both in terms of concrete enhancement proposition, and “extending the wiki page if you like”. Why isn’t it invalid? You are just trying to make your point no matter how relevant your arguments are.

It’s entirely possible David never received (automatic) notification his submission received any response. That’s happened to many of us. And his blog post does clearly show how the documentation was (perhaps still is) insufficient.
Anyway, many LO cheerleaders seem deaf to the various problems many people have with merge. Worse, some (like you) actually push back when all I am pointing out is that some aspects seem illogical and asking “Where does one best ask for feature enhancements?”

Well: at least I’d expect someone coming here to take a look at the “How to use this Ask site” guidelines linked at the Ask main page. Ind if one would look there, one would definitely see the “Feature Requests” section. Which points to the same bug tracker that you pointed to when mentioned the David’s bug. That’s why I didn’t reply to a question above, thinking you’ve figured that already.

Next: “push back”? Hmm… Well, when I see someone making proposals that don’t make sense to me, I could start throwing unacceptable things like “what a bullshit are you speaking about?!” and such. And that could rightfully be taken as “pushing back”. But I have hard time seeing why me trying to describe the reasons and details of why I suppose it’s unreasonable is “pushing back”.

You are trying to simplify one use case: when a paragraph only contains a single field, without, say, a label.

Wrt David and absence of notifications. The first reply to the report came in 5 hours after submitting. A person could bother to look into the bug he submitted, at least once, say, the next day.

However good his reasons could be to avoid replying (or monitoring), this doesn’t validate the bug itself. It has no proposals inside; it only points to some blog post, where specific proposals are absent, too. Those users who care to improve documentation, don’t see the issues.

So bug is clearly invalid, and rightfully closed. And your “Rather than accept his input and try to slog through this issue which so many seem to have, the bug report has been marked “RESOLVED INVALID” – really?” looks laughable at least. I fail to see those “so many”, given that you are third (after David and one other person in his report - comment #2, which actually deals with a different problem wrt wizards).

When I feel a need to create a new FAQ, I go and do.