| Summary: | Remove excessive whitespace when printing | ||
|---|---|---|---|
| Product: | [Applications] okular | Reporter: | Gabriel Ambuehl <gabriel_ambuehl> |
| Component: | general | Assignee: | Okular developers <okular-devel> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | dennis.jansen, pawelk, vito.detullio |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Gabriel Ambuehl
2006-11-02 10:36:28 UTC
I don't get your point ... what's the reason for enlarging the text part of a scientific journal text (and thus using more ink/toner)? I don't really think you could then put more real "text" on a page... AFAIC, I really like those "useless" borders for writing annotations and comments directly beneath the paragraph that spurred them... Reassigning to the mailing list See also kpdf bug 115557 about removing useless borders on-screen. Should that bug be duplicated or moved to okular? @kde2eran: if you understand the difference between "screen" and "printing", then the reply is no, they are different. @pino: I asked if bug 115557, on removing borders when *viewing in KPDF*, should be duplicated or reassigned to cover *viewing in Okular*. By the way, the PDF bounding box can be calculated using $ ghostscript -DBATCH -DNOPAUSE -DPARANOIDSAFER -DQUIET -sDEVICE=bbox -r15x15 file.pdf @kde2eran:
I don't want to mix *KPDF* and *Okular* bugs.
> By the way, the PDF bounding box can be calculated using ...
Portable solution, I see...
@pino: OK, then I'll duplicate that bug for Okular. Of course running GhostScript is not a solution for Okular, but if someone wants to implements a portable solution, maybe looking at GhostScript's code will help. > By the way, the PDF bounding box can be calculated using
> $ ghostscript -DBATCH -DNOPAUSE -DPARANOIDSAFER -DQUIET -sDEVICE=bbox
> -r15x15 file.pdf
This is what pdfcrop does (in conjunction with LaTeX to rebuild pages). It
does not work with all PDF though, sometimes it creates a horrible mess...
The patch in bug 161599 (on removing borders when *viewing*) has simple code for computing the bounding box by scanning the pixmap for white pixels. It will be also useful for me to manually select which part of page is interesting and should be printed (in magazines distributed via PDF there often are some unimportant marks near edges of page). kde2eran: now that we have a "trim" button for *viewing*, it's possible to apply this also to printing? Are the 2 problems so different? (In reply to comment #11) > now that we have a "trim" button for *viewing*, it's possible to > apply this also to printing? It is not possible to apply for priting the way used for viewing, sorry. > Are the 2 problems so different? Yes. *** Bug 187531 has been marked as a duplicate of this bug. *** |