Bug 116278 - MAILMERGE (Labels): Unused labels at end of last page should be completely blank
Summary: MAILMERGE (Labels): Unused labels at end of last page should be completely blank
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
: 129521 (view as bug list)
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
Reported: 2018-03-07 19:56 UTC by Ted Lee
Modified: 2019-12-24 17:11 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

sample test label document (9.52 KB, application/vnd.oasis.opendocument.text)
2018-03-07 19:56 UTC, Ted Lee

Note You need to log in before you can comment on or make changes to this bug.
Description Ted Lee 2018-03-07 19:56:12 UTC
Created attachment 140454 [details]
sample test label document

When labels are created the last page will usually contain a number of unused labels, after the last record of the associated database.  If the master label (first one) contains any static data in addition to database fields, that static data shows up in each of the unused labels after the last one filled from the database.  This is not the  behavior I'd expect: the unused labels should be completely blank.  It's not a big deal, but it means one can't save unused labels on a sheet of labels for other purposes, or if the label sheets are used for some other purpose the last page looks kind of ugly.  An obvious work-around is to edit the saved merged document before printing it, manually deleting or clearing all the should-be-blank labels, but one shouldn't have to do that.

Attached is a set of labels produced from a simple database that has fields for first, last, city and state.  The label layout has a space between first and last, a comma and space after city, and a period after state.  There are 20 labels on the page.  The database only has 4 records in it, so the last 16 labels should be completely empty.

This bug is in LO 3.3, so presumably it's legacy.  It's still present in
Comment 1 Heiko Tietze 2018-03-19 15:46:58 UTC
Don't see need for input from UX. Adding Jan-Marek since he worked a lot around mail merge.
Comment 2 Jan-Marek Glogowski 2018-03-21 14:52:39 UTC
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.
Comment 3 Ted Lee 2018-03-21 17:53:31 UTC
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!
Comment 4 Heiko Tietze 2018-03-21 18:11:45 UTC
(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.
Comment 5 Jan-Marek Glogowski 2018-03-21 18:13:25 UTC
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.
Comment 6 Ted Lee 2018-03-22 02:46:44 UTC
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.)
Comment 7 Ted Lee 2018-03-22 19:38:28 UTC
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.
Comment 8 QA Administrators 2019-10-19 02:42:25 UTC Comment hidden (obsolete)
Comment 9 Timur 2019-12-24 17:11:22 UTC
*** Bug 129521 has been marked as a duplicate of this bug. ***