Bug 35771 - Printing issues on Mac OS X (Intel)
Summary: Printing issues on Mac OS X (Intel)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: x86-64 (AMD64) macOS (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 57230 66906 (view as bug list)
Depends on:
Blocks: Print
  Show dependency treegraph
 
Reported: 2011-03-29 10:10 UTC by christian@roessner-net.com
Modified: 2018-01-22 11:30 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Example Document that does not print as expected (16.64 KB, application/vnd.oasis.opendocument.text)
2011-03-31 23:52 UTC, christian@roessner-net.com
Details
Another example document (12.81 KB, application/vnd.oasis.opendocument.text)
2011-04-04 02:25 UTC, christian@roessner-net.com
Details

Note You need to log in before you can comment on or make changes to this bug.
Description christian@roessner-net.com 2011-03-29 10:10:10 UTC
Description:

If you open a new LibreOffice writer document and create several pages and click on print, the job does not succeed.

What happens:

It starts two print jobs. The first job just prints the first and only the first page. The second job prints again, but the last page is not printed.

This was tested with several documents on several Intel-Macs (Mac OS X 2.6.6 and 2.6.7). Also 3 three different printers. Network printers as well as USB connected ones.

The same documents get printed cleanly on Linux and Windows 7, so this is a Mac OS X only bug.

Tested on LibrOffice 3.3.1 and 3.3.2

Solution (workaround):

Adding an empty page at any document prints at least all pages (the first page is duplicate though).
Comment 1 Steve Edmonds 2011-03-31 14:32:33 UTC
I have OSX 10.6.7, LO 3.3.2.
I do not have this issue.
Open writer, type P1, cmd+enter for new page, type p2, print.
Printing is normal from File>print and the print icon.

steve
Comment 2 christian@roessner-net.com 2011-03-31 23:52:59 UTC
Created attachment 45119 [details]
Example Document that does not print as expected

The attached document is an example that demonstrates the bug. Please try that one and you might (hopefully should) see the problem ;-)

Just to be sure, I tested exactly this document under Linux (works) and Mac (does not work).
Comment 3 Steve Edmonds 2011-04-01 12:30:17 UTC
I can confirm the problem with the attached document.
Prints to PDF ok.
Printer dialogue does not show the correct number of pages.
Comment 4 Steve Edmonds 2011-04-01 12:37:19 UTC
The first print dialogue has a preview of 3 pages, print 1 to 1
Immediately that job is sent another dialogue opens with print 1 to 2
Comment 5 Steve Edmonds 2011-04-01 13:13:00 UTC
Looking at the document structure, I wonder if that is introducing the problem (not that the problem should occur anyway).
Was this document created from scratch as an odt or did it stem from an import from a word document.
Comment 6 christian@roessner-net.com 2011-04-01 13:23:23 UTC
It was created with OpenOffice 3.
Comment 7 Steve Edmonds 2011-04-01 13:40:14 UTC
Looking at the document structure, I wonder if that is introducing the problem (not that the problem should occur anyway).
Was this document created from scratch as an odt or did it stem from an import from a word document.
Comment 8 christian@roessner-net.com 2011-04-02 00:33:50 UTC
I just spoke with my brother (he reported that bug to me and I as his system administrator reported it to you) that there do exist documents written in OOo that even can not be opened with LO anymore. I am not quiet sure, if this would be a different bug, but you spoke about the document structure. Maybe something is incompatible from OOo to LO that causes one and the other bug, could it?

Probably on Sunday or Monday I can attach such a document that can not be opened. Maybe the cause is the same.
Comment 9 christian@roessner-net.com 2011-04-02 04:58:15 UTC
Ok, the problem with not opening documents was a seperated one (Fileencoding incompatibility. We solved that on the server side). So still the problem with printing is unresolved.
Comment 10 christian@roessner-net.com 2011-04-02 05:03:51 UTC
The sample document was created from an OOo template (ott) file. If my brother remembers correctlky, it was created under OOo version 3.2.2

The problem does exist with all documents. Hundrets. No matter how many pages a document has, it is always the same behavior. Prints the first page followed by printing a second job without the last page.
Comment 11 Steve Edmonds 2011-04-03 10:42:06 UTC
Prints ok from LO3.3.2 and OO3.2.1 on Suse 11.0 (as you stated)

So definitely specific to OSX.
Do you have another example with a more simple straight forward layout.
Comment 12 christian@roessner-net.com 2011-04-03 11:10:39 UTC
I will ask my brother for another example, although I guess all will have the same layout. It will be Monday to get a document to upload here
Comment 13 christian@roessner-net.com 2011-04-04 02:25:26 UTC
Created attachment 45208 [details]
Another example document

This document is not too much easier, but different. I just looked with xmllint to the content.xml and it is a little bit smaller than the first example.

We opened a document that has no tables or stuff. Just floating text and that does print without problems. So it must be a problem with more complex examples.

When I work with Mac and Linux, I often think about \n\r problems or different font encodings (Mac Roman vs. UTF-8, etc.). Not to confuse anybody, but could the problem rely on such problems? That there exists some Mac specific stuff in the document that maybe is only seen with a hex editor or so? Some hidden bytes? Anything that should not be there?
Comment 14 christian@roessner-net.com 2011-04-05 09:54:18 UTC
OpenOffice-3.3.0_x86 does have the same problems on Mac OS X.
Comment 15 Steve Edmonds 2011-04-05 11:45:48 UTC
Hi.
I have found the factor causing the printing issue.
You have pages with top margin set to 0. If I change this to 0.5 cm the documents both print as normal.

This does not explain why I cannot print on a mac with top margin 0 but can on linux.
Comment 16 christian@roessner-net.com 2011-04-05 11:58:28 UTC
You also can print on Windows ;) Can and will this bug be fixed for Mac users? :)
Comment 17 Steve Edmonds 2011-04-16 12:28:49 UTC
The bug is confirmed, although there is a work around
Comment 18 christian@roessner-net.com 2011-04-23 02:38:35 UTC
The bug still exists in lates 3.4b2. There is no workaround, if you see that it affects exactly 8458 documents ;-)

Counted with: find -type f -iname "*.o?t" | wc -l
Comment 19 Fred 2011-05-06 05:09:29 UTC
I had this problem with a template that I first created in Word 97 way back, thereafter converted it in Oo.o 1x (.swt? I can't remember), thereafter in Oo.o 2x converted it to .ott.

My template work fine until I tried Oo.o 3.3 and LibO 3.3. Now only the first page was printed in a document with multiple pages.

I filed this bug:

http://openoffice.org/bugzilla/show_bug.cgi?id=115614

The workaround in  my Comment 8 also works with this bug: 

It seems that it's enough just to open the stylist, select page styles, double
click on "default", then format > page... and just change anything. For example
change a margin by one millimetre. It's even possible to change back if you like.

With this workaround Schreiprobe.odt prints out fine in LibO 3.3.2.

The problem seems to be in templates with a "first page" and "default"
Comment 20 Fred 2011-05-06 05:13:16 UTC
(In reply to comment #19)
> 
> The workaround in  my Comment 8 also works with this bug: 

I refered to comm. 8 in http://openoffice.org/bugzilla/show_bug.cgi?id=115614
Comment 21 Alex Thurgood 2011-05-06 05:22:59 UTC
#ALL :

There are other bugs that appear to be linked to the default page style which
cause printing problems, for example, inserting an envelope as first page. They
may be all be the result of one common cause (or then again, maybe not ;-)).
Certainly, the behaviour described in this bug report is exactly the one I
encountered with bug 36799.


Alex
Comment 22 Alex Thurgood 2011-05-06 05:27:05 UTC
Linking to bug 36799.

Alex
Comment 23 Fred 2011-05-06 05:45:37 UTC
Also Example.odt prints correctly with the workaround in Comment 19
Comment 24 Fred 2011-05-06 07:02:50 UTC
(In reply to comment #19)
> 
> The problem seems to be in templates with a "first page" and "default"
and created with a version prior to 3.3x
Comment 25 Björn Michaelsen 2011-12-23 13:22:37 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 26 Roman Eisele 2012-08-19 08:59:59 UTC
A Writer issue, isn’t it? Therefore adjusted the Component field.

Also reset the Version field according to comment #0. Please note that the Version field should always contain the FIRST version in which a bug is known to exist, and NOT the last one.
Comment 27 Alex Thurgood 2013-05-06 12:17:50 UTC
*** Bug 57230 has been marked as a duplicate of this bug. ***
Comment 28 ign_christian 2013-07-15 07:24:05 UTC
*** Bug 66906 has been marked as a duplicate of this bug. ***
Comment 29 Bernd Kloss 2013-07-15 15:02:43 UTC
Seems to be a senior bug dating from 2011.

I could not find the workaround mentioned in comment 19 (there Comment 8) because this document is not existing any longer.

Can this bug be marked as still existing in 4.1.0.2 and not as historical?
Comment 30 Steve Edmonds 2013-07-15 19:41:15 UTC
The provided example document still has a problem in 4.1.0.0.beta1. I will need to update LO to check the latest version.
Comment 31 retired 2013-07-16 11:11:03 UTC
Interesting problem. On OS X 10.8.4, LO 4.1.0.2.0

1. I hit cmd + p to print this document and
2. select (in the native OS X printing dialogue) to print "All"
3. in the preview I still only see 1 page (despite this document having 3 pages)
4. click "cancle"
5. another printing dialogue opens up
6. select "all" yet again
7. two pages can be printed this time (despite this doc being 3 pages).

More odd behavior can be seen when opting to print only one page. Usually, in the native OS X printing dialogue, I'd be able to select page 1 or 2 or 3. With this document with the up and down arrows I can navigate to page 13 or whatever number I want to. Makes no sense.

Craziest printing dialogue behavior I've seen so far. Christian, you get a high-score for that. :P
Comment 32 retired 2013-07-16 11:14:28 UTC
Forgot: tested with Schreibprobe.odt file.
Comment 33 Cédric Bosdonnat 2014-01-20 08:57:01 UTC
Restricted my LibreOffice hacking area
Comment 34 Bernd Kloss 2015-02-28 11:53:13 UTC
MAC OS X 10.2

LO-Version: 4.3.6.2
Build-ID: d50a87b2e514536ed401c18000dad4660b6a169e

The Bug returned.
Before using 4.2, the bug was gone.

In 4.3.6.2 it is there again.
Comment 35 Bernd Kloss 2015-03-08 17:15:01 UTC
Sorry, my mistake.
You have to apply some change to the template and save/reload it.
Afterwards the multiple-page-printing is okay.
Comment 36 tommy27 2015-08-24 13:04:54 UTC
hi guys, is this bug still present in current LibO 4.4.x or 5.0.x releases?
Comment 37 Alex Thurgood 2015-08-24 13:43:10 UTC
(In reply to tommy27 from comment #36)
> hi guys, is this bug still present in current LibO 4.4.x or 5.0.x releases?

Yes, testing with Example.odt on Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale : fr-FR (fr.UTF-8)

only prints out the first page, the second page is never printed, despite it being visible in the Print Preview
Comment 38 Alex Thurgood 2016-06-16 13:06:48 UTC
Bug still present in 

Version: 5.3.0.0.alpha0+
Build ID: 637371d4d90c2403f02d588ebe745368014b1032
CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; 
Locale: fr-FR (fr.UTF-8)
Comment 39 QA Administrators 2017-09-01 11:18:00 UTC Comment hidden (obsolete)
Comment 40 eisa01 2017-10-20 20:21:00 UTC
Still present

Version: 6.0.0.0.alpha1+
Build ID: 15dce20e8b97dbd0179f01910ca4d0027e80ff4e
CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-10-20_06:46:46
Locale: en-US (en_US.UTF-8); Calc: group
Comment 41 Jack Kenton 2017-10-21 23:31:43 UTC
All word processing prints in landscape mode even though the portrait mode is selected.
PDF files print OK.  they don't use Libre Office.
Comment 42 Ken W. 2017-11-14 00:09:07 UTC
This appears to be a longstanding problem. Unable to print in Portrait mode. Prints okay with OS 10.12.6 but only prints in Landscape mode regardless of setting.
Comment 43 Xisco Faulí 2017-12-06 20:56:20 UTC
*** Bug 114294 has been marked as a duplicate of this bug. ***
Comment 44 Robert Tighe 2018-01-14 22:38:38 UTC
Regarding the problem with the WP printing only in landscape mode (comments 41 and 42). I have had this problem since upgrading to version 5.3.6 and continues with 5.3.7.2, my current version of LibreOffice. I use a MacBook Air running OS 10.12.6 and do not have this problem with any other software or with spreadsheet.
Comment 45 Telesto 2018-01-15 08:03:50 UTC
(In reply to Robert Tighe from comment #44)
> Regarding the problem with the WP printing only in landscape mode (comments
> 41 and 42). I have had this problem since upgrading to version 5.3.6 and
> continues with 5.3.7.2, my current version of LibreOffice. I use a MacBook
> Air running OS 10.12.6 and do not have this problem with any other software
> or with spreadsheet.

This is most likely bug 92190. The issue is resolved in LibreOffice 5.4.4 and 6
Comment 46 Michael Meeks 2018-01-22 11:30:42 UTC
Closing then - please re-open if this persists with LibreOffice 5.4.4 and 6, or LibreOffice Vanilla from the app store =)

Thanks for filing !