Bug 83853 - Other: Printing from File>Labels fails without error message
Summary: Other: Printing from File>Labels fails without error message
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Blocks: Labels-BusinessCards
  Show dependency treegraph
Reported: 2014-09-14 17:12 UTC by Martin Thomas
Modified: 2021-10-19 03:41 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Martin Thomas 2014-09-14 17:12:53 UTC
Problem description: Printing from File>Labels produces no output. This is equally true if the option to print output to file is selected (i.e. it's isn't a printer problem with us).

There is no error message and the program appears to function normally (e.g. it prompts for a filename for the output in print-to-file and for a folder into which to save the output)... only, there's no output.

We have this bug currently on LibreOffice on three different Arch Linux machines. Printing still works on LibreOffice on a Mac in our office running OS 10.6.8.

We had this same problem some months back and reported it on the LibreOffice forums. There was some discussion there, but nothing which helped resolve the problem. The problem cleared up then as mysteriously as it had appeared.

We hoped that it was fixed by an update in LibreOffice, but evidently not.

This time, the bug first appeared on a machine which the same day, only an hour or so before, with the same version of LibreOffice, and without any intervening restart or anything, had printed ok. It would appear not to be a new bug in, but maybe a longstanding but erratic bug.

Steps to reproduce:
1. Open a database in LibreOffice
2. Select File>Labels and use already-existing format for labels
3. Click on New Document
4. Choose print.

Current behavior: As above, everything appears fine except that there is no output (not even if we select print-to-file).

Expected behavior: To get output.

Operating System: Linux (Other)
Version: release
Comment 1 Robert Großkopf 2014-09-14 17:49:05 UTC
Have tried to start to edit labels (file → open → labels). Only worked the first time I tried. Then the wizard crashes the whole LO while creating the new document. Tested with LO and LO System here: OpenSUSE 64bit rpm Linux.
The first time I got a document. This could be printed well ...
Comment 2 Philippe Morin 2014-11-14 22:27:17 UTC Comment hidden (obsolete)
Comment 3 Philippe Morin 2014-11-14 22:28:58 UTC
(In reply to Philippe Morin from comment #2)
> I also have this problem!

I use on Mac OS X 10 (Yosemite)
Comment 4 Alex Thurgood 2014-12-17 13:40:37 UTC
Tested with

Build ID: 7d55112667c8fcddb67bc3803796b46c93aa56b0

OSX 10.10.1

1) Open a database file.
2) File - New - Labels
3) Choose pre-existing format (I chose Avery A4)
4) Click on New Document
5) Now try to print document to printer (Kyocera networked FS C5150 DN)
6) Printing fails with printer error message requesting insertion of Monarch size envelope in Manual Paper feed.

Observations : the page attribute is set to User 10cm x 10cm, which is clearly wrong, as per my choice it should have been A4.

This is not imho a database issue, rather a Writer module issue. Changing component accordingly and confirming.
Comment 5 Alex Thurgood 2014-12-17 14:01:19 UTC Comment hidden (obsolete)
Comment 6 Alex Thurgood 2014-12-17 15:15:30 UTC Comment hidden (obsolete)
Comment 7 Steve Saus 2014-12-18 03:51:51 UTC
This "workaround" worked:

1. Set up your merged document. 
2. **Save the set up document without trying to merge it**
3. Close all LibreOffice applications.  Kill the daemon if you have it running (I don't).
4. Re-open your set-up document.  It will ask you if you wish to reconnect to sources.  Answer *yes*.
5. Print.

Things that did NOT seem to make a difference:
1. Saving the document without closing and reopening LO before attempting mail merge.
2. Rebooting the PC.

The key seems to be in the reconnecting to the source, if that helps y'all figure out where the bug is, that'd be awesome.
Comment 8 Alex Thurgood 2015-01-03 17:39:18 UTC Comment hidden (no-value)
Comment 9 Winfried Donkers 2015-04-24 09:25:54 UTC
With steps:
1. Select File>Labels, use available database (e.g. bibliography), put one or more fields on the label (with already-existing format for labels);
2. Click on New Document;
3. Document shows, but with field names, not with data;

Synchronizing does not help, openening data source (F4) and selecting records neither.
On printing or export to PDF, the field names are on the labels, no data.

Reproduced with LO 4.1.6 on openSUSE13.1-64 and LO4.4.2.2 on Windows 7.

It used to work fine (unfortunately last tested more than a year ago).

Although not exactly the same steps to reproduce, IMHO this is the same bug as in above comments and related to database connection.

Mailmerge does work fine.

Comment 10 Winfried Donkers 2015-04-24 10:11:42 UTC
(In reply to Winfried Donkers from comment #9)
> On printing or export to PDF, the field names are on the labels, no data.

Due to mangled information I received, I  must correct the above: when printing, a dialog appears about the database connection and selection to be printed, resulting in a proper print. In other words, printing behaviour is as expected.

This does not work for export to PDF, nor for print preview, though.
Comment 11 QA Administrators 2016-09-20 09:32:52 UTC Comment hidden (obsolete)
Comment 12 Julien Nabet 2016-10-18 19:40:06 UTC
On pc Debian x86-64 with master sources updated today, data appear when printing on file.
Data don't appear when exporting in pdf, just fields appear.
Comment 13 QA Administrators 2017-10-23 14:13:02 UTC Comment hidden (obsolete)
Comment 14 Winfried Donkers 2017-10-24 05:54:08 UTC
With version on Windows, data appears when printed, but not in print preview nor in PDF export.
Comment 15 Martin Thomas 2017-10-24 08:42:42 UTC
Bug still present, though erratic. The workaround described in comment 7 seems to work quite reliably.
Comment 16 QA Administrators 2019-10-19 02:42:06 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2021-10-19 03:41:58 UTC
Dear Martin Thomas,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team