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@kde.org ReportedBy: jochen.tru...@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. _______________________________________________ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel