#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 .. 5 > >> (Page 1 of 5)
  • Nobody/Anonymous

    Yes, this will be great !

  • Michael Zeising

    Michael Zeising - 2009-11-10

    Tobias wrote:

    [...] Es geht darum, daß Evince im nächsten Release Unterstützung für SyncTeX
    erhalten wird[1]. Das funktioniert in die Rückrichtung Viewer → Editor
    schon ganz ordentlich [...]

    Am Besten wäre natürlich, wenn dann auch Gedit-LaTeX schon bereit wäre
    und man in der Editor → Viewer Richtung springen kann.

    Im Prinzip muss lediglich ein Shellkommando abgesetzt werden, wenn der
    Benutzer irgendwo in the Text klickt (mit Ctrl, oder per Tastatur):

    synctex view -i "Zeile:Spalte:Dateiname.tex" -o "Dateiname.pdf" \ -x 'evince \ --page-label "%{page}" \ --highlight-rect "%{h}:%{v}:%{width}:%{height}" \ "Dateiname.pdf"'

    Der Programm synctex bekommt die Textstelle und schlägt dann in einer
    beim Kompilieren generierten Datei nach, welcher Seitenzahl und
    x,y-Koordinate diese entspricht. Und dann ruft synctex direkt den Viewer
    mit dem Ergebnis auf (-x "...").

    Das kann man natürlich auch in den integrierten Viewer einbauen. Das
    wäre dann recht schnieke.

    Die Voraussetzungen wären für den Benutzer dann wohl: TexLive 2008
    (damit reicht es, pdflatex -synctex=1 als compiler zu benutzen), Evince
    2.29.x, und (wenn ich dich überzeugen kann) Gedit plugin mit
    Vorwärts-Synctex Unterstützung. [...]

  • Michael Zeising

    Michael Zeising - 2009-11-10
    • priority: 5 --> 9
    • assigned_to: nobody --> m_zeising
  • Tobias

    Tobias - 2009-11-27

    Just to add some more potential implementation issues:

    From my inspection of the workings of Rubber there is no way to add the -synctex=1 compiler option to the command line that rubber executes. I could be wrong however and maybe I am overlooking the obvious.

    There are directives that, when added to the .tex source file, modify the behaviour. For example, I can change the binary:

    % rubber: set program xelatex

    This has the effect that xelatex is executed, and not pdflatex. However, when using

    % rubber: set program pdflatex -synctex=1
    % rubber: set program "pdflatex -synctex=1"

    Rubber returns the errors:

    wrong syntax for 'set'
    pdflatex -synctex=1 not found

    Then there are modules, which can modify the behaviour of rubber, but this will require patching upstream or something to that effect.

    I achieved this by adding

    if dict.has_key("opt") and dict["opt"] == "synctex":
    doc.cmdline.insert(0, "-synctex=1")

    to rubber/rules/latex/pdftex.py

    I find find the organization of Rubber very confusing and don’t know how to approach this problem properly.

  • Tobias

    Tobias - 2009-11-27

    Next, displaying the PDF file:

    (For the internal previewer this can be handled more cleanly, because everything is internal to the plugin.)

    When the user double-clicks a word in the PDF (or dvi) document, Evince executes the program that was specified in the --editor parameter, when starting Evince.

    In reality we start the editor (Gedit) indirectly, via the synctex binary. The synctex binary translates XY coordinates ( -o ... ) from the PDF to line numbers in the source files. It also calls the editor with these values ( -x ... ).

    evince --editor="synctex edit -o %p:%x:%y:%o -x 'gedit +%%{line} "$directory/"%%{input}'" "$shortname.pdf"

    Here’s the issue. It is not necessary to call Evince each time the compilation is run. Nowadays Evince monitors the mtime of the loaded PDF and reloads it automatically when changed. Without flickering and without moving the viewport.

    In tools.xml the default is to call Evince every time.

    For starters, perhaps it would be best to offer SyncTeX functionality only for the internal preview, where it’s easier to implement this back and forth translation.

  • Michael Zeising

    Michael Zeising - 2009-11-29

    Hi Tobias,

    thanks for all your investigations!

    For rubber: yes, I'd like to change a lot of things in rubber. It's powerful but I'm afraid I would have to fork it because it's not really developed anymore, just maintained (see https://launchpad.net/ubuntu/+source/rubber/+changelog\). What about a 'rubber-ng'? :)

    For the rest of the integration: would you like to join the team and work on the code directly?

  • Tobias

    Tobias - 2009-11-29

    About forking Rubber: Don’t you think a more cooperative approach would be better to begin with? Perhaps Mon. Beffara would be glad to see fresh developer interest. Perhaps he agrees to move the repository to something like Google Code and give out commit access? Did you contact him yet?

    About contributing: I think I should not divert any more time from the more important things on my plate. As tempting as it is.

  • Michael Zeising

    Michael Zeising - 2009-11-29

    I already tried to contact him some time ago but never got an answer. But you're right, I should try again before starting a fork...

  • Nobody/Anonymous

    Is anybody working on this? I am working on the evince side and my branch can be integrated witht he plugin via DBUS (if you choose to open an external evince windows) or by glib signals and methods if you choose to use the EvView widget... If nobody is working on this, then I will start modifying the livepreview to use EvView widget... This will save a lot of work the devs of evince already did!!! :) And also will get us dvi and ps support for free!!!! Then, adding synctex support is easy... Just connect to the signal sync-source and call the method sync-view where appropriate.

  • José  Aliste

    José Aliste - 2010-01-21

    Last comment was by me... Forgot to login

  • Yannick Voglaire


    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,


  • Michael Zeising

    Michael Zeising - 2010-01-23


    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?

  • Nobody/Anonymous

    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

    Tobias - 2010-01-24

    Last comment was me, BTW.

  • Nobody/Anonymous


    @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.

  • Yannick Voglaire

    @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 - 2010-02-24

    @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.

  • Nobody/Anonymous

    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

  • Yannick Voglaire

    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 ).

  • Nobody/Anonymous

    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:

  • Yannick Voglaire

    Simply replace

    self._context.activate_editor(File("file://%s" % source_file))

    at line 244 of GeditLaTeXPlugin/src/livepreview.py by


    Thank you for this. I thought that synctex would always give absolute file paths, but it only does unconditionally so for the output_file.
    This will be in the next svn revision.

  • Nobody/Anonymous

    Nope. Doesn’t work.

    I pulled trunk and the change is already committed there, and it still wants to open the relative path:

    2010-04-03 13:07:59,809 DEBUG LaTeXPreviews - Sync edit. Source:chapters/1.tex, Output:/home/user/document/main.pdf, Line:749, Column:-1, Offset:0, Context:

    Also, there is still this error:

    UnicodeError: label empty or too long

  • Yannick Voglaire

    The change I made wasn't supposed to make it use absolute paths, so it is normal that it still tries relative paths if it did before.
    I would need more information to isolate the problem. Could you please
    - copy here a full log since starting gedit ?
    - copy here the content of the hidden files corresponding to your inputs (at least one, for example chapters/.1.tex.properties.xml)
    - give me the version of synctex and gedit ?
    Could you also create new files from scratch with a master and some inputs, in a subdirectory or not, and see if it also doesn't work ?

    Thank you!

    PS: for the unicode error, I have no idea, I don't know that part of the code.

  • Yannick Voglaire

    Both problems should be fixed now in svn, please tell me if you still have problems.

    Just to know, did you have accents in your file names or directories ? And did you have "../" in your relative file paths ? Because for me the problem only happens with one of these two things. So if it does for you without these, it may still be another problem.

  • Nobody/Anonymous

    Relative paths are fixed now. I don’t have accents or .. in the include statements in my source files. They are simple relative paths.

    What is a bit unfortunate now is the the internal preview is toggled per-document and not globally. Is there a reason for this? Is it because there might be non-TeX file open inside gedit?

    Will there be support for SyncTex with external viewers too?

1 2 3 .. 5 > >> (Page 1 of 5)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks