Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Enable the user to avoid empty pages being created/printed|
|Status:||CLOSED FIXED||QA Contact:||issues@sw <issues>|
|Priority:||P3||CC:||al.nowak, andreas.martens, email, g.wagenknecht, gerry, harald.schilly, hillview, issues, lists.sridhar, llanero, norbert.notz, openoffice.bugs, pagalmes.lists, rb.henschel, simon.spielmann, t8m, wsf|
|Version:||OOo 1.0.0||Keywords:||oooqa, rfe_eval_ok, usability|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description lohmaier 2002-04-07 14:11:07 UTC
When inserting either a manual page-break or changing the properties of the first paragraph of a page to have another page-number for the following pages OO.o inserts an "invisible" page (invisible in the 'regular' view, but present in the page-layout with 'empty Page' ('leere Seite' in german) written on it). The statusbar display this page as well (page [x] y/<number of pages + empty page>) When inserting more text before the break, the 'invisible' page gets filled and displayed and the page-counting reflects the actual number of pages as one would expect. Now step by step: 1) open a new textdocument and insert some text 2) choose a paragraph that should be on top of the page with the assigned pagenumber and edit its properties: break,before,with template/layout, page number # (I' don't know the english terms) 3) have a look at the status bar: instead of x/2 it displays x/3 3a) search for that third page - you won't find it 3b) now have a look at the page-layout view - there it is! but empty 4) print the document to a ps/pdf-file: the empty page gets displayed in the ps/pdf (thats the reason for this issue) 5) insert more text to the first page (so it doesn't fit on one page any longer) -> no more empty page 5a) now we've got all the three pages - just like the status bar tells us and what's more important no empty pages in our ps/pdf
Comment 1 lohmaier 2002-05-18 12:08:15 UTC
Set the version to 1.0.0 since the bug occurs there as well, changed the subject to better describe the problem: The empty pages are printed and thus are not 'invisible' all the time
Comment 2 florianbruckner 2002-05-19 12:46:44 UTC
Having the same problem I found a way to work around it. The problem seems to be related to the "Page Layout" setting in the Page style. I have a document with the following structure: First Page (does not restart page numbering) TOC (restarts page numbering at 1) Default (restarts page numbering at 1) Indices (restarts page numbering at 1) After First Page and after TOC there is a nasty blank page. If I change the "Page Layout" setting of "First page" to "Only right" and of "TOC" to "Only left" both blank pages are gone. If TOC grows to more than one page, again a blank page is inserted between "First Page" and "TOC". If page numbering is not restarted, the problem is not there. I find this a rather nasty thing, because it prevents me from doing larger documents in OO.
Comment 3 florianbruckner 2002-05-19 12:48:54 UTC
Forgot to mention that my platform is Windows2000.
Comment 4 lohmaier 2002-05-21 14:36:28 UTC
Thanks for your comment, Florian. Since you're using Windows and I linux, I set the os to All.
Comment 5 eric_openoffice 2002-05-24 09:11:27 UTC
I have the same Problem as Christian with the manual insert of a page-break using Open Office.org 1.0 German Version under Windows XP Professional. Thanks to Florian Bruckner I have a workaround but that workaround doesn't always work as it shoul because if you have page number one make a manual page-break and try to start with another page number one you still have three pages and not two, when using a left page an german error message appears that says something like: Page number cannot be insert. On left pages only numbers like 2 4 6 are allowed (sorry don't know the english term for "gerade Zahlen") and on right pages only page numbers like 1 3 5 ("ungerade Zahlen") are allowed. When not restarting pagenumbering the problem does not appear. I tried to find a workaround to start the page numbering manually with page number one but up to now I still found no other way to start with page number without making an manual page-break and allowing OpenOffice.org 1.0 to start recounting.
Comment 6 gnmacken 2002-06-11 04:55:21 UTC
I have a similar problem with a report with a title page and the first page of text is page 1. I first tried to use a title page page style as is recommended in the help documentation. Unfortunately this resulted in a "blank page". I eventually came up with the following work around. 1. Create a Title Page page style as recommended 2. Create a Body Page page style with the attributes you want (headers footers, etc)[can use the default style] 3. Create a First Body Page page style that is based on Body Page but is "Left Only" and has a next style of Body Page 4. After the contents of the title page insert a manual page break with a next style of First Body Page and a page number of 1. The "blank page" will not appear and the page numbers are as I expected.
Comment 7 andreas.martens 2002-06-21 16:24:49 UTC
Hey folks, that's a feature, not a bug! In every book or newspaper or whatever the odd page numbers are on the right side, the even page numbers on the left side. If you choose a page number for a paragraph, you set automatically a left(right) page. If you choose a page break with a left page and the paragraph before is on a left page too, you will get an empty (right) page between this paragraphs. This page is only shown in the print preview and it will printed as well. If you have a duplex printer you will enjoy our empty pages! So I don't think we should fix this "bug", but maybe it's a good idea to create a new printer option like "ignore blank pages" and when you check it, the empty page will not be printed.
Comment 8 lohmaier 2002-06-21 18:08:30 UTC
> that's a feature, not a bug! That is to be discussed ... > In every book or newspaper or whatever the odd page numbers are on > the right side, the even page numbers on the left side. OK. > If you choose a page number for a paragraph, you set automatically > a left(right) page. I always thought that this is what the page-templates 'left Page' & 'right page' are for. > If you choose a page break with a left page and the paragraph > before is on a left page too, you will get an empty (right) page > between this paragraphs. The problem is that I don't want to instert the page break to get another left page (I'd then use the proper template), but just change the page-number. > [...] If you have a duplex printer you will enjoy our empty > pages! If I had a duplex printer I'd enjoy being able to set the paper-try in the page-template's properties (one can do that) > So I don't think we should fix this "bug", but maybe it's a good > idea to create a new printer option like "ignore blank pages" and > when you check it, the empty page will not be printed. I can live with that solution, but than make sure that these empty pages are omitted as well when printing to a file (ps or PDF). For the meantime: How would change the page number in a Writer Document without getting these empty pages?
Comment 9 stx123 2002-07-08 17:42:03 UTC
Removed ooo1.0 keyword in respect to Andreas comment.
Comment 10 lohmaier 2002-08-21 23:44:12 UTC
I'd really appreciate it if you could tell me the correct way to change the page numbering without getting these empty pages. See the older comments for more details.
Comment 11 pbryan 2002-08-22 01:11:07 UTC
Just some user comments... As a user who has just used a duplex printer to print a document with manual page-breaks that start with new page numbers, I can now understand why this "feature" exists. Upon reflection, I think the decision to insert or not insert blank pages should be deferred until print time, where the print logic can know if duplex printing is taking place or not. If duplex printing is taking place, then adding the blank pages makes sense. However, if simplex printing is taking place, these blank pages should not be inserted because they have no meaning.
Comment 12 lohmaier 2002-08-24 12:46:50 UTC
Hi Paul, I cannot follow the 'duplex-printer-argument'. If you want to make a difference between left or right pages, you can use page templates (layouts) for left and right pages. The paper-tray to be used can be defined in these templates, so when you insert a manual break to change page-numbering you can choose 'with template "right/left page"' to make sure that the correct paper tray is used and that the duplex-printer's funcionality is used. Keeping in mind, that you cannot only print a document on paper, but create electronic documents like pdf as well. And there is no way to avoid blank pages in a pdf when changing the page number. Letting the print-process decide whether to use duplex-printing or not is a good idea, but it shouldn't have to decide whether to include empty pages or not.
Comment 13 pbryan 2002-08-25 18:29:05 UTC
Hi Christian, Let's use a concrete example here: a document with one title page, three table-of-contents pages and fifty content pages. You want the title page to have no page number, the table-of-contents pages to be numbered pages i-iii and the content pages to be numbered 1-50. I think there's nothing contraversial about this so far. AFAIK, the appropriate way to perform this is to insert manual breaks after the title page and the table of contents, changing the page number to 1 and indicating a new page style. In my case, I created two new page styles for these manual breaks: ToC and Body. In the ToC page style, I inserted page number to the footer with the Roman (i ii iii) page numbering format. In the Body page style, I inserted a page number to the footer with the Arabic (1 2 3) page numbering format. For the page styles I defined, I set the page layout to "left and right", because as the document author, I cannot predict what when a page of a particular style will appear on the left or right page. Okay, now on to the contraversial issue... If my document is printed on a simplex printer, I want the title to appear on physical page 1, my table-of-contents to begin on physical page 2 and my content to begin on physical page 5. All printing on page fronts, no blank pages in between sections. If my document is printed on a duplex printer, I want the title to appear on the front of physical page 1, my table-of-contents to begin on the front of physical page 2 and my content to begin on the front of physical page 4. The back of physical pages 1 and 3 should be blank. I presently don't see a way of achieving this with OOo. In your example, you suggested that when a manual break is inserted, use the "left page" or "right page" style. Doesn't this assume that all subsequent pages in that section carry the same style? Must I perform manual breaks for all pages in that section to alternate between left and right page styles? Also, I have to think this problem has been addressed with "true" (not simply generated by a print driver) PDF files already. A PDF file can be printed to a simplex or duplex printer, and the behavior of new sections needs to allow for the first page in a new section to appear on the front of the physical page.
Comment 14 lohmaier 2002-08-25 19:24:59 UTC
Created attachment 2605 [details] image showing page/print preview
Comment 15 lohmaier 2002-08-25 19:26:03 UTC
Created attachment 2606 [details] image showing the setting for left/right layout of a page-template
Comment 16 lohmaier 2002-08-25 19:27:08 UTC
Created attachment 2607 [details] image showing how to the the following template
Comment 17 lohmaier 2002-08-25 19:55:37 UTC
Hi Paul, * the attached image overview.png shows the scenario you described (picture says more than thousand words) > For the page styles I defined, I set the page layout to "left and > right", because as the document author, I cannot predict what when a > page of a particular style will appear on the left or right page. I don't understand that. > Okay, now on to the contraversial issue... > If my document is printed on a simplex printer,[...] > All printing on page fronts, no blank pages in between sections. Exactly what I expect OO.o to do. (I regard creating pdf-Dokuments as printing on a simplex-printer as well) > If my document is printed on a duplex printer,[...] > I presently don't see a way of achieving this with OOo. I'll try to explain how I would achieve this.. To make sure, that the TOC starts at a new physical page, have a look at the picture 'layout.png' You'll have to set this to something else than "Rechts und Links" (right and left). "Gespiegelt" (mirrored?) should work if page-pargins are the the same and the Toc starts with an odd number (odd page-numbers are right pages) 1 is an odd number, so this would work. (Otherwise you'd have to use 'left/right TOC'-templates) The same would work for your body-layout if you wouldn't like to start new sections/chapter on a new physical page. (I assumed that) In your style for the section's caption you can set a "page break before" to start a new page and set the page-style that should be used. (You want to set 'right page' to start a new physical page in this scenario) > In your > example, you suggested that when a manual break is inserted, use > the "left page" or "right page" style. Not 'or' but 'and' > Doesn't this assume that all subsequent pages in that section carry > the same style? Must I perform manual breaks for all pages in that > section to alternate between left and right page styles? NO! Have a look at the attached picture 'following.png' in the settings for the page-layout, it's possible to set the page-layout that should follow the current layout when an (automatic) pagebreak occurs. In the picture you see the settings for the pemlate 'right page' (Rechte Seite). The layout that should follow is the "Folgevorlage", in this case 'left page' (Linke Seite). The settings for the left page is set accordingly ("Folgevorlage" for left page is right page), so there's no need to use manual breaks to alternate between right and left styles. (in the picture overview.png, right pages have a greater right margin, left pages have a bigger left margin) > [...] A PDF file can be printed to a simplex or duplex printer, and > the behavior of new sections needs to allow for the first page in a > new section to appear on the front of the physical page. In all cases I've seen so far there's always an additional page inserted with the smart text "This page intentionally left blank" But I don't own a duplex-printer, so maybe there are means to achieve this with some kind of pdf-internals.
Comment 18 lohmaier 2002-10-01 17:38:09 UTC
*** Issue 7913 has been marked as a duplicate of this issue. ***
Comment 19 zot 2002-10-01 18:05:18 UTC
(BTW the odd vs een argument is true. If you change the page number to even (2,4,6,8) then it does not add the blank page. This is clearly a bug/bad feature/poor design choice. 1) To assume that everyone is using duplex printing is outrageous. I know very few people not in an enterprise location that have duplex printers. And most people in enterprise situations have local simplex printers for their use. I create pdf's for invoices, quotes, PO, etc. I send them as pdfs. I have a title page, and then a body, nothing fancy. I have had clients question why our pdf's did this. We had to look stupid. There is NO reason to expect a blank page. 2) If I want a blank page, because I am using the duplex printer (I have one as well), I would add a page break to get the empty page. That is the crux. There is an instant work around for the minority, but the majority is screwed. [If you can remember, you can print pages 1,3-15 or whatever, but you must do that *every* time, since it is forgotten, and you are screwed again if you do this multiple times in the document.] To make the majority jump through hoops for the minority is not a feature, it is a bug being used by the minority. It remembers me of the old Netscape bug that allowed multiple HEAD sections to be sent down stream. When they fixed it, a small group of people complained that *now* it was broken. What do other word processors do? I have never seen one that automatically put blank pages in. If you want to have a "insert blank pages for duplex printing" that is fine, but it cannot be the default. In the mean time fix this to stop inserting blank pages.
Comment 20 eamon 2002-10-16 11:21:28 UTC
We operate two duplex printers, a number of simplex. We also transmit documents in PDF format. We also do some very large documents (openoffice seems better for this/excluding TOC not hyperlinking/lack of TOC hyperlink to PDF) - we are looking at moving all document production away from office to a mix or staroffice/openoffice. The "Inserted" pages are very usefull with the duplex printers - esp. when transmiting a document via PDF (prints correctly duplexed) However the are a real pain with simplex printing. I would turn the "blank pages" off by default and add an option in options/openoffice/print to turn duplex (blank pages) on or off.
Comment 21 lohmaier 2002-10-30 21:47:46 UTC
*** Issue 5906 has been marked as a duplicate of this issue. ***
Comment 22 stefan.baltzer 2002-12-09 14:58:22 UTC
Obviously, this feature confuses many of those who are NOT writing books (or other documens dedicated for sophisticated duplex printing). I think we may well sum this up as an ehancment (I changed the Title accordingly): Enable the user to switch off empty pages: Case 1: Prevent empty pages from being created at all [Enable a "page 2" on the right side] Case 2: surpress them when printing to printer/file Case 3: surpress them when exporting to PDF My idea: checkbox(es) on Tools-Options-Openoffice.org-Text document-Print in group box "pages". Reassigned to Bettina.
Comment 23 lohmaier 2003-01-04 00:35:31 UTC
*** Issue 10417 has been marked as a duplicate of this issue. ***
Comment 24 lohmaier 2003-03-03 22:57:00 UTC
*** Issue 11597 has been marked as a duplicate of this issue. ***
Comment 25 lohmaier 2003-03-04 17:15:16 UTC
*** Issue 12038 has been marked as a duplicate of this issue. ***
Comment 26 lohmaier 2003-04-27 14:13:55 UTC
*** Issue 13787 has been marked as a duplicate of this issue. ***
Comment 27 arifsaha 2003-05-22 23:01:47 UTC
I also feel that the behaviour of OpenOffice writer of inserting blank page when not requested is a bug. And especially important that now OpenOffice can export directly to PDF, without any way to avoid the blank page included. Somebody said about the behaviour is correct for book writing. Even if it is true, it will be small minority of potential OpenOffice users. While it nice to provide a feature of automatic blank page for book writer, force into everyone is definitely a bug. Evenmore, the default behaviour should be blank page only came up when requested. Hope it get fixed soon. Thanks, though, OpenOffice is a great job nevertheless. Let's make more people actually happy to admit it.
Comment 28 lohmaier 2003-05-30 19:54:11 UTC
time for a target...
Comment 29 bettina.haberer 2003-06-03 16:56:35 UTC
Not possible before OOo 2.0.
Comment 30 lohmaier 2003-06-09 23:41:45 UTC
*** Issue 15431 has been marked as a duplicate of this issue. ***
Comment 31 lohmaier 2003-06-12 17:48:18 UTC
*** Issue 15418 has been marked as a duplicate of this issue. ***
Comment 32 lohmaier 2003-06-28 22:55:00 UTC
*** Issue 16188 has been marked as a duplicate of this issue. ***
Comment 33 Regina Henschel 2003-06-29 20:00:27 UTC
Here my suggestion for handling this problem. Please add a new page layout "single side" into the page-template which is intended to print on simplex printers and where OOo will not insert empty pages. So the author can decide whether he will write front/back -as for books- with the already existing layouts or he will write only on front -as in the most private cases- with my suggested layout. kind regards Regina Henschel
Comment 34 rblackeagle 2003-07-19 20:56:13 UTC
The issue has been made worse in 1.1RC. In a Master Document in particular, such a change in Page Style (with a Manual Break) now produces three extra blanks pages. I just tested it with a First Page page style and then a Left Page style and got the extra page. To eliminate it, I changed First Page style to "Right Page Only" and it shows as page *2*!!! The blank page has now been made the first page. With this bug, it is impossible to set the first page number after a break to page "1" -- it will always be something between "2" and "4" (larger numbers of blank pages in a Master Doc). Doing a work-around using offsets leaves the TOC entries wrong (instead of page "1" it shows page "42" -- making it useless).
Comment 35 rblackeagle 2003-07-23 05:31:27 UTC
Due to some comments on the users' list, I have refined my description of the problem. It goes like this: What I've want: 1) Beginning First Page Style -- numbered Roman numeral "i" and normally having "Beginning Following Page Style" --- Manual Break with "New First Page Style" which has "Following style" as the "Next Style" (under the Organizer tab of the style dialog), and with page number "1" ---- 2) Blank page (can't have two odd pages back to back) with "Beginning Following Page Style) and page "ii" 3) New First Page Style -- numbered page "1" 4) Following Style -- numbered page "2" What I get: 1) Beginning First Page Style -- numbered Roman numeral "i" --- Manual First Page Style as above --- 2) Blank page --- Marked as New FIrst Page Style and page number "1" 3) Following Style -- numbered page "2" -- with headers I don't want 4) Following Style -- numbered page "3" There's a way to force the First Page Style to page 3), but no way to fix the page number so it will come out right in indexes and TOC's. I may complain, but it's the complaint and the replies of others that made me understand exactly what the problem is and how to describe it.
Comment 36 tristanb 2003-08-09 12:27:32 UTC
i like Regina Henschel's suggestion. If you do this, "single-side" should be the default layout; people who are going to use duplex printers are more likely to know how to change page styles to get what they want.
Comment 37 lohmaier 2003-08-10 00:01:49 UTC
I don't like Regina's proposal since when wanting to brint both to a duplex printer AND to pdf/singe sheets you'd have to switch page-styles first wich adds unnecessary work (for the user and probably for the programmers). I'd better like an option in the print-dialog "omit automatically generated blank pages" (e.g blang pages created intentionally still make it into the printout - only those that are marked with "blank page" in the page-preview should not be printed.
Comment 38 gwagenknecht 2003-08-10 13:36:21 UTC
Christian, IMHO this can not be done by simply adding a checkbox to the print dialog. First, PDF is not generated through the print dialog and second this doesn't solve our problems. The core problem is the handling of double and single sheet documents. If a document is a double sheet document it will be printed on left and right pages. In this case you might have differen margins and other settings. These should be also kept when exporting to pdf. In single sheet pages your documents have no left or right pages and OpenOffice has problems with this type of documents, which should be solved. The biggest problem is the addition of blank paes to the print or pdf export output. In generally I think the support for single sheet documents is not very well implemented. When a document is a single sheet document why still dealing with left/right pages in most dialogs? It is way to complicated.
Comment 39 tjkampa 2003-08-10 19:29:00 UTC
I agree. I think this should be solved with a 'single side' (or some other description) option in the page layout drop-down menu in page styles. Tim
Comment 40 lohmaier 2003-08-12 18:09:45 UTC
*** Issue 3142 has been marked as a duplicate of this issue. ***
Comment 41 lohmaier 2003-09-01 20:08:10 UTC
<sigh> - Forget about the placement of the option to toggle the option on or off. But I don't think it is necessary to change the style settings for your docoment just for printing it. When creating n-up prints or brochures, these additional pages make sense! So I'd like to be able to print a (shrinked down) draft with the additional pages, but as well create a PDF without these additional pages without having to fiddle with style properties and loose my layout. An additional Option during PDF-Export or in the Print-Dialog would perfectly solve this problem. I don't care where I have to check the option - be it a global preference setting somewhere in Tools|Options or in the Print and/or Export Dialog. It could even be part of the Document Properties - I don't care. The problem is not about single vs double sheet printouts - I want different margins in my PDF but without that *automatically* added blank pages. Again a additional style-property is not needed and wont help.
Comment 42 gwagenknecht 2003-09-02 06:37:31 UTC
In response to comment from Christian Lohmaier (2003-09-01 12:08 PDT) I think you pointed it out correctly. There are several requirements related to this bug. But your suggested solution again only covers one requirement as seen before. Requirement A: There is a need to avoid empty pages beeing printed out or exported into other formats (eg. PDF). But sometimes it is necessary to export them to PDF, too. A possible solution is a kind of "draft" option which avoids the print out/export of empty pages and can be enabled in the print out and export dialog. Requirement B: There is a need to better support single side documents where the creation of empty pages in general is very confusing and absolutly not necessary. I eperienced this use case during writing my thesis document with OpenOffice. As a new user I was very confused not to find a suitable setup. This can be solved by providing a single-side document layout becasue this kind of setup/config is related to the document and will never be changed. As a side effect the "draft" option mentioned before will be grayed out in the print out/export dialog using this layout.
Comment 43 gwagenknecht 2003-09-02 06:40:52 UTC
To summarize it: Req. A: avoid empty pages beeing printed/exported Req. B: avoid empty pages beeing created
Comment 44 rblackeagle 2003-09-03 05:24:32 UTC
gwagenknecht's summary seems a good one, but would require repagination if blank pages were not wanted or wanted. Thus we would have a message (perhaps) that said: "Please wait while repaginating" or something of the sort. A bigger problem for the programmers is that I want blank pages in some situations within a document and, within the same document, don't want them in others (especially not two and three blank pages). However, if I want blank pages, I can easily add them or make sure that two right or left pages follow one another. Thus, I would vote for removing automated extra page creation while drafting a document as we currently have. For printing, it would be wonderful to have the ability to choose.
Comment 45 lohmaier 2003-09-05 17:18:23 UTC
I still don't see the need for a differenciation between the following: > Req. A: avoid empty pages beeing printed/exported > Req. B: avoid empty pages beeing created I you "apply" A) you got the same as B) so why should B) be a seperate requirement?
Comment 46 gwagenknecht 2003-09-06 16:57:21 UTC
Because "A" confuses users not familar with "expert" text systems where this might be a "must-to-have" feature and to be honest the empty pages are very uncommon in "easy-to-use" word processors. Even high professional commercial book writing software I used to work with for writing books for IBM didn't have this problem. It's so simple and clear. When a user creates a new document he has to make a simple decision - single side or double side. We all know that even this simple decision is not simply doable with the current solution found in OpenOffice. Instead users are expected to "think around the corner" and associate a "single side" document configuration with a "left/right type" like it is currently used in OpenOffice's document setup dialogs. Remember, when developing software for a wide range of users, you can never expect a user understanding your way. You might not see a need because for you and your use case the current solution is clear. But believe me a lot of users will not. Yes, I might speak of users not familar with changing time in Windows (if they have rights to), but a good application has to be simple to be easy to use.
Comment 47 rblackeagle 2003-09-07 03:53:49 UTC
This issue has been going around for a long time and more than one issue has been filed for it. The "single-sided/double-sided" issue is a bit different, although, as I see it, is related. "Single-sided" is what I get when I print all pages on a simplex printer. On a duplex printer, "simgle-sided" would add a blank (non-numbered) page between numbered pages (1 - blank - 2 - blank - 3 - ...) The basic issue is that blank pages are sometimes added contrary to what the user wants and are numbered, *very* often contrary to what the user wants. Give me blank pages only when I want and not at other times. Let me choose single-sided or double-sided as I choose (and add unnumbered blanks for single-sided using a duplex printer or call it "print with duplex printer as if simplex."
Comment 48 lohmaier 2003-09-12 14:00:15 UTC
*** Issue 18654 has been marked as a duplicate of this issue. ***
Comment 49 lohmaier 2003-09-17 19:11:39 UTC
*** Issue 19138 has been marked as a duplicate of this issue. ***
Comment 50 guido.pinkernell 2003-10-23 11:29:43 UTC
*** Issue 19139 has been marked as a duplicate of this issue. ***
Comment 51 lohmaier 2004-02-12 16:00:19 UTC
*** Issue 25224 has been marked as a duplicate of this issue. ***
Comment 52 lohmaier 2004-03-15 17:04:18 UTC
*** Issue 26502 has been marked as a duplicate of this issue. ***
Comment 53 lohmaier 2004-03-19 21:49:56 UTC
*** Issue 26750 has been marked as a duplicate of this issue. ***
Comment 54 rblackeagle 2004-03-20 14:34:35 UTC
To continue the conversation on 26750: To use "Right Page only" and "Left Page only" BOTH styles need to be defined and set with each one having as a "Next style" the other one. Then it works. Still, you're correct. There is no provision for "do not print blank pages" or avoiding extra blank sheets from printing when using one-sided copies. That is, as far as I can see, not a feature, but a bug. For submitting proposals to a publisher, I must print one-sided. I have to go through my document and remove the extra blank pages whenever I have to right pages following one another. However, in my case, the blank pages are numbered and it causes a problem as my publisher wants the pages numbered in order without blank pages being numbered. I also cannot add the normal rubric: "intenionally blank" to the blank pages. In fact, I cannot add anything at all to them.
Comment 55 emmajane 2004-03-20 18:11:11 UTC
I would recommend adding this feature/bug to the FAQ. I have personally "wasted" hours trying to figure it out, and I know that there are others on the Debian list who have also wasted a lot of time trying to prepare digital documents that are not traditional book formats with double-sided pages. As much as I love using OpenOffice, this is a massive show stopper for me. I will probably have to switch word processing programs until the problem is resolved. This is a major disappointment for me as OOo is one of the reasons I switched my laptop from Windows to Debian--I felt the applications were mature enough for me to be able to function in the (digital) business world. For additional comments on how OOo needs to behave for my specific case, please read: http://www.openoffice.org/issues/show_bug.cgi?id=26750 Thanks for your hard work to date, I look forward to the issue being resolved!!!
Comment 56 bettina.haberer 2004-04-08 21:07:32 UTC
Hello Andreas, do we have a chance to add some change here?
Comment 57 lohmaier 2004-04-21 17:33:05 UTC
*** Issue 28063 has been marked as a duplicate of this issue. ***
Comment 58 andreas.martens 2004-04-22 16:27:25 UTC
Comment 59 falko.tesch 2004-04-23 09:02:31 UTC
FT: Re-assigned due to wrong owner setting ;o)
Comment 60 andreas.martens 2004-04-27 16:05:54 UTC
No, we don't have the time to specify and implement this.
Comment 61 bettina.haberer 2004-07-07 15:49:28 UTC
This feature should be considered for OO.o later.
Comment 62 michael.ruess 2004-08-16 12:03:49 UTC
*** Issue 32880 has been marked as a duplicate of this issue. ***
Comment 63 sgautier.ooo 2004-09-07 11:31:33 UTC
reassigning & adding keywords according to new RFE process - Sophie
Comment 64 lohmaier 2004-10-09 19:53:14 UTC
*** Issue 35214 has been marked as a duplicate of this issue. ***
Comment 65 michael.ruess 2004-10-12 07:46:10 UTC
*** Issue 35340 has been marked as a duplicate of this issue. ***
Comment 66 swisher 2004-10-13 22:39:52 UTC
I agree that: --"Single-sided" layout should be the default behavior, such that blank pages do not need to be added. Users should have to actively choose to use book- style pagination, because most don't need it. --Even if you have a book-style document, you should have to actively choose to add blank pages. This is similar to an option in FrameMaker (a highly book- oriented program) that is something like "make sections end on even pages", and is turned off by default. In FM, the added pages are displayed in the normal document view, so they're not a print-time surprise. I would add that if the program does add blank pages, there should be a further option to use the appropriate page style to format them with normal headers and footers. This would make them look like part of the document rather than like a printer hiccup or a PDF botch.
Comment 67 dplevin 2004-10-27 22:02:53 UTC
I do duplex printing of huge documents and also make PDF copies. Here's how I would like to see things work: Under a page style tab (page or a new duplex tab): * add a setting (off, blank, page number, single-sided, style) that controls what kind of blank page, if any is inserted when the section has an odd number of pages: ** Off doesn't insert anything. ** Blank is a completely blank page with no text/headers/footers. Has an invisible page number and counts towards page counts. ** Single-sided is like Blank except that it does not have a page number and does not count towards page counts. ** Page number is like Blank but adds a next page blank notation to the page number field on the preceding page. ** Style - have a blank page style selector that lets you select a page style for the blank page. Along with this, a field to enter text for that page (This page intentionally left blank.) and associate it with a paragraph/character style. The above are all behaviors I've had to deal with. Often more than one in a single document. * A checkbox to enable editing blank pages. Or maybe not. * Controls to regulate simplex, duplex, printed thumbnail sheets (if any), and pdf handling of blank pages. Maybe duplex should default to document, but the others could be different. There should be individual settings for completely blank blank pages and blank pages with stuff on them. * Create a new category of pages styles for blank pages. * Don't forget that for RTL language layouts, the blank page can be a right page.
Comment 68 andreas.martens 2004-10-29 10:27:55 UTC
Hi dplevin, thanks for your ideas. I don't know what we will achieve in future, minimum will be the enabling/disabling of printing blank pages. But I like some of your ideas, e.g. a blank page style, too.
Comment 69 lohmaier 2005-03-09 14:07:26 UTC
*** Issue 44597 has been marked as a duplicate of this issue. ***
Comment 70 iannz 2005-04-06 10:13:36 UTC
My recommendation is to add a new "page layout" called "None" such that changing to a page style with a page layout of "None" never produces an odd page. I appreciate that this would mean a change to the API as the property "PageStyleLayout" of the service com.sun.star.style.PageProperties belongs to an enumeration (com.sun.star.style.PageStyleLayout) and enumerations are not supposed to change. To me this issue is sufficiently important to warrant a change to the API and it should happen before OOo2.0 is released. I like the idea of having a way of specifying what goes onto a blank page, for those styles with a page layout (i.e. all the current page layouts) that produce them, but see this as a lower priority. I am working on a wizard to make page numbering easier and this issue is a show stopper!
Comment 71 iannz 2005-04-06 10:17:09 UTC
My recommendation is to add a new "page layout" called "None" such that changing to a page style with a page layout of "None" never produces a **blank** page. Sorry - just reread what I had posted and realised that I had made a typo. Hope this makes my suggestion clearer.
Comment 72 swisher 2005-04-06 23:58:15 UTC
"None" does not seem like a good name for the new layout. It sounds like it has *no* layout at all, which makes no sense. Folks commenting on this issue seem to think that "single-sided" leads to confusion about how the document will be printed (e.g., you might want a "single-sided" layout but to print it duplex, or vice-versa). The key concept is that there should be a layout that is independent of the parity of the page number, in other words, not book-like. This will solve 90% of user complaints about this issue. I don't have any bright ideas for what name to call such a layout that will get that concept across. It could be named "default", as long as it were the default. The other 10% of us also want an option to suppress the insertion of blank pages (or one of the variations that have been suggested), even if we're using a book-oriented layout scheme.
Comment 73 michael.ruess 2005-05-19 11:21:22 UTC
*** Issue 49488 has been marked as a duplicate of this issue. ***
Comment 74 grsingleton 2005-05-19 13:01:59 UTC
Created attachment 26319 [details] mscro to delete empty pages.
Comment 75 grsingleton 2005-05-19 13:02:48 UTC
Found a macro that whlps to eliminate blank pages in a document. Attached
Comment 76 lohmaier 2005-06-05 20:52:29 UTC
*** Issue 50333 has been marked as a duplicate of this issue. ***
Comment 77 michael.ruess 2005-06-08 11:44:30 UTC
*** Issue 50477 has been marked as a duplicate of this issue. ***
Comment 78 lohmaier 2005-06-15 11:46:43 UTC
*** Issue 50743 has been marked as a duplicate of this issue. ***
Comment 79 h.ilter 2005-07-21 13:17:59 UTC
*** Issue 52250 has been marked as a duplicate of this issue. ***
Comment 80 michael.ruess 2005-08-10 11:19:30 UTC
*** Issue 53118 has been marked as a duplicate of this issue. ***
Comment 81 Regina Henschel 2005-09-09 10:12:12 UTC
*** Issue 54387 has been marked as a duplicate of this issue. ***
Comment 82 neiljp 2005-09-15 17:07:02 UTC
Having just bumped into this bug (not a feature as it stands IMO), I'm quite shocked that this problem remains - or maybe people just do not use multiple sections in most documents (probably a bad thing). This may be a stupid question, but what would be wrong with simply having an option for each page layout (ie. per section, AIUI) which specified whether it should be pushed forward to an odd-numbered (or even numbered...or...) page, if the print settings are set to duplex. Perhaps call it something like 'with duplex printing force section start to [odd-numbered page|even-numbered page]' ? Regarding a workaround fix, I have to agree with other comments that simplex is more common than duplex and thus should be the default - ie. just remove the 'extra pages' functionality until a proper solution is present. If I had any say in this, I would say this should be fixed for OOo2, but I'm sure its too late now :( Regarding a permanent fix, I am aware that there are UI issues with how to present simplex vs duplex, ie. if page numbers shift with duplex printing. The best option off the top of my head would seem to be to add a 'document' option (dialog) to the 'format' menu, which included an option to specify whether it is a duplex document. I'm sure there are other option whole-document options (or if they are elsewhere, perhaps they could be in the same place). If the whole duplex/simplex issue is being discussed somewhere else, or should be, please let me know.
Comment 83 lohmaier 2005-09-15 23:14:15 UTC
*** Issue 19415 has been marked as a duplicate of this issue. ***
Comment 84 dplevin 2005-09-22 15:57:04 UTC
I just thought of something else. We need to make the distinction between automatic and manual duplexing. Automatic duplexing is where the printer automatically prints both sides of the page. Assuming that the printer is smart enough to handle successive odd pages. Manual duplexing is where you print a stack of odd pages, flip the stack over, reload it into the printer, and print the even pages on the back. When you do this, you *don't* want to skip the blank pages because then the even pages get out of sync with the odd pages on the front. Manual duplexing is a royal PITA, but most low-end printers don't do automatic duplexing. All of our B&W printers automatically duplex, but our color one doesn't. So the defaults should be: Don't print blank pages: simplex, automatic duplex, PDF. Print blank pages: manual duplex. Provide a manual override.
Comment 85 michael.ruess 2005-10-26 08:50:22 UTC
*** Issue 56670 has been marked as a duplicate of this issue. ***
Comment 86 michael.ruess 2005-12-20 12:22:32 UTC
A feature regarding this issue will be implemented into OO 2.0.2. See spec http://specs.openoffice.org/writer/printing/suppress-empty-pages-specification.odt.
Comment 87 jimmyh 2005-12-20 12:28:40 UTC
FYI, The link in the previous post has the Content-type incorrectly set to text/plain for the ODF file. We should probably have this mime type set properly on an openoffice.org server!
Comment 88 swisher 2005-12-20 17:52:03 UTC
I'm happy to see the spec for a feature to address this issue. Thanks very much! I would prefer that the fundamental assumption about left/right pages were addressed, but that is too fundamental to address in an incremental release. Unfortunately, this feature seems to be defined backwards. The feature is an option represented by a checkbox. The label for the checkbox is "Print automatically inserted blank pages". The behavior defined in the spec is that if the option is ON, the automatically-inserted blank pages are NOT printed, and if it is OFF, those pages ARE printed. I would expect that if I check (or tick) a checkbox with that label, the pages *would* be printed (as the label says), and if I clear the checkbox, the pages would *not* be printed. Therefore, the "Behavior of PA" in the spec should be changed: * If switched *on*, automatically inserted blank pages are printed. * If switched *off*, automatically inserted blank pages are *not* printed. The default value of the option should be OFF, i.e, not printing the extra pages. Printing the extra pages is the behavior that has led to so many issues being submitted about this, so that's what we want to turn off by default. Please do not correct this mismatch by changing the label instead of the behavior. UI labels should be stated positively, so that selecting the option means "do it", and clearing the option means "don't do it".
Comment 89 dplevin 2005-12-30 20:29:55 UTC
I second everything that swisher said. I'd like to see a third option for this setting: Auto The "Auto" setting automatically detects whether simplex or duplex/booklet is selected and behaves as follows: Simplex -> blank page disabled, Duplex/Booklet -> blank page enabled. "Auto" should be the default. The "On" and "Off" settings then become manual overrides for special cases. With "Auto", you don't have to remember to change Yet Another setting when switching between simplex and duplex.
Comment 90 stefan.baltzer 2006-02-02 13:44:49 UTC
SBA: Given the fact that there has been some changes (see URL above), I think it is time to close this issue (that became a book in the meantime, well on its way to top issue 1820 :-)... I propose to close this one and write a new issue for the "remaining dreams". NO ONE will ever take the time to read such a lenghty issue thoroughly. Main reason: This is already partly solved (for OOo 2.02)
Comment 91 lohmaier 2006-02-02 23:09:54 UTC
Agreed. The main issue is fixed. For remaining things seperate issues should be filed.
Comment 92 lohmaier 2006-02-02 23:11:08 UTC
fix already included in a current milestone â†’ closing.
Comment 93 lohmaier 2006-03-18 13:57:24 UTC
*** Issue 63332 has been marked as a duplicate of this issue. ***
Comment 94 Regina Henschel 2006-07-10 13:57:22 UTC
*** Issue 67174 has been marked as a duplicate of this issue. ***
Comment 95 michael.ruess 2006-07-17 14:16:03 UTC
*** Issue 67451 has been marked as a duplicate of this issue. ***
Comment 96 lohmaier 2006-10-19 20:01:18 UTC
*** Issue 70590 has been marked as a duplicate of this issue. ***
Comment 97 michael.ruess 2006-11-07 15:32:13 UTC
*** Issue 71296 has been marked as a duplicate of this issue. ***
Comment 98 lohmaier 2006-11-08 19:05:50 UTC
*** Issue 71356 has been marked as a duplicate of this issue. ***
Comment 99 eric.savary 2007-07-24 10:57:07 UTC
*** Issue 78401 has been marked as a duplicate of this issue. ***