Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Enable the user to avoid empty pages being created/printed | ||
---|---|---|---|
Product: | Writer | Reporter: | lohmaier |
Component: | formatting | Assignee: | requirements <requirements> |
Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> |
Severity: | Trivial | ||
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 |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Attachments: |
Description
lohmaier
2002-04-07 14:11:07 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 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. Forgot to mention that my platform is Windows2000. Thanks for your comment, Florian. Since you're using Windows and I linux, I set the os to All. 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. 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. 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. > 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? Removed ooo1.0 keyword in respect to Andreas comment. 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. 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. 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. 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. Created attachment 2605 [details]
image showing page/print preview
Created attachment 2606 [details]
image showing the setting for left/right layout of a page-template
Created attachment 2607 [details]
image showing how to the the following template
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. *** Issue 7913 has been marked as a duplicate of this issue. *** (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. 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. *** Issue 5906 has been marked as a duplicate of this issue. *** 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. *** Issue 10417 has been marked as a duplicate of this issue. *** *** Issue 11597 has been marked as a duplicate of this issue. *** *** Issue 12038 has been marked as a duplicate of this issue. *** *** Issue 13787 has been marked as a duplicate of this issue. *** 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. time for a target... Not possible before OOo 2.0. *** Issue 15431 has been marked as a duplicate of this issue. *** *** Issue 15418 has been marked as a duplicate of this issue. *** *** Issue 16188 has been marked as a duplicate of this issue. *** 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 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). 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. 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. 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. 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. 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 *** Issue 3142 has been marked as a duplicate of this issue. *** <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. 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. To summarize it: Req. A: avoid empty pages beeing printed/exported Req. B: avoid empty pages beeing created 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. 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?
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. 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." *** Issue 18654 has been marked as a duplicate of this issue. *** *** Issue 19138 has been marked as a duplicate of this issue. *** *** Issue 19139 has been marked as a duplicate of this issue. *** *** Issue 25224 has been marked as a duplicate of this issue. *** *** Issue 26502 has been marked as a duplicate of this issue. *** *** Issue 26750 has been marked as a duplicate of this issue. *** 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. 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!!! Hello Andreas, do we have a chance to add some change here? *** Issue 28063 has been marked as a duplicate of this issue. *** See attachment FT: Re-assigned due to wrong owner setting ;o) No, we don't have the time to specify and implement this. This feature should be considered for OO.o later. *** Issue 32880 has been marked as a duplicate of this issue. *** reassigning & adding keywords according to new RFE process - Sophie *** Issue 35214 has been marked as a duplicate of this issue. *** *** Issue 35340 has been marked as a duplicate of this issue. *** 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. 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. 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. *** Issue 44597 has been marked as a duplicate of this issue. *** 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! 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. "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. *** Issue 49488 has been marked as a duplicate of this issue. *** Created attachment 26319 [details]
mscro to delete empty pages.
Found a macro that whlps to eliminate blank pages in a document. Attached *** Issue 50333 has been marked as a duplicate of this issue. *** *** Issue 50477 has been marked as a duplicate of this issue. *** *** Issue 50743 has been marked as a duplicate of this issue. *** *** Issue 52250 has been marked as a duplicate of this issue. *** *** Issue 53118 has been marked as a duplicate of this issue. *** *** Issue 54387 has been marked as a duplicate of this issue. *** 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. *** Issue 19415 has been marked as a duplicate of this issue. *** 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. *** Issue 56670 has been marked as a duplicate of this issue. *** 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. 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! 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". 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. 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) Agreed. The main issue is fixed. For remaining things seperate issues should be filed. fix already included in a current milestone → closing. *** Issue 63332 has been marked as a duplicate of this issue. *** *** Issue 67174 has been marked as a duplicate of this issue. *** *** Issue 67451 has been marked as a duplicate of this issue. *** *** Issue 70590 has been marked as a duplicate of this issue. *** *** Issue 71296 has been marked as a duplicate of this issue. *** *** Issue 71356 has been marked as a duplicate of this issue. *** *** Issue 78401 has been marked as a duplicate of this issue. *** *** Issue 83320 has been marked as a duplicate of this issue. *** |