| Summary: | "Trim Margins" cuts too much | ||
|---|---|---|---|
| Product: | [Applications] okular | Reporter: | Alexander Potashev <aspotashev> |
| Component: | DjVu backend | Assignee: | Okular developers <okular-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | auxsvr, creichert07, fabiodurso, hhielscher, kollix |
| Priority: | NOR | ||
| Version: | 0.11.2 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/okular/5b12bf685df1c02be025cdb870f97df62da72b09 | Version Fixed In: | 4.9.0 |
| Sentry Crash Report: | |||
| Attachments: |
"Trim Margins" disabled
"Trim Margins" enabled Title page with trimmed margins on 0.12.2 |
||
|
Description
Alexander Potashev
2010-11-19 23:42:46 UTC
Created attachment 53564 [details]
"Trim Margins" disabled
Created attachment 53565 [details]
"Trim Margins" enabled
I cannot reproduce this in 0.12.2 or 0.12.8. Can anyone else reproduce this behavior? Created attachment 61813 [details]
Title page with trimmed margins on 0.12.2
In 0.12.2, second and subsequent pages look fine with margins trimmed (hardly any difference from no trim, actually), but the front page gets part of the title cut off (attached).
The "trim margins" feature in okular worked find until KDE 4.7. In KDE 4.8, pdf documents sometimes have too much of the page trimmed, some pages are incorrectly left intact, and it is very likely that the page in focus when the feature is turned on will be excessively trimmed. Also, the algorithm for trimming has become unstable, i.e. reloading the same file will often leave different areas of a page trimmed. If the page is resized only once after "trim margins" is activated, then trimming is successful, otherwise it fails and the process takes longer to complete. *** Bug 292680 has been marked as a duplicate of this bug. *** *** Bug 303622 has been marked as a duplicate of this bug. *** Git commit edbb4ef9f5aa8f120558b9d4f4b9f68970100c4b by Fabio D'Urso. Committed on 17/07/2012 at 20:35. Pushed by fabiod into branch 'KDE/4.9'. Call Generator::signalPixmapRequestDone _after_ saving the calculated bounding box Fixes a bug that causes the extraction of a wrong bounding box: If the request queue is not empty, signalPixmapRequestDone causes a new pixmap request to be started, thus overwriting mPixmapGenerationThread's mCalcBoundingBox before it is read by the if in the next line. Now signalPixmapRequestDone is called after the bounding box is saved, so that new requests are started only after all data from mPixmapGenerationThread have been saved. REVIEW: 105600 M +1 -1 core/generator.cpp http://commits.kde.org/okular/edbb4ef9f5aa8f120558b9d4f4b9f68970100c4b Git commit 5b12bf685df1c02be025cdb870f97df62da72b09 by Fabio D'Urso. Committed on 17/07/2012 at 20:35. Pushed by fabiod into branch 'master'. Call Generator::signalPixmapRequestDone _after_ saving the calculated bounding box Fixes a bug that causes the extraction of a wrong bounding box: If the request queue is not empty, signalPixmapRequestDone causes a new pixmap request to be started, thus overwriting mPixmapGenerationThread's mCalcBoundingBox before it is read by the if in the next line. Now signalPixmapRequestDone is called after the bounding box is saved, so that new requests are started only after all data from mPixmapGenerationThread have been saved. REVIEW: 105600 M +1 -1 core/generator.cpp http://commits.kde.org/okular/5b12bf685df1c02be025cdb870f97df62da72b09 |