qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On 08.05.2012 17:15, Andi Șerbănescu wrote:
> Hello,
> 
> I've checked it out (I wrote an ebuild if anyone's interested). Bad
> news first.

If it simplifies testing for Gentoo users, why not post it to the
mailing list. (But maybe in another thread.)

> The dragging/scrolling feels less smooth; I checked out 0.2.2 and
> it turned out I was right. I don't know what causes this behaviour,
> but it happens both with fit width and with regular zoom. Fiddling
> with page caches and prefetch didn't seem to make a difference.

Not good, interesting to know but seems unrelated to interface
questions of this thread. Maybe we should open another one for that.

Only so much at this point: The rendering of pages did change, the
drawing of them on the screen did not. Each tab now renders only one
page at a time. You can enable the old behaviour of rendering several
pages concurrently by enabling "render_from_disk" in "qpdfview.pri".
Please consult README for a short explanation.

If this is not the cause for the program feeling slower, please open a
new thread on the mailing list.

> Zooming in and out also exposes a glitch of the border: sometimes
> it doesn't fit the page (e.g. the top part is 1 pixel lower than
> it should be or the left one is offset 1 pixel to the right and so
> on). In these cases, alignment follows the border instead of the
> page itself.

This could be rounding errors as the page border and the white dummy
background will always fit the calculated size whereas the rasterized
image of the page will have integer dimensions. I am not sure how to
fix this without introducing other errors. (I am not sure how to test
this either: Maybe you can send me a copy of the problematic document
with the scale factor used. But this would also depend on the DPI of
your monitor I suppose.)

I'll probably change this to rounding up again which may be the
preferable one of the possible errors here.

> Speaking of zoom, how about adding an option (maybe under settings)
> to scale all pages to the same width (the largest) under 2-page
> view, the way okular does?

I don't know, I am already a bit uncomfortable with the non-uniform
scaling because it obscures the size relations of the document which
is IMHO what the viewer is supposed to display. Therefore I would
prefer to keep at least the relative size of the two currently
displayed pages.

> There's also page down/up which could scroll one screenfull at a
> time, instead of just putting you at the beginning of the
> next/previous page.

I think it is better that way as there are so many ways to scroll/pan
and IMHO skipping pages is more important in paged documents.

> And now on to the good news. I see you added a few buttons. Of
> course, I wouldn't mind a few more :)

I do not think that making every function accessible from the toolbars
via buttons is a good idea. Only functions that are used very often
should go there to keep the clutter to a minimum.

> I'd like it if you could have buttons for fit page/width, too, and 
> make that drop-down list into a text box to display nothing else
> but percentages (like page number). You could always see the exact
> zoom level, and you'd also see if the buttons are pressed.

As I said earlier, I like the verbosity of have a self-explaining text
there. And often, there also is no such thing as "the exact zoom
level" as the scaling is non-uniform in the fit-to-X view modes, i.e.
the scale factor is an ill-defined quantity in these modes.

> Since the drop-down list for page layout is gone, another pair of 
> buttons (for continuous mode and 1/2 pages view) would be in order.
> I think buttons are more efficient than drop-down lists, since
> instead of clicking in one place, finding the desired option and
> clicking on it, you can get away with one click most of the time.

My preference for the combo box comes from the fact that it consumes
less space and one can change both the scale mode as well as the scale
factor with one control (e.g. one can enter arbitrary percentages
there). It also means that there is less stuff on screen than if there
was a button for everything.

(Again, if you really want lightning fast access for example for "Fit
to page", you can always just press control+8.)

> And does using those icon sets that tend to be around (e.g.
> hicolor) instead of coming with its own icons seem a good idea?
> This way the user may change them along with the icon theme (and
> also get rid of the SVG dependency).

It is a good idea and that is why it is currently done that way.
(Consult the code to check.) The icons that ship with qpdfview are
fallback icons (from the Tango project, one of those well-known icon
themes) and are used only if the user does not have an appropriate
icon theme installed. If this is not picked up on your system, this
might be another configuration problem with Qt.

As for the fallback icons, I do prefer SVG to PNG because it is
simpler to handle and resolution independent. The size difference is
marginal and again, this is a fallback solution only. The default way
is to use the installed icon theme. But the dependency will probably
stay as some users do not have an icon theme with the necessary icons
installed.

> I also think hinting is nice (although some fonts seem to
> disagree). How about adding further options, such as autohinting,
> hinting styles (full, medium, slight) and subpixel rendering?

Exactly, the quality of hinting depends very much on the hints
embedded in the font files and your specific setup. So if you like it,
just enabled it. (You only need to do this once.)

As for the other options, the program exposes the rendering options
the Qt4 frontend of Poppler exposes. (Except for one related to slight
hinting.) The other options you mention should probably be configured
system-wide using fontconfig, e.g.
"http://en.gentoo-wiki.com/wiki/X.Org/Fonts#The_Xft_Font_System";.

> P.S. Sorry about the translation, but I've been busy with a few 
> (university) projects. I'll get back to it soon.

This is all spare-time work, so don't pressure yourself. Now is
currently not to good a time for translation work anyway as the
interface strings change too often.

Regards, Adam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPqVPVAAoJEPSSjE3STU341qMH/iJfENBu45ipIprFJEvTEfTw
ppX5ssANX20ZyHqC3FTpg56r11ddGJ/DJoaRVB+XoR3cvFuLLf26AKOlVsDxpMkK
lHCyRTO2LyzTQprVJ4uOgAInqJPKQ8AynRb/jSrrVg/5cQb3Yx8fxriwTSg0mDbh
pbOUoWjcERXxX/D2Jb4kXuqooBN0j4V92dTb77j6QKKCCxhfpMDALvS1XEDVJTTw
bACk8mKWXU7pc+l0Wm2N5QSw23Y2bDtqYtk3Aux70IbgYIePgndJ+Pn5uC8PMg5Q
cfOVbiSAA6dwPWhOx4RXXiM6I3stbBJFlZlK9jutGkz8CGkoyLkneiLlPm3Fzxw=
=110I
-----END PGP SIGNATURE-----