#31 Add SyncTeX support

Tools (4)

SyncTeX support would enable clean source and output mapping. It is the modern pdfTeX implementation of what source specials did.

There is already a patch to Evince in Gnome bugzilla[1]. Since SyncTeX needs support on both editor and viewer side adding this to the plugin would kickstart SyncTeX use in Gnome.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=543503


<< < 1 2 3 4 .. 11 > >> (Page 2 of 11)
  • Hi,

    I am currently working on the live preview and I was about to start trying to integrate synctex, as the preview was getting more or less as functional as it should be for a daily use (I should commit that to svn in the next days).
    However, and it's a bit sad that I worked on this livepreview for nothing, but I think that for the long term this EvView widget is what should be used (I wish I knew about this widget before!). I was planning to add ps support through libspectre, but was still facing efficiency problems interfacing this library with python. These problems would of course disappear with the use of evview.
    Also this would more easily bring transitions, fullscreen and printing, for which I only provided an easy way to open the document in the gnome default viewer for the moment.

    I think you know EvView and the way to work with synctex better than me, so if Michael agrees to include EvView in his plugin, I will hand you the development of the live preview.
    Could I ask you to wait for my commit to start working on it ?
    I think you will have to delete much and to modify most of the code, but I would like you to keep (maybe not directly of course) such features as
    - automatic centering of the document when changing the zoom,
    - key bindings for moving and zooming in the live preview while keeping the focus in the edit window (Alt+Super+Arrows and Alt+Super+{p,m} for now),
    - saving the pane position and zoom state each time it is modified,
    - keep the (horizontal and vertical) viewing position when reloading the document (maybe EvView does it natively),
    - the magnifying glass.
    I am of course at your disposal for any help or clarification about the way the live preview works for now.

    Best regards,


  • Hi,

    I absolutely agree that a preview based on EvView should be implemented.

    But before you start changing the code: please try to make the preview implementation _exchangeable_. That means: try to find an 'interface' that a preview implementation needs to comply with. The other parts of the plugin should only rely on this contract. The code of the preview is quite low-level and I'd like to keep it clean and understandable.

    @yannickv: At the beginning, this is your task, because you know the code. But first of all, complete your work on the code you mentioned.

    @jaliste: Please wait for yannickv to specify an interface and then have a look if it suffices you. Another thing: I guess you'd like to join the developer team, wouldn't you? :-)

    Do you agree?

  • Yannick, please don’t think I want to knock your work and make you feel bad. But I had the impression that your preview pane had some pretty significant usability issues. I had wanted to make some comments on the bug report where you posted it, but somehow the comment section was closed.

    I give you one example. In every user interface we have in Gnome there is a concept of keyboard focus, and once focus has been captured by a widget you can use the standard keyboard controls. But you solved it by giving the preview pane some very odd non-standard shortcuts. It would be better to give the preview pane focus so that the user can use Arrow, and Page-Up and Page-Down. And not the Windows Key. IBM thinkpads or Apple computers don’t have Windows key at all.

    There is more still. The zooming, for example.

    I think if the preview behaved just like an embedded Evince, and the same shortcuts that are active when you focus the pane, then that would be the best.

  • Tobias

    Last comment was me, BTW.

  • Hi,

    @Michael: Thank you for your answer, I agree with your proposition. I will first commit the last changes I made, and then try to define an interface for the preview (starting from the LaTeXPreview class maybe) to allow easy replacement by another one based on EvView (or any other actually). Any suggestion or help on this is of course welcome.

    @belshazzar: Thank you for your feedback. Please don't hesitate to give any other criticism you have about the preview, I have no claim of "absolute rightness" about the choices I made. When I started trying to improve the preview, it was only because I thought it was a very good idea to have this, but that it was not very usable as is (by the way, I didn't close the comment section myself, I did not intend to close the discussion!).

    What I had in mind when implementing these controls for the scrolling and zooming is the following:
    - First, I think (and maybe this is the first point which should be discussed here about the preview, independently of the backend (EvView or python-poppler)) that the huge advantage of an embedded preview compared to an external viewer, is that you can control it without giving it the focus. You can type your text, compile it, look at and move in the result, and continue typing without having to Alt+Tab every time. If you have to switch focus each time you want to move in the preview, then the difference with an external viewer becomes much less significant. (Again, I'm just explaining why I made it the way it is, not trying to convince you that it is the right way to think about it. Everything may be changed.)
    - Then concerning the "very odd non-standard shortcuts", a few comments:
    1) I tried to find better and more common shortcuts for moving for example. The arrows seem natural to use, with a modifier as the preview had no focus. But all combinations of Ctrl, Shift, Alt and the arrows were taken, either by the editor, or by gnome, or were not working (for the latter, I think about Ctrl+Shift+Alt+arrows, which is already strange). I then relied on the Super key, which is not commonly used on Linux, but not difficult to reach.
    2) I didn't know that the Super key did not exist on IBM Thinkpad. On Apple computers though, it does exist, as I'm running such a computer. It is the command key (cmd), which especially designed for shortcuts to GUI functionalities.
    3) These shortcuts should of course be modifiable in the configuration, which I haven't done yet. However, as a workaround, as in every gnome application, you can change them by hovering them and typing a shortcut (after having activated the corresponding option in the gnome Appearance configuration window.
    4) For the zoom shortcuts, the p and m stand for plus and minus. I didn't want to use these, and would have preferred + and -, but I couldn't find how to write the shortcut in the "accelerator" variable in latex/actions.py so as to make it work (I tried "+", "Plus", "<Plus>", "<+>", etc.). What is strange is that I can use <Alt>+<Super>+<+> if I assign it while hovering the menu... ! So if you know the syntax, I welcome any hint (I couldn't find any complete syntax, only examples, in the gtk or pygtk docs).

    So this explains my choices. I completely understand that these are non-standard, and should as such be changed to comply with the Gnome HIG. I considered the "no-focus" a feature, but it indeed has drawbacks and may not be intuitive, so this may be changed.

  • @belshazzar: Concerning the shortcuts, please check svn revision 357 from today. Amongst other things, the preview is now focusable.
    It is focused when toggled on, and standard shortcuts (i.e. those of evince) for moving and zooming are accessible. Ctrl+Tab moves the focus from the view to the preview, and Tab or Ctrl+Tab does the converse.
    Please tell me if it suits you.

    (If you have other remarks, which I hope, maybe we should open a new tracker item.)

    Best regards,


  • José  Aliste
    José Aliste

    @M_zeising, I would happily join the dev team. I agree it s better to make the implementation exchangables for the time being.
    @yannick, thanks for your comments... About the performance problems... In evince you have a cache that solves that for you, meaning that the render process is done async. For the moment I have some toy code that uses EvView widget to do the work, but got stack in the magnifying glass because the python bindings of EvDocument do not expose all the functionality I need. Also, using magnifying glass in EvDocument may be difficult for the same problems you have using libspectre... and a Cache may be needed for the magnifying glass... Other than that, all other features are easy to implement. Anyway, synctex support in evince won t land before 2.32; which is by sept.

  • Hello, I just got today’s commit of SyncTeX support in the internal viewer. It’s fun to play with and it gives a good idea of how it’s supposed to work.

    There is a problem with relative paths in the PDF→source direction. It tries to open relative paths, but it dosesn’t find the source files. I cannot really tell where it is looking. Gedit displays messages like

    Could not find the file /Titlepage.tex

    This doesn’t make a lot of sense.

    My file layout is


    I also get a strange Unicode-realated message:

    Traceback (most recent call last):
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/base/decorators.py", line 699, in _on_load
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/base/decorators.py", line 757, in _adjust_editor
    editor_class.__init__(self._editor, self, file)
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/base/__init__.py", line 403, in __init__
    self.init(file, self._window_context)
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/latex/editor.py", line 113, in init
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/latex/editor.py", line 339, in __parse
    master_file = self.__master_file
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/typecheck/__init__.py", line 1360, in fake_function
    result = func(*vargs, **kwargs)
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/latex/editor.py", line 379, in __master_file
    property_file = PropertyFile(self._file)
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/latex/__init__.py", line 68, in __init__
    self.__log.debug("File %s not found, creating empty one" % self.__file)
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/base/__init__.py", line 1345, in __str__
    return self.uri
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/base/__init__.py", line 1219, in uri
    return fixurl(self._uri.geturl())
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/typecheck/__init__.py", line 1360, in fake_function
    result = func(*vargs, **kwargs)
    File ".gnome2/gedit/plugins/GeditLaTeXPlugin/src/base/__init__.py", line 1112, in fixurl
    netloc = parsed.netloc.encode('idna')
    File "/usr/lib/python2.6/encodings/idna.py", line 164, in encode
    File "/usr/lib/python2.6/encodings/idna.py", line 73, in ToASCII
    raise UnicodeError("label empty or too long")
    UnicodeError: label empty or too long

  • Wow, you were quick! :-)
    Thank you for posting. I tried to reproduce your problem, but I couldn't. I created a layout like yours, and sync works in any directions from any file. I tested on Ubuntu 10.04, I will also try on Ubuntu 9.10. Could you write your configuration ? (syncex, TeXLive, distro, ...)

    Do you get messages like this one in the terminal ?

    2010-03-31 08:06:08,480 DEBUG LaTeXPreviews - Sync edit. Source:/home/yan/Documents/LaTeXTests/documenttest.tex, Output:/home/yan/Documents/LaTeXTests/documenttest.pdf, Line:22, Column:-1, Offset:0, Context:

    (I mean, with full paths ?)

    Could you send me the termina output with a few lines before and after the error "Could not find..." please ?

    Thank you very much!

    For the other problem, it doesn't seem to be related to the live preview, I filed it as a new bug (https://sourceforge.net/tracker/?func=detail&aid=2979778&group_id=204144&atid=988428 ).

  • No, it tries to open a file:// URI with a relative path.

    Sync edit. Source:chapters/1.tex, Output:/home/user/document/main.pdf, Line:13, Column:-1, Offset:0, Context:

<< < 1 2 3 4 .. 11 > >> (Page 2 of 11)