qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

-----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-----