[Okular-devel] [Bug 205084] New: dvi source references don't work properly when --unique is used (not a backend problem)

Jochen Trumpf Jochen.Trumpf at anu.edu.au
Tue Aug 25 15:08:38 CEST 2009


https://bugs.kde.org/show_bug.cgi?id=205084

           Summary: dvi source references don't work properly when
                    --unique is used (not a backend problem)
           Product: okular
           Version: unspecified
          Platform: Compiled Sources
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: okular-devel at kde.org
        ReportedBy: Jochen.Trumpf at anu.edu.au


Version:            (using Devel)
Compiler:          gcc (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) 4.3.2 
OS:                Linux
Installed from:    Compiled sources

This one is a bit tricky, so please bear with me. Try to run

okular --unique file:///full/path/test.dvi#src:834test.tex

followed by

okular --unique file:///full/path/test.dvi#src:834test.tex

on a multipage dvi document that contains source references. Pick a reference
that appears not on the first page of the document (i.e. a high line number,
e.g. 834 in my example). Note that due to bug #205076 you will need to use
fully qualified urls to reproduce this bug.

On the first call, the document gets correctly opened at the approximate
location of the source reference. The second call reloads the document, but
jumps to the first page of the document instead of to the location of the
source reference. This also happens if you change the line number of the source
reference in the second call (no matter what you change it to). As an aside,
note how the correct page number is displayed at the bottom but the wrong page
is shown after the second call. The vertical scrollbar position is also wrong.

I have spent a lot of time trying to debug this and have narrowed down the
source of the problem to a particular piece of code in 
PageView::slotRelayoutPages(), around the call to center(geometry.left[...]) in
part 4) of this method (the call is in line 3022 of ui/pageview.cpp).

On the first call of okular, this code gets eventually triggered and further
down the track correctly sets the viewport corresponding to the given source
reference. (There is always an earlier attempt at setting that viewport which
fails since the viewport geometry has not been adapted yet and leads to an
invalid (inf) normalizedY coordinate. I am not sure if that is a bug as such,
though).

On the second call of okular, however, no new PageView is constructed
(obviously, because the document is opened via dbus), so some missing(?) resize
code [see below] somehow leads to this center call not being made. This means
that the viewport corresponding to the source reference has an invalid (inf)
normalizedY coordinate when it is first set and different to the first call it
is not set again later.

The easiest way to see this happening is to put some debug code into   
Document::setViewport.

By trial and error I have found a further indicator that the problem has to do
with resize: Put the (completely irrational) call

m_pageView->viewport()->resize(0,0);

after the openUrl call in Part::openDocument( const QString &doc ) and now the
document gets openend at least on the correct page when okular is called the
second time. The viewport is still slightly wrong, though, so this is not even
a workaround. This was just the only way I could find to get the center call
mentioned above triggered. I couldn't find a way of telling okular to "dirty"
the whole viewport although its geometry has not changed [this is my
interpretation and may be way off the actual problem].

I am happy to help debug this further if needed.

Incidentally, I found this bug and also bug #205076 while implementing forward
search for pdf files using synctex. I will post my code to okular-devel later.

Cheers, Jochen

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the Okular-devel mailing list