#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 5 > >> (Page 2 of 5)
  • José  Aliste
    José Aliste

    It's working for me too. I will add synctex support for evince as external viewer as soon as the synctex patch in Evince is merged.

  • > 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?

    The reason is that the user may not want to have previews for all his tex documents. In 0.3 maybe the preview panel will be in a side view, just like the left and bottom panels. Then it will be
    I guess you encounter this the most when reaching a tex file through ctrl+clicking in the preview. In this case, indeed it is better to open the preview for the new file by default (to show the pdf we were coming from). I'll commit this soon.

  • José  Aliste
    José Aliste

    yannickv, I am ready to add synctex support using evince as a External viewer. I have a small problem though. Right now, the ctrl + left click always trigger the EmbededPreview, even if it's not shown... So I can't use the visibility of the EmbededPreview as a flag to know where to send the synctex event (either to the internal preview or to the external Evince viewer)... I was thinking about adding a Preference to say wether you want internal preview or external preview as prefered Preview. What do you guys think?

  • I was concerned by the same problem, and came up with the same proposition. In my opinion, setting it as a global preference respects the user's choice, and keeps the advantage that Ctrl+click (ideally) allows to
    1) open the preview or external viewer if it is not opened,
    2) synchronize the view with the source,
    in only one operation.
    Then, there are some details like: if the user has chosen the external viewer for sync, and (accidentally or on purpose) opens an internal preview, then should ctrl+click synchronize with the internal or the external viewer ? Should that be a second option ? Or should the internal preview be unreachable when the external one has been chosen in the options... ? What do you think ?

  • What about always synchronizing both, the embedded and the external viewer? I don't think it's that expensive, is it?

    If necessary, an alterantive to an option would be a toggle button next to the embedded viewer for switching between the embedded viewer and external viewers to be synchonized (like the outline sync toggle button). What do you think?

    • labels: --> Tools
  • José  Aliste
    José Aliste

    @m_zeising, the problem with synchronizing both is what do we do if the user ctrl+ left click and neither the internal nor the external viewer are shown, then which one are you supposed to open? (ctrl + left click should open the view if it's not already open!) This is undefined, unless we have a preference or the toggle button.
    @yannickv, I would say that internal viewer should be unreachable when the external viewer is chosen is better. But really don't know about different usecases... In particular, I always use the external viewer.

    Other option is to add to the metadata, which viewer you were using for a given tex file. Then use this information to open the corresponding viewer. And maybe just ask the first time you do a ctrl + click, which viewer do you prefer.

    Some details about implementation. It's done with Dbus. After spawning evince, I get the DBUS object of the Window in Evince and connect to a signal (to have view-to-source sync) and call a DBUS method when ctrl + click (to have source-to-view sync). The synctex parser is embeded in evince, so there is no need to call "synctex" in the command line.

  • > Some details about implementation. It's done with Dbus. After spawning
    evince, I get the DBUS object of the Window in Evince and connect to a
    signal (to have view-to-source sync) and call a DBUS method when ctrl +
    click (to have source-to-view sync). The synctex parser is embeded in
    evince, so there is no need to call "synctex" in the command line.

    With the future option for "internal/external viewer", I think it should not be a problem to plug this in the current implementation (at least part of it in LaTeXEditor._ctrl_left_clicked() for the source to view, I guess).
    For the internal preview, here is basically the current structure. Could I ask you to tell me if this would suit you for your EvView implementation, or what you would like to have changed, added, etc. ?

    - the plugin only communicates with the previews through the LaTeXPreviews class, which is attached to the window context (WindowContext.latex_previews). Actually this is only completely true since the last commit (379).
    - LaTeXPreviews has the following "public structure":

    class LaTeXPreviews:
    Class that manages all tab's preview panels.

    ZOOM_IN, ZOOM_OUT = range(2)

    def __init__(self, context):
    def is_shown(self, tab):
    def toggle(self, tab, compiled_file_path):
    def show(self, tab, compiled_file_path):
    def hide(self, tab):
    def reparent(self, tab):
    def update_file_path(self, tab, compiled_file_path):
    def zoom(self, tab, direction):
    def scroll(self, tab, direction):
    def sync_view(self, tab, source_file, line, column, output_file):
    def sync_edit(self, source_file, output_file, line, column, offset, context):
    def destroy(self):

    - All these methods are called by the plugin, except sync_edit, which is called by the internal preview after a ctrl+click in the pdf. Note that no sync code is in LaTeXPreviews nor in the rest of the plugin, so that it is really the preview itself which chooses to use the "synctex" program, or synctex library, or something else.

    - actual previews are instances of a PreviewPanel class, of which there would be two implementations: one with python-poppler, one with EvView (do you agree with that ?). In the present state, this class exposes the following methods and constants:

    class PreviewPanel:
    This class manages a view of the compiled file.




    def __init__(self, latex_previews, compiled_file_path):
    def scale(self):
    def file_path(self):
    def update_file_path(self, file_path):
    def get_panel(self):
    def get_scrolled_window(self):
    def get_vadjustment(self):
    def get_hadjustment(self):
    def set_cursor(self, curs):
    def get_zoom_type(self):
    def set_zoom_type(self, zoom_type):
    def zoom_to(self, scale, zoom_type):
    def zoom_in(self):
    def zoom_out(self):
    def zoom_fit_width(self):
    def zoom_fit_page(self):
    def scroll_up(self):
    def scroll_down(self):
    def scroll_left(self):
    def scroll_right(self):
    def get_free_horiz_space(self, page_index):
    def get_free_vert_space(self):
    def get_page_and_position_from_pointer(self, x, y):
    def get_page_at_position(self, position):
    def get_current_page(self):
    def go_to_page(self, page, relative = False):
    def go_to_page_and_position(self, page, y):
    def toggle_continuous(self):
    def sync_view(self, source_file, line, column, output_file):
    def destroy(self):

    of which only the following are currently used by LaTeXPreviews:

    get_panel() (the panel is a focusable gtk.Widget, and is the second child of the HPaned split view (owned by LaTeXPreviews) of the tab, the first child being the text view), file_path, update_file_path(), zoom_{in,out}(), scroll_{up,down,left,right}(), sync_view(), destroy()

    - the zoom_* and scroll_* should probably be merged into one method... ?
    - if we introduce a widget in some toolbar indicating and allowing to change the current page number and zoom state, methods like go_to_page, get_current_page, get_zoom, etc. should then be present.

    Suggestions, questions and comments from anyone, especially from José and Michael, are most welcome.

    Best regards,

  • Yannickv, it seems ok

  • Evince finally got SyncTeX support and it will be available in 2.32. Release (due in Oct 2010). Gedit-plugins has also got an official plugin to use synctex support (dev by me). Please notice that the plugin only implements Forward and Backward Search, nothing more, I intend this other plugin to be as simple as it can be.

    So, Do we agree about the "external/internal Previewer Preference"? If so, I would like if we can release gedit-latex-0.2.1 adding this pref, so that ctrl+click is disabled if the external Previewer is used. This way, gedit-latex and gedit-synctex plugin can live together ;) Michael, What do you think? Of course, as Tobias point out, we should try to add synctex support to rubber so everything works well.

  • The pre-first e85 debt is entitled on the season, with some cards spinning the income's computer people finance and requests constructing that liquid twenty-two installation would improve victim tax in the zone. , http://xserv1.umb.edu/groups/podcasts/weblog/232b6/attachments/04ee1/47a.html business credit card processing, 550240,

<< < 1 2 3 4 5 > >> (Page 2 of 5)