qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Hello,

On 15.06.2012 13:32, Adam Reichold wrote:
> 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.

I was wrong. The problem was/is different. I unintendedly scaled the
pages when drawing them. So these distortions should be gone. But the
infamous "one pixel too small" problem returns. But this seems rather
preferable in this case... Trunk should have the fix...

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

iQEcBAEBAgAGBQJP20jZAAoJEPSSjE3STU34h3sIAILatGtHRYSS44EIZZVmGmVz
rgdeb/G0AiDYmQ50BwfrFkJm5X63io9l3xwLjIzgriu87B6aGGEqClTzBs9KPlbh
VkK5DnJg3H97yfKaNvOt5xPPk99qivAtKAXo1LYYqiEG5u3FWxnF2PzrQ3BqeHW9
n3BrXnpwuPrwr85vSmL66OF23mQQJ+K/rh2jne5kE9KuZTK3KuGiuXByIM8pvrqW
jOKBQSgasUsIREjrHLXudO6fJVIOw3q7p3RoMil7t+brTTWPx/e/CivVrXEpFpVD
Cr1PfWocDxVIgI9JoAXo+4zkdMabdWdKKG3hueJXFSxlXLDasO3VINzLicKB0jM=
=dYNr
-----END PGP SIGNATURE-----