Possible Duplicate:
Is there any way to get real-time compilation for LaTeX?
I'm looking for an application in which I can write pure LaTeX in one half of the screen and on the other half to see the compiled document in real time.
This seems really like an obvious way to do LaTeX authoring but it doesn't look like any software is able to do it.
LyX is not what I'm looking for. I want to edit the actual LaTeX and see it rendered in real time. Why isn't this already being done somewhere?
BaKoMa TeX (no longer in development) does what you are looking for and is the only such solution that I know of. It does real incremental LaTeX compiling in the background, so it works with practically all LaTeX packages (e.g. those for complex diagrams). The LaTeX system itself is also quite good (e.g., it had early support for SVG).
It was originally only available for Windows, but nowadays there are also versions for Linux and Mac.
It is unfortunate that it is not free or open source, but for me paying the license fee is worth it. It is so superior to any other solution that I just can't imagine going back. As far as I know it is written by a single russian physicist, so I think the price is well justified.
Btw, I am not in any way connected to BaKoMa, just a very happy user.
fontspec package support for OpenType fonts and no UTF fonts. BaKoMa TeX development appears to have stopped in 2018.
I recommend latexmk which, with -pvc switch (for "preview continuously"), will recompile (as many times as necessary) whenever the source changes. If you have a pdf viewer that autorefreshes the pdf view (Skim on Mac OSX does this) then you can see a refreshed preview every time you hit save.
Using latexmk is nice even without the -pvc option since it automatically compiles (including bibtex) as many times as necessary.
Added: How to set up latexmk and Skim for near realtime LaTeX
Added: Here's something similar to latexmk, written in python: http://iml.univ-mrs.fr/~beffara/soft/rubber/. It doesn't seem to have anything like the "preview continuously" option, though that could be added with something like this: https://stackoverflow.com/questions/393176/monitor-a-set-of-files-for-changes
Realtime previewing (like StackOverflow does!) does not mean WYSIWYG. WYSIWYG means hiding the source from you so that what you are editing appears like the final output. Which, yes, for technical writing is a terrible idea. Seeing a realtime preview does not make LaTeX WYSIWYG -- you are still editing the plain text source. (Note that this is the way the StackOverflow editor works.)
I don't dispute that you should not typically worry about the preview. You could even argue against this feature on the grounds that it would encourage bad habits. I would actually argue the opposite -- seeing the choices TeX is making in realtime just reassures you that you can put the typesetting out of your mind and have faith in TeX.
In any case, there are plenty of times when you do need to care (like with messy equations, or in the final stages of editing when you're cleaning up bad line breaks and whatnot) and a truly realtime preview would save a lot of time.
\include.
May 29, 2016 at 4:41
Gummi is better than BaKoMa TeX. It is a free, open source, program written in python, featuring a live preview pane.
[ Edit: Gummi is currently maintained here: https://github.com/alexandervdm/gummi ]
Many PDF and DVI viewers update their display automatically when changes occur in the file they are displaying. So for example, one common way people use LaTeX is to have their LaTeX editor on one half of the screen, a viewer on the other, and hit "Typeset" on their editor every few minutes or so. It is possible to set up your system to allow clicking on a point in the displayed output to go to the corresponding point in the editor, and vice-versa.
Now what you could do, if you wanted to avoid the step of hitting "Typeset" every few minutes, is to have a script running in the background that simply compiled your LaTeX file every few seconds. You would have to keep the following in mind:
Compiling a LaTeX file can take a second or two, and can require more than one compilation to get all the references right.
If there is an error in the compilation step (as there is likely to be, e.g. when you have typed a "$" in your source file but not yet typed the closing "$"), you need to just abort the compilation (better is to start the compilation in -nonstopmode), and when there are errors, make sure the existing PDF/DVI file is not modified.
Barring these, such a script more-or-less works. (I had written and was using one long ago.) The output will be updated in almost less than a sentence's worth of typing time.
[Edit: As Stephan pointed out, "Textures" for OS X does this. its website says
we reintroduced the popular Traffic Light, the Textures facility that continuously shows you the TeX status of your documents while you type. If the light is green, TeX is happy; if the light turns red, there's a problem. As soon as you fix it, the light turns green again. (The light turns yellow while TeX is working, but Textures is so fast you'll rarely see it.)Also as he pointed out, it's not really all that useful.]
The reason I gave it up is because this is really not the right way of using LaTeX. The entire point of LaTeX is for you to not worry about the formatting when inputting the file; just type it in with the right semantic markup (paragraphs, sections, subsections) and leave the presentation up to LaTeX. Having to simultaneously worry about the presentation and content is extremely distracting and pointless; if you're going to do this you might as well use Word! The typesetting should be done only after you have a clear idea of what it is that you want to typeset.
To answer your second question:
because it is not the way it is intended to be used. LaTeX is not (!) a WYSIWYG-system. It is a document layout system. So you write your text (in a low end teletype-terminal) with some minor layout-directives, and someone else (the tex-subsystem on a high-end maschine) is producing (compiling) the ready-to-print Paper.
So you take your focus only on your content, not on the appearance.
The idea behind this is, that you are not as skilled in the art (!) of printing (setting letters) like a professional printer (the person, not the machine), so all formatting you do may be wrong in the sense of professionalism. Tex is implemented with the knowledge of a professional printer in mind.
In reply to ShreevatsaR observation that LaTeX is not wysiwyg and that simultaneously considering presentation and content is pointless, sometimes presentation and content are not separable: try entering a multi-line \equation that takes up a quarter page in a research journal with a two-column format, or entering a data table. Sooner or later you are going to have to fix those typos and will need to refer repeatedly back and forth between the presentation and content to get it right. Another place is where you have a page or word count limit and you are trying to juggle meaning and document length. I think being able to see immediately the effects of your edits is extremely useful.
That being said, judicious use of a makefile, xdvi or gv, and your favorite editor (mine is vim) makes the need for a separate program to accomplish a wysiwyg effect for LaTeX superfluous, as has been pointed out.
Being a vim user, I never used it, but there is an extension for emacs that does something like that and it's called preview-latex.
HTH
We had that on the mac before OS-X with Textures. It is of very limited use though. It is nice when experimenting with difficult formulas, but not when writing, as Shreevatsa already noticed.
The delay for compilation is not strictly necessary on modern machines, but that would need major surgery in the TeX engine.
You might want to take a look at TeXmacs, which is much more WYSIWYG.
I used to use whizzytex, a package for Emacs which uses advi to do the preview.
It has been in Debian and Ubuntu for quite a while now. It may not interact perfectly with all the LaTeX packages out there, but it does a good job of connecting your cursor in Emacs with the cursor in the preview pane.
It's true that this isn't a 100% WYSIWYG emacs editor, but it does provide real-time preview updates as you type, and the preview window is interactive. Just make sure that your LaTeX is always in a compilable state (YaTeX provides a set of macros the help maintain this property).
(I now just use emacs with YaTeX and the Evince pdf viewer which updates every time I save/compile)
TeXworks may be the solution you're looking for. It opens two windows: one is the text editor for entering your LaTeX code, the other is the PDF/DVI viewer that gets live updates. It can also use SyncTeX so that you can click in the PDF document and the text editor will jump to the code that generated that output you clicked on.
You can watch a video presentation of TeXworks from the TeXLive 2008 conference.
Because LaTeX for big(ish) documents takes at least a few milliseconds to compile. The best solution I've found (and what I'm using right now) is to use Kile and Quick Preview using (Alt-1) every few seconds. If you use evince or some similar DVI/PDF viewer, it will just update whatever page you're looking at, which allows me to make changes and see them almost instantly (almost real-time).
Lytha is absolutely right, but I've found it really difficult to learn the syntax of LaTeX without running the compiler a dozen times with all my (typically wrong) syntax to see the result.
LEd (http://www.latexeditor.org/) comes with split screen mode.
It's still not real time, but you can hit the compile key as often as you want ;)
Great idea. It's not ideal, but as people pointed out, it's possible to make something like this yourself. Here's what I did (and used for a while) on Windows:
What you need:
I used gVim as the text editor, latexdaemon as the compilation engine, and Sumatra as the PDF viewer.
In Vim, issue the command :au! CursorHoldI,CursorHold <buffer> silent! :update to make it auto-save the document every time you stop typing. Also :set updatetime=800 to set the timeout after which saving happens to a low value.
latexdaemon will auto-compile the document in an efficient way every time it's changed. Use the following at the beginning of the file to make it produce PDF:
%Daemon> ini=pdflatex
Or just start it with latexdaemon -ini=pdflatex.
Sumatra will automatically re-load the file every time it is changed, and it will not lock the PDF (so it can be recompiled without closing Sumatra first).
This recipe will give you an almost real-time preview, but it takes some effort to set up, and is not without issues. For example, you might not want to continuously auto-save, in case you'd want to revert to an earlier version.
There's a lot to improve on this, but I've been using it for some time (after reading your question), and thought putting the recipe out here might be useful for others too.
Since I was lazy, I just put everything to set this up into a .bat file:
@start C:\Path\To\Sumatra\SumatraPDF.exe %1.pdf
@start latexdaemon -ini=pdflatex %1.tex
@gvim -c ":au! CursorHoldI,CursorHold <buffer> silent! :update" -c ":set updatetime=800" %1.tex
I read an interview of Knuth a few years ago where he mentioned this sort of thing as his way of working. My vague and probably inaccurate memory is he'd edit the raw TeX or maybe Latex code in Emacs, keeping another window open with a viewer that'd get updated by a script that noticed when the source file changed. (C-x C-s rather than after every keystroke -- but still done often.)
Obviously this isn't a real answer to your question, but it's something to consider for the haters saying "Don't do that!".
WhizzyTeX with Active-DVI does exactly what you are looking for. Its website could be a little more clear about the functionality, but I've used it, and it works well. Also, despite looking a bit dated, it is actively maintained; the documentation was updated this week.
Not yet ready for prime time, but the Gliimpse project seems like a very promising way to handle the underlying problem (having the source code and the final result at the same time) in a very nice way.
Basically, the idea is that you press the alt-key in your editor, after which the editor transitions to the final (compiled) result, untill you release the key and go back to the Latex 'source code'.
The demo and video available on the page are impressive.
There's a nice post about it at the codinghorror blog.
Mostly nice answers. It was quite useful for myself. Just small comment about Kile and (Alt-1) (see above Stefan Mai). If I use (Alt-1) than later I have to use (Alt-Tab) to go back for editing. It is not really convenient. Better way is to put Kile on one half of screen (right|left) or (up|down). Put dvi viewer to another half of screen, then use (Alt-2). You will stay in Kile editor and dvi-viewer will be updated. It is real-time for me. Unfortunately it is useful only for Linux users. But I suppose something like this can be done in Windows with "Texmaker". P.S. Emacs is great for programming, LaTex and so on, but so difficult to learn.
look at texpad on http://new.math.uiuc.edu/math198/latex.html
Just use Emacs for Windows + latex-preview (auctex). It works for me :)
About the "non-wysiwygness" of LaTeX, may I point out a previous question and some of its answers, which raise some interesting points. (The link points now to an archived version of that page, which had since been closed and deleted as off topic, but contained nonetheless useful ideas.)
In particular, the fact that a LaTeX file is a logical, not a physical, description of the document you are composing leads to several useful features, outlined in the above question/answers: use of comments, indenting as a way to keeps things cleaner and more readable and so on, in a spirit not different from what is done in other languages.
That is a bad expect. because it's against to one of principles of TeX Systems:
Visual attributes must not be mixed with logical structure
you are looking for a semi-WYSIWYG System, like most of popular HTML editors. the WYSIWYG and LaTeX words are like Hokey and Figure skating :-) LaTeX and all of TeX-based systems cannot and do not want to be WYSIWYG.
In answer your second question, Why isn't this already being done somewhere? It has been done somewhere, quite some time ago. Check out Scientific Word, assuming you don't mind a commercial application. It may meet your needs, and they offer a 30 day trial version.
Note: I don't use this program myself, but I had heard seen it many years ago, and it does seem to meet your criteria.
As many of the other respondants have commented, it seems the majority of LaTeX users are happy enough without a real-time WYSIWYG editor.
