Bug 103666

Trust me, this is pretty much impossible to implement on the PostScript level. There are far too many incompatible PS files out there (incompatible to the "Document Structuring Conventions") and no program can do this n-upping with margin adjustment on PS source code level.

Even worse it is if you have to deal with "formatted differently" files which possibly originate from different programs.

The way to go is doing that in PDF (after conversion from PS). I recommend you to do this even now, for your commandline fiddling. Have a look at "pdftk"...

Note, your $summary very much differs from the content of your wish. Double sided printing and "number-up" layouting are quite some different things. I assume you did not mean to talk about "image shifting" for duplex printing (where front and back page are shifted by different amounts into different directions possibly)?

Cheers

Thanks a lot for the answer. My fault, I know now that 2-up printing was what I meant when I wrote this bug report :) . I was thinking of some kind of thumbnail preview in kprinter which would allow for clicking into it and pulling up some rectangle which would be the part of the page that is actually printed. Kprinter could internally call pstops (from psutils) with the parameters obtained this way. This could work with 1-up and also if you additionally choose 2-up printing.

In the meantime, I found a solution for DSC conforming PS files: I use a customized version of the perl script impose by Dov Grobgeld (http://www.ctan.org/tex-archive/support/impose/) which automatically detects the bounding box and calls pstops for 2-up printing. I wrote a filter for kdeprint; this makes it already quite comfortable.

However, the option to draw the bounding box to be used for resizing would still be great since automatic detection does not work with, e.g., scanned texts (which are quite common in scientific archives) and some PDF files.

It's extremely difficult to "edit" PostScript files visually, even if it is only for scaling... In any case, this is out of scope for KDEPrint. KDEPrint does not do *anything* to the files itself; it only calls external programs and utilities, and lets the user GUI-configure the parameters for running these utilities.

In the KDE 3.5.x lifetime nothing fundamental will change here in any case. For KDE 4.x we'll have to see. People with skills and time and love to look after this "boring" printing stuff are rare -- and they are also rare inside KDE. So it is not ruled out that we have lots of nice discussions and many pretty feature requests and nasty bug reports, but not much will change for printing when shiny new KDE 4.0 is out.

I'll close this bug now as a duplicate of bug 107936 (and many others) which also discusses number-up printing, print previews etc.

See also the detailed hints+screenshots about a few of the "pre-filters" which can be run by KDEPrint over at bug 107936 and at bug 82123.

Please transfer your votes if you care. Continue discussion at bug 107936. Thank you.

*** This bug has been marked as a duplicate of 107936 ***

Dear Kurt.

I saw that you have been closing a lot of bugs all concerning n-up printing and I really don't want to get on your nerves. But I can't help saying that I don't see any resemblance of bug 103666 to bug 107936 apart from both dealing with n-up printing. My wish should also have an effect for 1-up, and I was NOT talking of editing Postscript files at all.

Perhaps I did not explain this well: Drawing a bounding box should not mean that the original postscript file be changed. Equally well you could click twice into a preview of the page, once in order to determine the upper left and once for the lower right corner - only as a means to find out the coordinates of the text part of the page to be printed. This is sensible when there is a very large white space border around the text in the orginal postscript file which leads to a lot of white space between the two pages for 2-up, e.g. (In some cases, I get postscript files which are so badly formatted that only a third of a page is actually text, the rest is empty.)

This information can be used to offset and resize the page with pstops in such a way that the mentioned rectangle fits a given (normalized) rectangle on the page to be printed. E.g., the "normalized rectangle" could be of the size of an A4 page minus some border width (in the case of 1-up) or of the size of half an A4 page minus some border width (in the case of 2-up, here pstops would have to rotate the two pages and resize them). The result is an output where the amount of white space (border) has been reduced to a normalized size - without editing the original postscript file.

Please have a look at the perl script impose which I mentioned in my previous post. It includes the resizing step - but only works if determining the text area automatically works out fine.

For the other cases (where this automatic step fails, e.g., for scanned documents), one could use exactly the same (simple) algorithm to find the pstops arguments from the rectangle drawn by the user. All KPrinter has to do is to offer a preview, the option to draw the rectangle around the text and to pass its coordinates to a modified version of the perl script.

So can we please reopen this bug?

    "So can we please reopen this bug?"

No.

But patches are welcome.

Closing old Resolved status bug.