qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Hello again,

On 10.05.2012 22:25, Andi Șerbănescu wrote:
> On 8 May 2012 20:27, Adam Reichold <adamreichold@xxxxxxxxxxx>
> wrote: 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).

Well, as I said, currently I do not know how to do this without any
rounding errors. I am open to suggestions.

I'd also say we could life with that one pixel mistake as long as it
does not cause the horizontal scrollbar to become visible.

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

Nice.

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

Maybe this was the revision were I accidentally pushed
"render_in_paint" as the default configuration...

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

Added a build-time option "fit_to_equal_width" for you to try out and
tell me whether this is what you actually meant. Tough personally, I
don't like it. But of course, I could live with the build-time option.

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

Good idea. Should be done.

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

Agreed. I reduced the default to "open in new tab" and "refresh" for
"file" and "current page", "number of pages", "previous page" and
"next page" for "edit".

This would probably be a good place for other users of this mailing
list to speak out what they would choose as the default options as I
will probably remove the fallback icons of the non-default actions
from the release. (Meaning you could not really add them back in if
your icon theme does not contain the necessary icons. See 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.

I think I really like that combo box and will probably not change it
but see below.

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

That does not seem to be a real argument because the question would be
why they have them and whether we agree with that reasoning.

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

Definitely too crazy. :-) (I'd assume that Evince basically gets this
for free from the GNOME support libraries.) I am not in favour of
implementing this or even just dropping it into the code from
somewhere else as qpdfview aims for a somewhat minimal code base.

But I did make the toolbars configurable by editing the configuration
file which should be "~/.config/qpdfview/qpdfview.conf" by default
(depending on your XDG_* environment variables). You can set the keys
"fileToolBar", "editToolBar" and "viewToolBar" in the section
"mainWindow" to your liking using your favourite text editor.

The current defaults are:
fileToolBar = openInNewTab,refresh
editToolBar = currentPage,numberOfPages,previousPage,nextPage
viewToolBar = scaleFactor,zoomIn,zoomOut (Yes you can remove that
pesky combo box. :-))

Further available entries are:
fileToolBar: open,saveCopy,print
editToolBar: firstPage,lastPage,search (Yes you can finally have a
search button. :-))
viewToolBar:
fitToPage,doNotScale,rotateLeft,rotateRight,fullscreen,presentation

Note that you can also use this to just reorder things. (I will
probably have to document this in the README.)

The options that seem to be currently missing from the view toolbar
have the problem that there are no icons specified in the FreeDesktop
icon naming specification, i.e. they are not completely standard.

This means someone would have to design some magnificent icons for the
page layout and probably the scale mode options that could actually be
shipped as non-fallback icons. But here is the catch: That someone
won't be me as I am totally absolutely not in the design-and-graphics
department.

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

That's bad, but I don't see anything that qpdfview could fix about that?

Regards, Adam.

>>>>> 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.
>>>> 
>> 
>> -- Mailing list: https://launchpad.net/~qpdfview Post to     :
>> qpdfview@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>> https://launchpad.net/~qpdfview More help   :
>> https://help.launchpad.net/ListHelp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPrL1TAAoJEPSSjE3STU34G6gH/1ISxL0UEMq59giaBei3A3/h
WYMdjPM9J2NbCzAJKPFRRTi+0d5J4/12VmC+YMx/LSvQ9sw7UKTx1fHGo3o1d6kN
PsLocIRVs0WqENOlE6vBHfZAaWXZcP6oCwBMbZ8dbryDblqV8/gWBQ3nMMvKe5Hn
loJybZunQwvCCfAFZeBej56fGXxIHxbEwvrhufytdYNmog+M/j4VbxiY1DpDSQtL
De4F34AhoGDUYI4GiiW7H2KQE/A1EZ28uao1jZyks4t4mFctTZhMOPn3MsRuABzf
RZtQFEAV6s7R/YTXcZ4uFZl9u7Fk1EpYpr7RXpo8KxRyUW85cclUIOSviApAIc8=
=n3cl
-----END PGP SIGNATURE-----