It's not a bug, it's just a missing feature. Originally the purpose of a PDF was just to emulate a printed page. Think of a PDF page as basically just a map with the exact location of certain characters. A PDF page doesn't even know where word boundaries are, much less paragraphs and columns. It is up to the artificial intelligence of the PDF software to recognize these things, but this is tricky business, and it's unsurprising that even the best PDF software does not always get this right. You may get different results in different PDF readers, however.
More recently, the notion of a "tagged PDF" has evolved, which allows for the insertion of 'guideposts' to help the PDF reader software understand the flow of text, so it doesn't have to rely so much on its own artificial intelligence. There have been some experiments in the direction of producing this with pdfTeX (see this question, but I don't think anything is quite ready for production-level work yet.
To launch from PDF the editor with an unrelated text file with specific options, probably you need do this indirectly.
- Create a script that launches all what you want (e.g. containing
gedit +42 file.txt
). Depending on the viewer file.txt
may need to be an absolute path.
- Link from TeX to that script (e.g. with
href
)
- The script extension (for example
.sh
or .mygedit
, rungeditfromline42.sh
or rungeditfromline42.mygedit
) must be among the executable mime types.
Depending on the viewer, one (or both) of the following points need to be set:
- (
Evince, Acroread
) The extension has to be associated with some type of execution of the script. One way I found for this is here (replacing Java with Bash): https://ask.fedoraproject.org/en/question/9735/how-do-i-launch-jar-files-using-nautilus/?answer=15275#post-id-15275 (I don't know of an automatic way of doing this).
- (
xpdf
) Make the script executable chmod +x rungeditfromline42.sh
.
- (No solution yet for
Okular
)
All that so that acroread
knows how to handle (in other cases, will be treated as any normal text). I also noticed that, for some reason, evince
requires the full paths (inside the scripts).
I tested this in Fedora 20. A similar problem is solved in http://latex-beamer-class.10966.n7.nabble.com/run-a-shell-script-from-a-beamer-generated-pdf-td2049.html. But the instruccions are not complete in my opinion.
EDIT 2015: How to make script extension to be associated with some type of execution of the script? (point 4 above)
(If this is step is not taken Acrobat or Evince might open the script file and not execute the script)
In ~/.local/share/applications/
create a file called run-gedit.desktop
:
[Desktop Entry]
Encoding=UTF-8
Type=Application
Exec=bash %f
Icon=icon
Name=run-gedit
Comment=Run the gedit file
From nautilus
right-click on the rungeditfromline42.mygedit
file (see above) and click the "Open With" tab, scroll down until you find "run-gedit" then click it and "Set as default". Go to Evince, click in the link to test that the script is run.
A loosely related note about SyncTeX
Since 2008 is possible to use SyncTeX
to allow synchronisation between the source and PDF files.
To enable synchronisation, SyncTeX creates an auxiliary file in the format filename.synctex.gz
.
Several LaTeX editors use SyncTeX by default. You do not need change the source .tex
file at all. For example in TeXWorks
you only need one rigth mouse click in the PDF viewer to open a menu and then choose go to the source code (to the lines that correspond to that is actually cliked in the PDF viewer), and with same procedure in the text editor you can return to the PDF viewer (showing the page that you are actually editing).
Best Answer
Big chars (characters with more than 8 bits) of LuaTeX/XeTeX are not yet fully supported. Workaround: