qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Hey,

On 11.05.2012 19:29, Andi Șerbănescu wrote:
> Hello,
> 
> On 11 May 2012 10:18, Adam Reichold <adamreichold@xxxxxxxxxxx>
> wrote: 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.
> 
> 
>> I wish I could help you, but I'm not at all into C++ or toolkit
>> programming.
> 
>>>> 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...
> 
> 
>> As of 236, it's still gone :)
> 
>>>>>>>> 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.
> 
> 
>> Yes, that's what I wanted. There's another thing: the thumbnails.
>> I really think those should be of fixed size. I actually have a
>> book whose covers are huge (over 16 times larger surface-wise)
>> compared to the rest of the pages, and besides taking up a lot of
>> space it makes it very hard to make out the contents of those
>> pages in the thumbnail panel.

I see. I will have a look into that. One thing that would really help
is if you could send me one or two of those files with non-uniform
page sizes. I actually have very few files to test with in that
regard. Of course, better directly and not through the mailing list.

>>>>>>>> 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.)
> 
> 
>> Well, I don't really care what's default if it can be easily
>> changed.
> 
>>>>>>>> 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 honestly have no idea why they put them in there :)
> 
>> If you'd ask me, it probably has to do with the fact that some 
>> documents do NOT lend themselves well to certain layouts, so if
>> you happen to load one of them, it's very useful to have an
>> option at hand for switching away to a more adequate layout.
> 
>> WIMP-oriented applications ought to have buttons to represent
>> such options, even if they also provide keybindings. Qpdfview is
>> a different animal than zathura and mupdf.

That is definitely true, but we also have a menu to represent these
functions. It's not that it is reachable by keyboard only. Anyway,
we're getting there.

>>>>> 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.
> 
> 
>> Now, I think VLC also has one of those, and it doesn't depend on 
>> anything else than Qt, but…
> 
> 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.
> 
> 
>> …editing files will do just fine for me.
> 
> 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.)
> 
> 
>> This is good. I'm very grateful. (Didn't you forget about
>> fitToWidth, though?)

The problem is that there is only a "zoom-fit-best" icon specified,
not "zoom-fit-best-width" or something like that. :-) (You can look
through the list for example here:
"http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html";)
So basically, I made a random choice. (The other option would be to
give both the same icon. Don't know whether that's a good idea.)

> 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.
> 
> 
>> Not even something that would resemble them or suggest the same
>> thing? That sounds like bad news…

Not really... This point had to come sooner or later. So we probably
need icons for the four layouts and three scale modes. It is probably
not such about designing them but finding a suitable source with a
license that allows me to use these icons. (For example, the Tango
icons are public domain so that I could just mesh up an application
icon for qpdfview without doing any actual design.)

>>>>>>>> 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?
> 
> 
>> Nothing, really. I just mentioned it.
> 
> 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
>> 
>> -- 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/

iQEcBAEBAgAGBQJPrVC5AAoJEPSSjE3STU344ncH/2NXg034kV+osiiABy+NCPzV
mTLL8aqNKAsY8nqyFJp/p6sUJuazUyh0M0V3EWfQ7S3BrZW/sqwcWz03+m1O+nqg
qqsyR3rOaM+eLzYRtd7nGDJodP6YLvXVfzS8VHHfnKoSjp1AhY/buHCFvwnK7iSL
KWyze2+4x2ORG5Yk4MxfTBVxu4ekn1MIc21tBfM8sBYdsWjILQwmr1469PLcZCvf
5kQDPwviD0DWl7R4fxsN/N85XqT/f708jOqmCJ4IND2ZCmqHhIqtsccqQq9JlEcG
lx3Sn8AgSCW84+UaaQHdGGN+p6SxWlIxgRlVh136PnBfpV8MIe/GMCJvTzrCSzA=
=K7s8
-----END PGP SIGNATURE-----