[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