Thoughts on live previews in LaTeXila

Several years ago I talked about some principles for the user experience of LaTeXila, a GTK+ LaTeX editor for GNU/Linux. The conclusion:

The idea of LaTeXila is to always deal directly with the LaTeX code, while simplifying as most as possible the writing of this LaTeX code. The users don’t need to be LaTeX gurus, but they should understand what happens.

In my opinion this better follows the LaTeX philosophy than programs like LyX. By writing directly the LaTeX markup, you have full control of your document. The idea of LaTeX is to concentrate on the content and the structure of the document, not its layout.

With a live preview, you see constantly the layout… so you’re less concentrated on the content. As soon as something is wrong in the layout, you’ll want to fix it. This can lead to bad practices, like proceeding by trials and errors until the layout is good. LaTeXila tries to avoid that. As in programming, you should understand what you’ve written before the compilation or execution. You must be certain that the code is correct; if you have any doubts, the best is to read the documentation, this will save you time when you’ll use the same commands in the future.

Moreover, layout polishing should be done when the content is finished. For instance, it can sometimes happen that a word exceeds the margin, because LaTeX doesn’t know where to place an hyphen to split that word. It is useless to fix this issue when the content isn’t finalized, because if you add or remove some words in the sentence, the problem will maybe be fixed by itself.

Instead of a live preview, the workflow in LaTeXila is to compile from time to time the document (e.g. when you’ve finished a section) to re-read your text and check that the result is what you expected. A handy feature in that context is the forward and backward search between LaTeXila and Evince, to switch between the *.tex file(s) and the PDF at the corresponding positions, with a simple Ctrl+click.

But there are some special cases where a live preview can be useful, i.e. when more source <-> result cycles are required:

  • A PGF/TikZ figure preview, because in that case the layout is more important.
  • When we do something difficult, like writing a long and tricky math equation. But when it becomes difficult to find our way in the code, an alternative is to improve its readability, by spacing it out, adding comments to separate the sections, etc.

If you have other specific use cases where a live preview is really useful, I would be interested to hear them. I don’t think “learning LaTeX” requires a live preview, as explained above this can result in bad practices.

So I think a live preview might be useful for editing one paragraph. A live preview of the whole document is probably less useful. In any case, a live preview should be enabled only temporarily. In LaTeXila we can imagine doing a right click on a paragraph or TikZ figure, select the live preview in the context menu and we enter in a mode where only that paragraph (or selection) is visible, with the live preview on top/right/directly injected in your brain/whatever. Then when the writing of the tricky paragraph is finished, we return to the normal mode with the whole source content.

8 thoughts on “Thoughts on live previews in LaTeXila”

  1. Very nice idea! I agree completely that live-preview for the whole LaTeX document is unnecessary, but with this one-paragraph live-preview mode, I can already see typesetting tables becoming much less of a pain. That I think would be the biggest benefit for me personally — there are far too many times I have to shuttle between evince and LaTeXila to get a compicated table right. In addition, this will also help with environments like subfigure, to easy figure out the spacing between the individual figures and so on.

    Not to take the discussion completely off-topic, but I would also like to suggest that one unrelated feature that might be of great benefit is to suggest autocompletion in \cite and \ref commands using available tags from the bib file and \label items respectively. Texmaker [1] seems to do that, for instance.

    Anyway, keep up the good work, LaTeXila is already a pleasure to use!


    1. For the completion of the \ref and \cite commands, you’re lucky, three French students are working on it for a project for their courses. It’ll hopefully be done for the end of the semester in June (but the code will be merged only if it works fine and if the code has a good quality, of course).

  2. I mostly making presentations and making text fast. 70% of time I’m spending with playing with minted or other syntax highlighter to make my code in presentation more better to see.

    1. Yeah, configuring the packages is one use case where more source/result cycles can be needed. Maybe in this case a live preview of the whole document is useful. Or a more sophisticated way: select your source code, and ask to configure the preamble with live preview of the selected text. But it becomes a bit complicated, and clicking on the build tool button is not that bad.

  3. The proposed solution indeed seems to have the right approach, supporting LaTeX-coding, rather than hiding it from the user. Additional sections for which I see a use are title pages and tables. Then again it might be a feature to be executed on every certain section of code, although that could be considered feature bloat.

    In any case giving more direct feedback would certainly shorten the learning-cycle of the user, helping to overcome the learning-curve that LaTeX brings.

  4. I’ve switched to biblatex/biber for most of my work now. I found them to be easier to customize than original bibtex (e.g. have reference titles link to the EE/DOI/URL/ISBN) for convenience. If you e.g. prepare slides to distribute, you want the references to be clickable for your students.
    Please make sure that biblatex/biber is supported just like bibtex. They use the same .bib input; and essentially the same commands (cite, but also e.g. fullcite, citep etc.)

Leave a Reply

Your email address will not be published. Required fields are marked *