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).
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
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).
I can confirm the problem with the attached document. Prints to PDF ok. Printer dialogue does not show the correct number of pages.
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
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.
It was created with OpenOffice 3.
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.
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.
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.
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.
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
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?
OpenOffice-3.3.0_x86 does have the same problems on Mac OS X.
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.
You also can print on Windows ;) Can and will this bug be fixed for Mac users? :)
The bug is confirmed, although there is a work around
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
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"
(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
#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
Linking to bug 36799. Alex
Also Example.odt prints correctly with the workaround in Comment 19
(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
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.
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.
*** Bug 57230 has been marked as a duplicate of this bug. ***
*** Bug 66906 has been marked as a duplicate of this bug. ***
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?
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.
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
Forgot: tested with Schreibprobe.odt file.
Restricted my LibreOffice hacking area
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.
Sorry, my mistake. You have to apply some change to the template and save/reload it. Afterwards the multiple-page-printing is okay.
hi guys, is this bug still present in current LibO 4.4.x or 5.0.x releases?
(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
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)
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
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
All word processing prints in landscape mode even though the portrait mode is selected. PDF files print OK. they don't use Libre Office.
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.
*** Bug 114294 has been marked as a duplicate of this bug. ***
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.
(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
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 !