Bug 241490

Summary:	'facing pages' view mode produces inaesthetic variable space between pages
Product:	[Applications] okular	Reporter:	James Fisher <jameshfisher>
Component:	general	Assignee:	Okular developers <okular-devel>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	michaels_1984, modulistic
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:	4.8.0
Sentry Crash Report:

Description James Fisher 2010-06-12 02:19:57 UTC

Version: unspecified
OS: Linux

The "dual" view mode in Okular is, presumably, meant to emulate the layout of a physical book. On this assumption, the positioning of the pages within the window is currently done poorly. There is always space between the pages (this gets smaller, but never disappears, as you zoom in), where in a book there is none. Worse than the fact that there is space between the pages is that this space is variable, changing the composition as one zooms. Even worse is that, when zooming out sufficiently, any one page is 'closer' to the pages "above" and "below" than it is to its facing page, meaning that the the natural way in which the eye groups the pages (as two vertical columns) is different to their natural grouping in a book (as pairs of facing pages).

It may seem pedantic, but this current logic for placing pages destroys any design of the facing pages. For example, the http://en.wikipedia.org/wiki/Canons_of_page_construction are based on the assumption that the two facing pages are touching. This is not to mention such things as carefully-designed two-page spreads -- in this case Okular effectively chops someone's artwork in half.

The pages should in fact be displayed as touching in the gutter. This is the approach taken by Adobe Reader, for example.

For my part, I suggest that the pages are displayed literally pixel-to-pixel, and that their visual separation into pages is done by altering the lightnesses of the two touching columns of pixels. For example, one column of pixels could be made 20% darker, and the other could be made 20% lighter, giving the impression of a groove in the page.

Reproducible: Always

Comment 1 modulistic 2010-07-14 12:39:34 UTC

I agree with James here.

There is no such a thing as a perfect default because documents vary greatly; some include crop marks, and I even have a (badly scanned) book that has different sizes for facing pages... but I would suggest this solution:

* Adding a checkbox just below "Center first page" that reads "Remove gap between facing pages", under Settings > Configure > General
* Also I would vote for both of these checkboxes to ship in a checked state by default, as suggested in bug #228971

Comment 2 James Fisher 2010-07-14 13:43:47 UTC

@modulistic: I would personally make a stronger case, namely that the 'separate pages' view should be entirely replaced by 'touching'.  I'm not convinced there's any use-case whatsoever for the current way of displaying pages.

If there is a use-case, then I the checkbox should read "add gap between facing pages" rather than "remove", and should ship in an unchecked state.

I think your suggested phrase makes "touching pages" sound like a "feature," whereas AFAICT it would actually be simpler to implement than the current logic.

Thanks for the support, though. :)

Comment 3 modulistic 2010-08-10 12:29:11 UTC

(In reply to comment #2)
I fully agree.

Comment 4 Michael 2010-11-21 00:24:15 UTC

I also agree with the above comments. 

Personally, I think it is natural to expect in the "facing pages" view a reading experience similar to a book, meaning two pages right next to each other, with no gap, regardless of the zoom value. 

Since I do not know (but correct me, if I am wrong) any use case where the current behavior (as of version 0.11.1), i.e an enlarging gap while zooming out, is desired, I suggest to change the default behavior of the "facing pages" view and to avoid another possibly confusing option in the settings.

Nevertheless, many thanks to the developers for this great piece of software.

Comment 5 Albert Astals Cid 2011-12-04 11:46:37 UTC

Should be there in KDE 4.8.0 if the behaviour still does not fit what you want please open a new bug explaining exactly what and why you think a change should be applied