qpdfview team mailing list archive

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

On Fri, 15 Jun 2012 09:01:48 +0200
Adam Reichold <adamreichold@xxxxxxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.

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

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

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

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

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.

> > Regards, Andi
> >
>
> Best regards, Adam.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJP2t3cAAoJEPSSjE3STU34IDYIAKjATiU8zOpNeb436D/eTBGU
> 95ozPnqv9Hubnlei+98I1Rj8HhxOHQIIdVeZ7DtegxpIBs+cxRCtHTTRXCZ4+90r
> BoWrYnj5SfGeU1FrxnlN+B/vuvqAYPUrYgZHWXnKk+ZtslFmbo2VOGMF0IWku2h6
> 0dYFm5Eufd5qneC+UyK4vjKO9NCZM6RBY25/oLMO8V+EJrDYaKppGiXAO98UpuC+
> fI6e5frpl8YRrFSeKlQYteufFmhsf78eDEi8nd7ll5LN+nMn+aQz4Uatq7MF+nTf
> /nAHqwT0VoBU83ihDGwCOwxo9J7Y8X/wd27ZJ9NFLqhs/9aa9ODybQHUgshcP44=
> =IJ0Z
> -----END PGP SIGNATURE-----
>