qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Hello,

On 15.06.2012 12:36, Andi Șerbănescu wrote:
> On Fri, 15 Jun 2012 09:01:48 +0200 Adam Reichold
> <adamreichold@xxxxxxxxxxx> wrote:
> 
> Hello Andi,
> 
> On 14.06.2012 22:15, Andi Șerbănescu wrote:
>>>> Hello,
>>>> 
>>>> I'm back. How's it going? I've been living in a cave for the
>>>> last month :), so if I'm pestering you about something that
>>>> has already been talked about, then I apologise.
> 
> Nice to have you back. We are still in a somewhat lengthy 0.3beta 
> cycle. Mostly waiting for translation work (I contacted the
> Launchpad translators team for help.) and fixing the odd bug or
> two. We also see some activity w.r.t. the Debian package.
> 
> 
>> I'll be minding the translation soon, too. I also have an updated
>> ebuild for the development branch. The Gentoo guys already have
>> one in Portage for milestones.
> 
> I hope to be able to release soon enough. And I learned so much
> doing 0.3 that I think 0.3.1 will be a rewrite again. :-) But with
> under 10000 lines of code, this should not be too much of a
> problem...
> 
>>>> I remember about the button images. The Oxygen theme has
>>>> icons for all of the features except continuous mode, if I
>>>> remember (and it's dual-licenced, under GPL and CC). It would
>>>> be good if we could get rid of the ‘hidden’ buttons by the
>>>> next stable release.
> 
> With 'hidden', do you mean not visible by default? Because by now
> you should be able to add all buttons you wanted and some more and
> there should be icons for them. (If you have a FDo-compatible icon
> theme installed. But always for the defaults and
> application-specifics.)
> 
> If not this sounds like a bug. Can you expand on what you mean by 
> 'hidden'? Maybe with a screen shot?
> 
> 
>> That's exactly what I meant: the non-default buttons (which
>> display a text string instead of an image). And they also seem to
>> use the fallback icons regardless of any icon theme present.
>> Maybe this is some Gentoo glitch, but I don't really know.

The non-default buttons display a text only if there is _no_
FDo-compatible icon theme. Nothing I want to change about that.

The application-specific buttons are application specific and
therefore can not use the icon theme. (I think this is page layout and
scale mode.) Again, this is as intended.

What would be unintended is if the non-default buttons would display
text even though there is an icon theme present. But since this is
known to work on other platforms, I suspect a Qt configuration problem.

>>>> I also wanted to suggest that instead of having the 1/2 page
>>>> and 1/2 column modes, we should have 2 binary options
>>>> (continuous and dual) that can be activated independently of
>>>> each other. It would be easier for the buttons too (we'd only
>>>> have two buttons, and therefore only one more image to find
>>>> instead of two).
> 
> This is way the other viewers do it. I know. Will think about
> it... Not sure yet.
> 
>>>> And about the single toolbar, I think that the current degree
>>>> of control over their contents afforded by editing the config
>>>> should do away with the need of having multiple toolbars. Or
>>>> maybe you can have two, but each having all the available
>>>> options (if you want, say, to put them in different places).
> 
> Putting them in different places. (De)Activating them
> independently. Grouping functionality. Multiple tool bars seem to
> be too useful to me, so I don't think I want to change that.
> 
> 
>> I thought about that. But you can still do most of those things
>> with one toolbar (activating and grouping buttons separately),
>> with even finer control (right now, for example, you can't put
>> ‘View’ buttons between ‘File’ buttons). For multiple placement,
>> maybe fixed toolbars would be in order, but the current way
>> (specific toolbars) is rather restricting.
> 
>>>> Regarding the document TOC (Outline) links not working: they
>>>> work only for a few documents; for most, they work only
>>>> partially or not at all. I have attached a book for which
>>>> they don't work at all. I don't know if most of my documents
>>>> are corrupt or not, but in evince they do work.
> 
> I think I found the problem: The document you sent is a bit odd in 
> that it specifies links like page 14 at -63% from the top. (And
> since it is always -63%, I guess it is somehow broken.) The
> document view then refuses to open a link to "page = 14, top =
> -0.63" as e.g. top is expected to lie between 0.0 and 1.0.
> 
> Everywhere else this is enforced but I seem to have forgotten
> about the outline. So I force the links into valid parameters as
> well by truncating page and top and it seems to work as intended.
> (trunk revision 314)
> 
> 
>> It works now. Thanks. Oh, and speaking of the book I sent: does
>> reading compressed (gz, bz2, xz etc.) files seem like an useful
>> thing to have?

Not really on the list. IMHO, PDF viewers should display PDF files
whereas compressors should uncompressed compressed files.

>>>> I've also noticed that scaling produces some artifacts.
>>>> Fiddling around with my resolution settings didn't help. Can
>>>> you reproduce it with the book that I've sent you? Set the
>>>> window size to 1024·768 and the layout to single page
>>>> continuous and fit to width. Then go to page 1 (14 of 231),
>>>> row 7 (‘ontology. Other kinds…’).
>>>> 
>>>> Can you see the row being stretched and those weird looking
>>>> ‘s’ glyphs? Of course, it happens in other places too, but
>>>> this one was the only handy example. (And it obviously only
>>>> happens for a some zoom levels.)
> 
> Yes, I can see those artifacts and know their kind. But I don't
> know how to do something about them. This happens in the rendering
> which I delegate to the Poppler library. Could again be rounding
> issues from scale to DPI to integer dimensions. As I said I am not
> unsure if anything can be done about it. (Besides changing the
> scale that is.)
> 
> 
>> Hopefully it will go away with a new re-write. By the way,
>> did/can you check out mupdf as an alternative back-end?

I checked mupdf as backend and wrote some proof of concept. But it is
rather unstable compared to Poppler which seems better supported and
easier to develop with.

>> But there's something I don't get: if calling poppler is done the
>> same way across different software, then why do these things
>> happen? If you do re-write it, maybe you could take a look at
>> some other client that doesn't have these issues, such as okular
>> (a daunting task, I know).

I think the problem is to correctly round the resolution at which the
pages will be rendered which would have other side-effects. We'll see.

>>>> And it also has the nasty habit of segfaulting when I make
>>>> changes in the ‘Settings…’ dialogue if any file is loaded. It
>>>> seems to happen regardless of what options it's built with.
>>>> I'm using poppler-0.18.4-r1 from Portage, by the way, but I
>>>> suppose this doesn't happen to you.
> 
> Yes, it does not happen to me. Which does not mean there is no bug 
> involved in this.
> 
> All documents are refreshed after the settings are changed. Maybe
> you could try to find out whether refreshing alone will trigger
> this behaviour as well?
> 
> 
>> You're right, Refresh is the culprit. I have no idea how to look
>> into it. It didn't always happen (actually, I think it's rather
>> recent), but I don't remember when did it first crop up.

Again, a test file may be helpful. Does it happen with the file you
sent earlier?

>> And why did you have to change PgUp/PdDn and Sp/Bksp behaviour? I
>> don't have any way to scroll by the screenfull in non-continuous
>> mode, which means I have to either use the ‘slow moving’ Up/Dn
>> keys or switch to using the mouse, which is even more annoying.
> 
>> The old way of doing it (PgUp/PgDn always changed pages and
>> Sp/Bksp always scrolled by the screenfull) was just right.

I think the result of that discussion was: Left/right for
previous/next page and PgUp/PgDn and Sp/Bksp for scrolling one screen
at a time. Works exactly like that for me.

>>>> Regards, Andi
>>>> 
> 
> Best regards, Adam.
> 
>> 

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

iQEcBAEBAgAGBQJP2x1lAAoJEPSSjE3STU34rn0IAMFQPxPbWt0wUinjj9CNVM1l
N0HiNfYmx9xwqdWFnXeCI5r9z9s/rLnw+6tGVpCtk9DVwQK19rmiL4M1NpPL5mPF
ODFbDTIrm1oi5p4plZB4wxsW8HQaE6TV5lndit5wARK23T43id42Nz2iJTttdGMt
uYBn/ZjNZjxiSZIQzXBAHg7HTqFJXwSQCfRR2L6wq7r2LpVXAFzxcgsBtZLCg9yB
MouAbdWqKekf/LBWkhpZjj4hrYKwasbUGRmZOOdWiSEnxMbt2+pdotdixi1yd5qk
c6rQGCOBFxH6TslIrwbmXKE88p3YgJgEuTKnW7mYO3QFWovRVze70pdbjQLLtLI=
=VoCc
-----END PGP SIGNATURE-----