Multipage printing issue using even and odd.

Thank you for your bug. The description is not clear, could you attach an example to the bug?

when you want to print a document saving paper, you would print more pages on a single sheet.
This works good, but:

If you want to save more paper, you would print on both sides of the sheet. It's impossible to do that because the print setup allow only "even and odd" pages and not "even and odd" sheets. For a single page sheet, there are no differences.
Got it?

Thank you for the time!

The "Page Setup" dialog has a "Two-sided" option, isn't that doing what you want?

Two sided options doesn't work well. Because print only even or odd pages not sheets. Try to print a document using more pages for sheet and two sided.

could you attach an example? the difference between page and sheet is not clear

I think I understand the nature of this bug, having just encountered it myself.

The process I went through is as follows:

1. I have a large PDF file that I want to print. The text is large, and I want to save paper.
2. I decided that I wanted to scale the pages so that two (document) pages are on each side of paper.
3. Furthermore I want to print on both sides of each sheet of paper.
4. My printer doesn't support duplexing (which I assume is what the two-sided option is for).

The natural thing to do is to select:
+ "Pages per sheet": 2
+ "Only print": "Odd sheets"

Then print, and reload the paper into the printer, then select:
+ "Pages per sheet": 2
+ "Only print": "Even sheets"

I expect this to give an result where the first sheet has (document) pages 1&2 on it, and it's reverse has 3&4, and so on.
This seems sensible given the distinction in terminology in the dialog box between pages and sheets.

The actual result is that the first sheet has pages 1&3 on it, and on it's reverse are pages 2&4. I can't see how this is useful for anyone. It doesn't even fold into a booklet or the like.

I think it should also be noted that the diagram showing the page format is not very helpful when you're trying to do this sort of thing. It could be made much better.

Got perfectly the problem.

I believe that the problem lies with the postscript filters getting applied in the wrong order. This is a very serious issue, at least it sure is for me since I rely on this feature a lot to save paper.

I see this bug is still marked as need info. Peter Russel seems to describe the issue clearly, and I also just ran into the same issue trying to print a long document using pages per sheet = 2. I want to print on both sides of the paper using a printer that doesn't support duplex printing.

Using the definitions as:

Page: logical page as defined in the document
Sheet: physical piece of paper as loaded in the printer

If I have an 8 page document that I want to print using 2 sheets, I want:

Pages per sheet": 2

Then selecting

+ "Pages per sheet": 2
+ "Only print": "Odd sheets"

I expect page 1 & page 2 to be printed on sheet 1, page 5 & 6 to be printed on sheet2. Now I turn the sheets upside down and reload them in the printer, and select:

+ "Pages per sheet": 2
+ "Only print": "Even sheets"

I expect page 3&4 on sheet 1 and page 7&8 on sheet 2.

Is there anything else that can be clarified?

Please, I don't want rumours that Ubuntu users needlessly kill trees because of deficient two-sided printing support to start spreading ;-)

Regards
Neilen

I'm facing the same issue.

The expectation is that selecting "pages per sheet: 2" and "odd pages" will print pages 1+2, 5+6 on two sheets. If I then select "even pages" it should print pages 3+4 and 7+8.

So the expected order is that the printer driver (or whatever is processing the data, cups, gnome, evince...) should first group two pages into every sheet, then print either even or odd sheets.

Instead, the order of operations is reversed: the driver first filters only the odd pages, and then puts two of them onto each sheet to print, which is unlike what probably every operating system out there does. (Reversing the order of these two operations is probably all it takes to fix this, but I don't know the source code details...)

I think this bug should have a higher priority, too, as it probably affects many users with average home machines + printers.

If you try to save ink, or simply for convenience, you print 2up, and if your printer doesn't do duplex, but you want paper printed on both sides, then you first print odd pages, re-insert the paper into the printer feed, and then print even pages. Result: four pages per sheet, in the expected order (1+2, 3+4).

Just stumbled across this problem (and report / discussion thread) myself...

Nothing to add on the problem description, previous posters have done an excellent job of explaining their usage pattern and Evince's behavior. Looking forward to a fix...

In the meantime, here's a workaround for those interested (and apologies if this is not the right forum to post this info... but it related directly to the problem...):

- get 'page-crunch' (use Synaptic or apt-get install page-crunch). This is a GUI frontend for a suite of PostScript document formatting utilities. The tool apparently handles PDF too.
- Export the source document (e.g. OpenOffice) to PDF as you otherwise would to print it with Evince
- start page-crunch (alt-F2, 'page-crunch'). Open the PDF file from the previous step. Select a name for the reformatted output file (also PDF). Select "pages per sheet = 2", and other parameters as desired (esp. paper size is A4 by default). Click "See". It may complain about not finding xpdf... just click 'Ok' to ignore the error.

Open the reformatted version of your PDF in Evince. Now each page of the new document contains 2 pages of the original document. So you leave Pages per Sheet = 1 under Page Setup. If you now print odd pages (i.e. "Odd Sheets"), flip and reload the stack of paper, and print even pages, you get the 2-up, 2-sided printout as desired.

I haven't tried, but presumably this will work for any number of pages per sheet.

Just to point out that this bug still exists in Gutsy. Is there any movement on this?

this bug is no longer getting any attention, imo its severity should be set to something higher than "low": what's worse this affects other applications as well since unless i'm mistaken evince relies on gnome-print to do its thing

the issue is a lack of manpower, changing the setting will not really do a difference there. Having a bug assigned to the wrong place with quite some comments and not a clear description doesn't make the bug easier to read either

solve this problem should take a small amount of time for a skilled developer, think you description is not enought?

dunno, I've lot to do, doesn't know about printing and have no working printer to work on that right now and looks like nobody else seems interested in working on this bug, I'm happy to look to contribution from anybody wanting to give an hand to fix this bug though

I would be interested in working on this bug, however, I am new to development in Ubuntu. I am experienced in software development. I am eager to contribute, so if you could mentor me I would be willing to fix this bug.

do you have any specific question on where to start? the issue is likely an evince or gtk one, would be useful to look on whether other software have the same issue and if that's specific to some configurations then looking at the gtkprint or evince code using a debugger and trying doing changes there

Thanks, that is helpful to know what code to begin looking at. I do have another question on where to start...where do I get the code so I can debug?

you can look to https://wiki.ubuntu.com/ContributeToUbuntu which has documentations or use apt-get source to get sources

Thanks! I was able to get the source, compile it, and get it running in a debugger. It took quite a bit of work being new to this. One problem I am having in my debug version is the ability to open any type of document. If you've got any suggestions off the top of your head I would appreciate it.

not sure to understand the question, what document do you want to open and what is not working?

Sorry, I didn't explain that well. What I am trying to do is open a pdf document, or any document for that matter, in my build of evince. The problem is that I get a mime type error when trying to open a document. I obviously missed something somewhere but I am not sure what. Any ideas?

not really, how do you run evince?

What I did was downloaded the source files, ran the configure & make (actually make install too), and then executed the binary. Not sure if doing the make install was the best option, but I did it anyway so I could launch the evince I built. Evince launches fine, but it does not seem to be able to open files. If I have the wrong approach here, let me know. My thoughts were to reproduce the problem on my machine (which I did), then get the source code and start learning how it works to see where I might make any changes to fix the bug.

you should rather build a deb and install it, the installation to local should work though

Well, I think I was making it more difficult than it was. I wasn't thinking about attaching the debugger to the currently installed evince on my system. Thanks again. I'll see what I can do here.

To me this looks like a problem with the gtk print dialog, reassigning.

I got the same problem as well ... Hardy AMD64

I used the page crunch (which looks like an old old program !!) and it worked fine.

You need XPDF installed to "see" in page-crunch.
I did not find any "Do It" button on Page-crunch. So just use "see" button and the file gets created.

Printing Issues may not be mainstream for the developer/coder but is quite an issue for the average "windozezzzzzz...." guy. So someone pls take note (eg. people who sing paeans to ubuntu at every forum) .

As for me I am a newly converted fellow, less endowed with the cerebral equipment. However still would like to help. If someone can cut up the work - i am willing to fill out the details.

FYI, just checked the ibex daily cd image and the bug is still there

This is an upstream bug of the CUPS filters. It really does not make sense to apply even/odd selection before N-up. It should go the other way around, as even/odd is only used for manual duplex.

Problem is in evince/GTK print), as printing a PDF file from the command line on Hardy

lpr -P PDF -o page-set=even -o number-up=2 manypages.pdf

gives the expected result: 3, 4, 7, 8, 11, 12, ...

(use another printer name if you do not have a PDF print queue)

The above-mentioned command line gives also the correct result on Intrepid now (cups_1.3.8-13).

The problem of evince is that it only sends the even pages to CUPS and lets CUPS then do the N-up. It should send all pages and supply the page-set=even option to the job, so that CUPS removes the odd pages AFTER applying N-up. Or evince should do both the page selection and N-up by itself.

The bug is in evince I believe and not in the gtk printing interface. Printing 2 pages per sheet, odd sheets works correctly from firefox 3. (eg. for this page, 13 a4 pages: {1,2},{5,6}{9.10},{13} )

So what's the decision on this bug? It's still an issue in 9.04. Is it an evince problem or is it really a gtk+ problem despite firefox printing correctly?

This isn't the good way to close bugs.
This bug is stille here.

Reposting here my post to the gnome bug but as a patch against evince 2.26.1-0ubuntu1

I have a really simple fix for this. In export_print_page in
ev-print-operation.c:

REPLACE:

while ((export->page_set == GTK_PAGE_SET_EVEN && export->page % 2 == 0) ||
(export->page_set == GTK_PAGE_SET_ODD && export->page % 2 == 1));

WITH:

while((export->page_set == GTK_PAGE_SET_EVEN && (export->page /
export->pages_per_sheet) % 2 == 0) ||
(export->page_set == GTK_PAGE_SET_ODD && (export->page /
export->pages_per_sheet) % 2 == 1));

This way we check for even/odd sheets rather than pages in doing the pagination
and nothing else has to be changed in the code.

ISSUES:
Is the integer division guaranteed portable?
Is pages_per_sheet guaranteed to be non-zero?
Will this interfere with duplex printing if the hardware supports native
duplex?

argh... i meant "export_print_inc_page", of course

My patch has been accepted upstream. How can I help in making the changes to the 2.26 gnome branch propagate to a new deb into our repos?

I have a problem with printing this document.

http://cocosci.berkeley.edu/tom/papers/ncrp.pdf

Evince cannot print it on odd/even pages plus it brakes down at page 122.
Interestingly not only evince but okular is the same so I suspect this is a bug of the libpoppler (again).

Lev