I'm in a bit of a sticky position having to introduce several people to work that is inherently harder than what they are going to be comfortable with. I would like to ease this transition my making smart choices in the software I sit them down at. I am not in the position of being able to force the usage of any particular software, but I am in a position of being personally responsible for the final product, so the more effective I can make others involved in this workflow the less work I will have to do myself.

The most basic need is for a LaTeX editor that won't frighten the children. I have a handful of authors as well as a couple of translators and proof readers that are busy generating content. To date, this has been done mostly in Word. Files have been passed around by email and USB stick. Losing track of who has the latest version or making edits to an old copy and thus jinxing the work done seems to have been a pretty regular thing. As a result the folks have become protective of their computers and their roles, each trying to act as the "canonical" holder of the "latest" Word files. Of course these attitudes didn't actually solve the problem, but they will make it hard for me to introduce a better workflow (at least for the first project or two).

When a piece does finally survive this tormented upbringing and is ready to be published it gets sent to a print house as Word files. There some poor bloke gets to convert it all to a printable format, re-typeset the whole thing (the quality of which varies greatly) and send it to press. Unfortunately the final editing, conversions and typesetting often never make it back down the chain so even as the author/copyright holder we don't have a final digital edition that could be re-published; it would need to be hacked on again. This seems "easy" to the authors and translators who get themselves off the hook early in the cycle, but the end result is a tangled web of obsolete projects that don't provide ongoing value beyond one printing.

I'm now in the process of taking over some of those final steps. In order to make then sane, I'm trying to recommend a change in usage all the way up the chain. The short version is that I want all content authored (or translated) directly into LaTeX files out of the gate and all file handling to be version controlled in Git. Unfortunately I am well aware that the intricacies of both technologies will probably be considered black magic by most people involved in these projects. This puts me in a position of both teaching and supporting whatever solutions I recommend.

Barring somebody whipping out an integrated package with a workflow that rolls out the red carpet, my plan is to limit the workflow (for everybody but myself) to three pieces of software: a git repo manager, a text editor with some LaTeX smarts (and a PDF viewer), and some sort of project management software for coordination. The first will probably be Gitbox and the latter likely Gitlab. That leaves me looking for an editor to recommend. The basic requirements are:

  • Most of these people use OSX, so I would prefer something that is native to that platform, not just in the look of the widgets but that provides an overall usage pattern that won't be too alien to the sort of folks who don't venture outside that ecosystem.
  • The interfaces should be low clutter and conducive to use by writers/translators that need to enter large amounts of copy without stopping every minute to make sure the "code compiles."
  • The file handling should be intuitive enough that if I setup repo-per-book git workspaces they can easily create and edit either a master or per-chapter *.tex files without worrying about the *.sty or whatever other things I put in there to make a book out of the mess.
  • A minimum of LaTeX syntax aides should be available. Ideally if there are toolbars or whatever these could be customized by me in getting them setup such that just the markup options they needed would be available:
    • Chapter and section headings
    • Block-quoted sections
    • Footnotes
    • Bold/italic emphasis
  • Some sort of basic preview. This may or may not be the output of a full LaTeX compile run but should provide enough visual feedback that they can feel confident they are entering the data correctly.
  • Handle non-English text encoding. A Turkish localized UI would be ideal but not required as most of my users can deal with English. What is required is that the editor doesn't choke on non-English input data, which will be almost exclusively Turkish. The files will need to be UTF-8 encoded (and compiling will be one of LuaLaTex/XeTeX).

Is there a native OSX editor that fits these requirements? If not, what comes closest given the usage goals? Is there some other solution I should be looking at instead (e.g. authoring in Markdown and converting later with pandoc or using a collaborative web based LaTeX editor and instead)?

A FOSS solution would be awesome but I'm mostly looking for a pragmatic solution. Of course cheaper is better, but I'm also willing to pay up some cash for a solution that will get the job done better and/or make me fewer enemies!

2 Answers 2


Personally I would suggest:

  1. Use (pandoc extended) markdown for the actual files and pandoc to produce the final output - this will handle UTF-8 with no problem and gives you the option of multiple output formats. The pandoc extensions to markdown support
    • document metadata (title, author, date);
    • footnotes;
    • tables;
    • definition lists;
    • superscript and subscript;
    • strikeout;
    • enhanced ordered lists (start number and numbering style are significant);
    • running example lists;
    • delimited code blocks with syntax highlighting;
    • smart quotes, dashes, and ellipses;
    • markdown inside HTML blocks;
    • inline LaTeX.
  2. There are a great many markdown editors, some with preview, many free, or, of course, the individuals can use their favourite plain text editor, as long as it outputs plain UTF-8 files.
  3. Use mercurial rather than git - I generally find it to be more user friendly.
  4. Having a pre-commit render and view with a proceed/cancel button should be relatively simple to implement.
  5. Ditto - pre push.
  6. You could even consider either a post push hook or a jenkins server building all your chapters at the current status to a location that all of your team can view.

The following are points to consider:

  • All the above are FOSS tools so the costs are minimal.
  • Markdown is human readable - a lot easier than LaTex/
  • Markdown is more VCS friendly than many other formats.

Another possibility if you cannot weed your contributors from Word is to use Mercurial with the zipdoc extension. This would atleast let you VCS word documents.

  • 2
    Thank you for the insights. I will definitely take a serious look at pandoc and its Markdown implementation as that sounds promising. Teaching Markdown is ever so much less likely to make me enemies than teaching LaTeX! I think I'll stick with Git as I'm already live and breathe Git and will be much better able to support it. The pre/post commit/push hooks to automate the flow are spot on though; in fact I had something similar in mind.
    – Caleb
    Nov 6, 2014 at 6:41

You mentioned toward the end that you're at least open to the idea of Web-based collaborative editing, so in case you haven't already checked it out, I recommend writeLaTeX.

It offers (to my taste) a good balance of ease of use for the TeX-uninitiated (which includes me) and genuine LaTeX capabilities. It can be used as a browser-based editor with real-time preview and relatively basic cloud-based storage and collaboration for free; more advanced project management features are available at relatively low cost.

My introduction to this site/service was a Hacker News post linking to this writeLaTeX blog post on their (at the time new) Rich Text mode.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.