[Okular-devel] idea for activation of inverse search

[Pino Toscano]

Hi Jochen,

(wow, what a busy weeks, sorry for the delay...)

> I have been thinking a bit about a good activation method for source
> references in okular. I think, the shift+left click is generally okay, but
> what I would expect to happen in dvi documents, and also in pdf documents
> generated from latex (either with pdfsync or synctex),

Yes, the activation method is the same for each document that provides 
references to a source file. Currently we support references in DVI files, 
and pdfsync for PDF documents.
(I have been asked to support the new Texlive 2008' synctex, but not got 
around installing it to actually try.)

> is that such a click 
> activates the closest source link, even if the point I clicked is not in
> the direct vicinity of any such link.
>
> So, probably something like
>
> const ObjectRect * Page::closestObjectRect( ObjectRect::ObjectType type,
> double x, double y, double xScale, double yScale ) const
> {
>   QLinkedList< ObjectRect * >::const_iterator it = m_rects.begin(), end =
> m_rects.end();
>
>   double bestdist = 1000.0; // effectively infinite
std::numeric_limits<double>::max() ;)
>   ObjectRect *bestrect = 0;
>   double temp;
>
>   for( ; it != end; ++it )
>     if ( ( (*it)->objectType() == type ) && ( (temp = (*it)-
>
> >distTo(x,y,xScale,yScale)) < bestdist ) )
>
> 	    {
> 	      bestdist = temp;
> 	      bestrect = *it;
> 	    }
>
>   return bestrect;
> }
>
> with a corresponding implementation of (an overloaded virtual?)
>
> double SourceRefObjectRect::distTo( double, double y, double , double )
> const {
>   return ( pow( y - m_point.y, 2 ) );
> }

For now we are maintaining a binary compability for the core library, and I 
don't see a real need for it. A problem of this implementation (well, not 
really a problem per-se, but of the way it should be used) is that it'd 
return the nearest object, that could also be "far" in the page.

> Here is a small problem I ran into: this version of distTo does not use x,
> but works well for dvi, since there the source links are always centered at
> x=0.5 in the middle of the line (the DVI_SourceFileAnchors only have
> vertical information -- why?).

(at a really quick glance, it would look like some peculiarity of the DVI 
format.)

> I.e. I do not have to hit close to the 
> center of the line and still the best link is selected. However, the
> current pdfsync anchors also have horizontal information (and I guess the
> synctex ones will as well). So, you either need to check the type of
> file/source anchors in the distTo function or you need to modify the
> DVI_SourceFileAnchors.

Another idea could be having "-1" as special value for either of the 
SourceRefObjectRect coordinates to indicate "this coordinate is not 
specified/does not care".

All in all, I could use this -1 marker plus a custom proximity function in 
Page to find out... why not...

> I don't know if source links are used in other document types and whether
> there you wouldn't want the closest link to open. If that is the case, you
> could make the choice of objectRect vs. closestObjectRect configurable (per
> backend?).

I would not do configuration, but just find a "good enough" distance from each 
point (ie like the 5px-radius circular zone around the cursor).

> Thanks BTW for the editor config dialog! I had been waiting for that :-) In
> case you want to add an emacs/emacsclient default there: the commandline
> would be
>
> emacsclient -a emacs --no-wait +%l %f
>
> (this uses emacsclient to open in a running emacs with activated
> emacs-server, if that fails it starts a new emacs)

Added few days ago, thanks!

> I hope you find this useful.

Sure thing, thanks for the feeback :)

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/okular-devel/attachments/20081115/fb93012f/attachment.sig