-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, all this rounding begins to be complicated...
On 23.06.2012 20:50, Andi Șerbănescu wrote: >> It currently scrolls to the nearest pixel in the middle of the >> gap. One can do either thing: The beginning of the gap hence >> scrollbar (previous page might be visible) or lower inside the or >> a the top of the page. (scroll bar will not be at the minimum). > ======================================================================== > > Hmmm… The stable version scrolls to the top the page (skipping the gap > entirely), but without wiggling. Yes, the stable version skips directly to the top of the page. (So the scroll bar is not at the minimum.) The future branch does the same now. It wiggles less because it always rounds up the bounding rectangles of the pages which is also where the one-pixel-too-much comes from. The future branch does not do this, yet. So more rounding takes place. It probably will do so because painting outside the bounding rectangle produces rendering artifacts. (Don't know if you have seen them yet, I have. Mostly when zooming out.) > I'd like either that, either the beginning of the gap. And the > latter runs the risk of showing a little of the previous page, so… > > My question, though, was whether increasing the gap between pages > would prevent the bottom of the previous page from showing (in case > we'd start from the beginning of the gap). I guess not… Yes, that would not change it in any way. > The wiggling mysteriously seems to have gone away, however. As it is a rounding effect, it is quite unpredictable and depends intricately on the window size, page size and so on. Sometimes it is there, sometimes not. >> As I said: The borders are 5 pixel in all direction but there is >> only one border in between pages, i.e. vertically and >> horizontically in two pages mode. Hence the gaps are always 5 >> pixel long. > > My mistake. The sides are double only in case of fit-to-width. > This was apparently so, because the visible width the fitting calculated with was wrong. It was too small, so the borders where the same but the page just was not large enough. When the fit is too tight, one will get a horizontal scrollbar even though it isn't necessary. I checked the Qt source code and compared how they fit in a QGraphicsView: they use the viewport rectangle (so did I) and a margin of 4 (so did I, still getting a scroll bar). This is because a scene rect of e.g. width 985.5 will give a scrollable length of 986. So now I use a margin of 6 to account for the two pixel possible rounding error and it seems to work as expected. (Though not perfectly symmetrical to the pixel, but still better.) I also changed this in stable. Would be nice if you could test this in both versions and check that you never get an active scroll bar when fitting. (The vertical one will of course be always visible.) Giving me a heads up on this before tomorrow's release would be gladly appreciated. Best regards, Adam. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP5h0NAAoJEPSSjE3STU342r0IAIWQbdG7vnWT8JVp4+Y1hu+9 A6guPbZHFZE/zJMfqV+WsXpFYtJs5W3eSw15z0Bs/4zWpl3y8YbYb6T4ndhpk6LQ oXiM1IcgJKEjipgI0kBfId7kywKedMCxTUZnDeb1TpIa4xJdbGRpM58M6H5JNivF A7E8mKvCCEGPembp73NLPtDl1uneYWOAS79m+eikzbu/02lfkr4XlE/pGhS2xKo2 zhnuM6l+KPqakz0h7v00gCvjimYEtJKI6uYX+Z5+jtDSdtqHUrZuhQBywJIRwqXM 62NtUwXZLQGHkUrSpd+gPgygpe0cLHN/R4gKpjYjRgfv6oq5aQQea2kq0yootFo= =VXnP -----END PGP SIGNATURE----- -- Mailing list: https://launchpad.net/~qpdfview Post to : [email protected] Unsubscribe : https://launchpad.net/~qpdfview More help : https://help.launchpad.net/ListHelp
