qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Revision 225 rounds up the bounding box of pages again and hence
hopefully fixes the page border problems.

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

iQEcBAEBAgAGBQJPqVdvAAoJEPSSjE3STU34EnYH/jXbmrd2b0k3xUikhnxL/PM6
VeV7H2rAN2lm+yi8XNWlM/5raz9Qn8x89XIQ1vhPYQqdIgT7+77J8PG00OUu64Zp
hoKx8NAxOCf9WrfVcrEJE6t/GNexNucroxnSq2NFepHd00viKbJnlXOUHHfqFGMT
vGkEp+QilwGz1KQd28VNtQd9E5OXFGO6pAfxdjXnv3NJZ+cnegcnnFpBlxRMicH7
5dmPAuTbBJ1CuZU+HuvFWa/gcNFf7o7pPhu++cQjQCcWdofMQuj8VxLjDu/yAYmP
Rvu3g0mWTaoRPSHYDTiTCFrGbj9+0Wm9rcJnovZtvJdFWed2zyGH0RqmhQuL790=
=iyXz
-----END PGP SIGNATURE-----