# TeXworks: synctex works only partially

I've got a document that compiles without error or warnings (and looks about right) but for some segments of the document synctex doesn't seem to be working. What could be wrong?

The document consists of one root .tex file which \inputs a bunch of others. Synctex works for all these sub-documents - except for one. In practice, this means I can Ctrl-Click in the viewer and find the appropriate spot both in parts of the text before and after this particular subdocument. Conversely, I can Ctrl-Click in the editor and jump to the right spot in the view in all subdocuments but this one.

However, when I Ctrl-Click on a part of the output corresponding to this particular subdocument I get the following error popup: Cannot read file "E:/emn/uni/Thesis/doc": Access is denied. in the TeXworks viewer. The path in this error message exists but is a directory: namely the one containing the tex files.

• All filenames consist of only latin letters, numbers, and underscores and the extension .tex. The problematic file is called G2MLVQ_9_Refinements.tex whereas a (working) file is called G2MLVQ_7_Implementation.tex
• I can't make a small example which fails - small examples don't fail; however the order of files seems to matter, so perhaps something in an earlier file is affecting synctex later on... (once I've isolated this, I'll update the question).
• Concerns MiKTeX 2.9 and the bundled TeXworks version 0.4.3 r.857.

I'm stumped: what could be going wrong?

-
We need more detail. What version of TeXworks and TeX system (MiKTeX, TeXLive) do you use? What are the file names involved: are there spaces or special characters in the name of the problematic file? –  Joseph Wright Nov 15 '11 at 16:39
It is always best to compose a MWE that illustrates the problem including the \documentclass and the appropriate packages so that those trying to help don't have to recreate it. Personally, I have often solved my own problems in the process of reducing the amount of code actually required to reproduce the problem. So, in this case try removing most of the code before and after and try to minimize the size of the included file. –  Peter Grill Nov 15 '11 at 16:41
Thanks! I'll try to make a MWE, which I haven't managed to yet. –  Eamon Nerbonne Nov 16 '11 at 14:29
There are no weird characters in the filename; everthing is in [A-Za-z0-9_] followed by .tex. Path contains no spaces and no weird characters either. Oh, and the \input command uses the same capitalization as the filename to avoid windows case-insensitivity issues. –  Eamon Nerbonne Nov 16 '11 at 14:32
I have exactly the same problem with synctex and multiple files, using the TikZ-package for drawing. It turned out that uncommenting a certain \input{tikzpicture.tex} in a (working) file that is parsed just before the problematic file 'resolves' the problem. Currently I'm trying to figure out which part of the TikZ-code causes the problem. It seems to have no problems with a minimal TikZ-example as an \input{tikzpicture2.tex} and synctex also links correctly into tikzpicture2.tex. –  user9705 Nov 30 '11 at 10:34
show 2 more comments

I have ran across a similar problem on WinEdt and SumatraPDF. After trials and errors, I found that if I use \input for both files (e.g., the first one contains a "complicated" tikzpicture, and the second one is where a synctex search error may occur), instead of \include, the error goes away. If I need \newpage or \clearpage for the second file, I use the command inside the file, not before the \input command in the main file.

For an example of "complicated tikzpicture", you can try the example "Fancy tables with TikZ", a blog by Stefan Kottwitz:

http://texblog.net/latex-archive/graphics/tikz-table/

Hope my experience might be any of help.

Here is an MWE:

main file

\documentclass{article}
\usepackage{tikz} %% to construct a complex tikzpicture
\usetikzlibrary{calc}
\pgfdeclarelayer{background}
\pgfdeclarelayer{foreground}
\pgfsetlayers{background,main,foreground}

\begin{document}
\section{Main File}
Three more tex files will be added below.

% part1 contains a tikzpicture
\input{synctex-part1}

%\newpage, \clearpage or \include may break synctex
\input{synctex-part2}

\newpage  % now without it, synctex in part 3 is broken
\input{synctex-part3}

\end{document}


synctex-part1.tex

\section{Part 1}
a complex tikzpicture

\begin{tikzpicture}
\node (mynode) {\Large This tikzpicture may cause synctex failure.};%
%% without pgfonlayer, synctex works fine regardless include or input
\begin{pgfonlayer}{background}%
%% draw a box
\draw[rounded corners,top color=red,bottom color=black!40!red,draw=white]
($(mynode.south west)-(0.1,0.1)$) rectangle ($(mynode.north east)+(0.1,0.1)$);
\end{pgfonlayer}%
\end{tikzpicture}


You can write anything in synctex-part2.tex and synctex-part3.tex to test.

-
Thanks for the tip - I'm using only \input already anyhow, and the "main" file contains virtually no content beyond \input already - just the title and TOC, not even usepackages etc. –  Eamon Nerbonne Jan 21 '12 at 12:19
@Eamon Nerbonne, I added an MWE, see if it helps. –  ltxsun Jan 22 '12 at 3:20

I had exactly the same problem after moving the last section from one capter_y.tex to somewhere in chapter_x.tex. After moving, the chapter after chapter_y.tex, chapter_z.tex, failed when trying "jump to pdf"/"jump to source"

I have no idea why this worked, but solved the problem by including \clearpage before the failing chapter:

\documentclass[a4paper,norsk,11pt,twoside]{book}
\usepackage[utf8]{inputenc}
...
\input{chapter_x}
\input{chapter_y}
\input{chapter_z}


to

...
\input{chapter_x}
\input{chapter_y}
\clearpage
\input{chapter_z}


In my case, using \include{.}, instead of \input{.} for both the chapter preceding the problem chapter, and the problem chapter itself also worked, since

\include{.} == \clearpage \input{.} \clearpage


I'm using MikTex 2.9, Windows 7 32bit.

Hope this helps.

-