Bug 128496 - Printing a "form letter" with database fields ignores document print settings and tries to print with "default printer?"
Summary: Printing a "form letter" with database fields ignores document print settings...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.2.7.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Print-Dialog
  Show dependency treegraph
 
Reported: 2019-10-31 10:57 UTC by Duncan Bellamy
Modified: 2023-07-28 20:43 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Label Template (10.70 KB, application/vnd.oasis.opendocument.text-template)
2019-10-31 10:59 UTC, Duncan Bellamy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan Bellamy 2019-10-31 10:57:57 UTC
Description:
I have a label template saved as a document template with database address fields as a single label as its for a zebra printer with labels on a roll.  When I print I get the dialog "Your document contains address database fields. Do you want to print a form letter?" If I click yes I can select the database entries I want, and a print window is opened.  But the printer is not the label printer that is the default printer in the label template, and is a the last a4 printer used.  The label text is 90 degrees wrong in the preview, and selecting the label printer does not correct the text in the preview and it prints out 90 degrees wrong as well.

If instead of printing I output to file, the file has the same problem of having the wrong printer and again if I change in the printer window the layout is still 90 degrees wrong.  But if I set the default printer for the document to the label printer and save and then reopen it prints to the label printer and save it and open it again it prints straight away correctly.

This is the same if for an example an A3 printer is set as default printer for the label document template, when the labels are generated the same incorrect printer is used.

Steps to Reproduce:
1.Create a letter/label template with database fields and set a default printer 
2.print document as a form letter and choose database entries
3.

Actual Results:
created document/label has wrong default printer and changing to the correct one does not correct the formatting.

Expected Results:
document/labels should be created with same default printer as the template document


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.2.7.1
Build ID: 23edc44b61b830b7d749943e020e96f5a7df63bf
CPU threads: 8; OS: Mac OS X 10.15.1; UI render: default; VCL: osx; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Duncan Bellamy 2019-10-31 10:59:53 UTC
Created attachment 155420 [details]
Label Template

Example Label Template
Comment 2 Alex Thurgood 2019-11-07 07:01:12 UTC
@Duncan:

Do you have the options 
"Load user-specific settings with document" and/or
"Load printer settings from document"

 activated, under Preferences > Load/Save > General ?

Does playing with these settings make any difference ?

I observe that when I open the test document template in 

Version: 6.4.0.0.alpha1+
Build ID: f7bc0204a80a4f078c63f93b9892904686ad5b36
CPU threads: 4; OS: Mac OS X 10.15.1; UI render: default; VCL: osx; 
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded

and explore the Default Style settings
- the first tab "Organizer" indicates "3.45cm + [from printer settings]"
- the second tab "Page" indicates "Paper Tray" as [from printer settings]"

When I go to print, if I ignore the mailmerge print dialog, then I see a preview of the document with the fields rotated 90° as you have reported, with a default selected printer being my default printer for the machine I'm working from.

Confirming the rotation in the preview.
Also confirming that an attempted print out tries to force A6 page size on my default printer, but even allowing for printing to a different cassette (I don't have an y A6 stock) then the print out is rotated by 90°.
Comment 3 Xisco Faulí 2019-11-08 12:55:19 UTC
Hi Gabor, since you fixed bug 39742 and bug 44786, I thought you might be interested in this issue...
Comment 4 Duncan Bellamy 2019-11-09 15:08:06 UTC
(In reply to Alex Thurgood from comment #2)
> @Duncan:
> 
> Do you have the options 
> "Load user-specific settings with document" and/or
> "Load printer settings from document"
> 
>  activated, under Preferences > Load/Save > General ?
> 
> Does playing with these settings make any difference ?
> 
> I observe that when I open the test document template in 
> 
> Version: 6.4.0.0.alpha1+
> Build ID: f7bc0204a80a4f078c63f93b9892904686ad5b36
> CPU threads: 4; OS: Mac OS X 10.15.1; UI render: default; VCL: osx; 
> Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
> Calc: threaded
> 
> and explore the Default Style settings
> - the first tab "Organizer" indicates "3.45cm + [from printer settings]"
> - the second tab "Page" indicates "Paper Tray" as [from printer settings]"
> 
> When I go to print, if I ignore the mailmerge print dialog, then I see a
> preview of the document with the fields rotated 90° as you have reported,
> with a default selected printer being my default printer for the machine I'm
> working from.
> 
> Confirming the rotation in the preview.
> Also confirming that an attempted print out tries to force A6 page size on
> my default printer, but even allowing for printing to a different cassette
> (I don't have an y A6 stock) then the print out is rotated by 90°.

I have tried on a Windows pc with libre office 6.3.2.2 with and without load user-specific and load printer settings and the result is again the mail merged output ignores the set printer and uses the default A4 one.

I didn't test the other behaviour about rotation as did it with a new test A4 form letter and set printer to pdf printer, but result was the same with mail merged document printer always being the installed A4 printer.
Comment 5 Xisco Faulí 2019-11-11 14:59:12 UTC
Setting to ALL then
Comment 6 QA Administrators 2021-11-11 04:14:29 UTC
Dear Duncan Bellamy,

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

MassPing-UntouchedBug