What should work is marking the content of the master label as a section and set the sections hide condition based on a value in the dataset.

Just be aware, that there always has to be a visible section or line to place the cursor in a frame. But it should be possible to use two sections, one with content and one empty, which you just show or hide, so at least one of them is visible. Or just have an empty line after the new section.


A better UX for hidden labels
-----------------------------

I'm not sure there is an straight forward way to implement this for synchronized labels.

Just hiding the whole label would be nice, but that would change behavior, so it won't be implemented.

For synchronized labels we already use sections, but it's a single one, so it can't be hidden. You can hide the section, but it'll stay visible, as there has to be a place for a cursor. That limit won't change.
But if we create the labels with two sections and set the second sections hide condition to the negated / inverted condition of the first, just one of them is visible at a time. In addition add a button to the synchronize dialog to switch them. This way the 2nd section might even have different content.

All this is probably larger work - I don't know the label generation code at all, just the processing mail merge code - might even be a GSoC project. And it has to stay compatible with existing label documents, which is probably harder to realize.

At one point I tried using hidden sections to suppress blank lines, as suggested somewhere on-line, but as I recall I had trouble making it work. But I did find that turning every line into a paragraph and then using hidden paragraphs worked fine to suppress blank lines.  In the case of a line that had no data fields (because it was in a label after the last record) I could not use that to suppress the line (paragraph) containing just static data (such as the comma between city and state) -- presumably because that label was never actually processed.

Thinking about your response I did realize one way to accomplish what I want.  Rather than putting static data (such as that comma between city and state) in the master label, all I would need do is put a field for the comma in my database, populating it with a comma in every record.  I'm not sure if that would be easier than simply editing the last page of the label document before printing it, but at least I wouldn't have to remember to do it!

(In reply to Ted Lee from comment #3)
> Thinking about your response I did realize one way to accomplish what I
> want. 

If you succeed please close the ticket as WORKSFORME. I doubt that we have an easy solution and IMHO it's not worth all the effort.

Since you didn't write about the data source: if it's a Calc sheet you can construct the required string in an additional column.

And even if it is not it would probably be easier to generate a Calc sheet from the data. Then you can manipulate the data in a way suitable for mail merge.

There is no way mail merge will ever remove commas between fields.
The only properties mail merge works with are fields and section visibility. Anything more advanced has to be handled by some view in a database, where you can use SQL to manipulate strings, or Calc functions to construct an additional Calc sheet column.

I'm afraid I can't say "WORKSFORME" because it doesn't!  My "bug", if you are willing to call it that, is that the label function does not work the way a user expects it to: If I have only 25 records in my database, only 25 labels should be printed! -- but, say, the page has room for 30 labels, the function will print any static data in the master label in the remaining 5 labels.  In principle I don't understand why it should be so hard to make it work the way it should, but I do sense that the label function was added after mail merge and used that in the simplest way possible to accomplish the task and somehow the present behavior is a side-effect of that implementation.  The strange floating "synchronize" window that shows up to implement labels is an indication that it is a strange, albeit I am sure clever, design.

Yes, it would be relatively easy to add a static column containing a comma (or other static text like a To: or From:) in a small database.  But if it were one that had thousands of records it wouldn't be.  I do believe, however, one could easily create a view of the database that added an extra computed field that simply was a constant, and use that view to drive the label engine, but I wasn't quickly able to figure out how to do that.  The built-in help for databases isn't very helpful when it comes to creating views and I was too lazy to dig around the net for a better tutorial or description on how do to it.  (I am sure you can create a view that, say, creates a field C that is the sum of fields A and B, but I couldn't figure out how to do that. But if you can do that, you ought to be able to create a field that is just a constant value.)  Still not something you ought to have to do to get the label feature to work right, but it isn't much more burdensome than what you have to do to suppress printing blank lines.  So I'm willing to tag the bug as WorkAroundAvailable (or however that is marked) and of course would recommend the help text for labels has something on the topic (as well as how to suppress blank lines.)

FYI, I did figure out how to create a field in a view that is just a constant character string.  (It was trivial, ultimately.) So that is indeed a relatively easy workaround for the problem.  (All the unused labels at the end of the last page now come out blank.)  I changed the importance from "enhancement" to "trivial".  I believe that whenever a program does not work the way a reasonable person expects it should, that's a bug, minor though it may be.  Why it's not been reported before I don't know, of course, but perhaps the label feature isn't used very much.

*** Bug 129521 has been marked as a duplicate of this bug. ***

I couldn't reproduce this. So either it works or there is some detail missing. 
Sample attachment 140454 [details] is not proper, it's a result, not source. 
I set Needinfo for sample source with fields that come from in-built Bibliography database.

Dear Ted Lee,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp