qpdfview team mailing list archive

[Andi Șerbănescu <ac.serbanescu@xxxxxxxxx>]

On 8 May 2012 20:27, Adam Reichold <adamreichold@xxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Revision 225 rounds up the bounding box of pages again and hence
> hopefully fixes the page border problems.
>

The borders don't show that glitch anymore, but sometimes a few pages
may be 1 pixel wider or narrower than the rest (obviously with fit
width).

> On 08.05.2012 19:11, Adam Reichold wrote:
>> 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.)
>>

Will do.

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

I got the latest revision and the sluggishness is gone. Thanks.

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

See above.

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

You would be able to turn it off, of course. And the current way of
scaling would controlled by the same setting.

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

Then how about leaving page up/down alone, and making, say, backspace
and space do those things instead?

>>> 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 agree with you there. Come to think of it, I don't see why would
both open and open in new tab, or save to file be in the toolbar.
(More on this below.)

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

I know, but I don't see why that would be a loss. Tooltips could
explain things instead.

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

Yes, but they do seem missing. All the other viewers have buttons to
control page layout and zoom.

I'm curious to know if something can be done to solve conflicting
preferences. Would one of those toolbar editors (à la evince) be too
crazy?

>>> 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'm actually surprised to see how many misconfigured things I may have
lying around :)

>>> 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";.
>>

There are a few problems with poppler and subpixel RGB right now, so
it doesn't really work :)

>>> 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/
>
> iQEcBAEBAgAGBQJPqVdvAAoJEPSSjE3STU34EnYH/jXbmrd2b0k3xUikhnxL/PM6
> VeV7H2rAN2lm+yi8XNWlM/5raz9Qn8x89XIQ1vhPYQqdIgT7+77J8PG00OUu64Zp
> hoKx8NAxOCf9WrfVcrEJE6t/GNexNucroxnSq2NFepHd00viKbJnlXOUHHfqFGMT
> vGkEp+QilwGz1KQd28VNtQd9E5OXFGO6pAfxdjXnv3NJZ+cnegcnnFpBlxRMicH7
> 5dmPAuTbBJ1CuZU+HuvFWa/gcNFf7o7pPhu++cQjQCcWdofMQuj8VxLjDu/yAYmP
> Rvu3g0mWTaoRPSHYDTiTCFrGbj9+0Wm9rcJnovZtvJdFWed2zyGH0RqmhQuL790=
> =iyXz
> -----END PGP SIGNATURE-----
>
> --
> Mailing list: https://launchpad.net/~qpdfview
> Post to     : qpdfview@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~qpdfview
> More help   : https://help.launchpad.net/ListHelp