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 188.8.131.52.
Don't see need for input from UX. Adding Jan-Marek since he worked a lot around mail merge.
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
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.
Dear Ted Lee,
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
*** Bug 129521 has been marked as a duplicate of this bug. ***