[Kde-print-devel] [Bug 103666] [KDE4] facilitate margin adjustment for double-sided printing

[Kurt Bennater]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=103666         




------- Additional Comments From curdy schlundmail net  2007-01-14 20:42 -------
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?