I had an idea this morning and would like to share and to know if someone has already developed it somewhere!

A Mozilla group is currently building a JavaScript Application able to transform any PDF code into HTML5, so you don't need any plugin to external PDF reader (Adobe, Evince, Xpdf,...). It is currently an extension, but may go in the browser kernel in the future https://github.com/mozilla/pdf.js.

Using that and an online text editor (codeMirror), some application of mine are running PDFlatex on server side...providing some (La)TeX online facilities. This is common.

What about having the same kind of JavaScript able to parse (La)TeX code directly and of course rendering a PDF ready for printout and page orientation on your screen? For the end user, it has a PDF Web browser but he has the (LaTeX) code when asking to view the source code. The final HTML5 code is not really seen except for debugging, and become like the assembly code in classical C development.

This would provide access to (LaTeX) source code of any scientific paper... rather to reinvent a Math formula and if I'm not wrong, This it IS the idea Knuth had few decades ago when building TeX. People should share (La)TeX code, not DVI, PS nor PDF code. The client browser (Firefox, Chrome, Opera, Safari and others) should handle PDFlatex process locally!

Let me explain my requirements another way;

I am working for the industry for 20 years and I use to use TeX and LaTeX at University like many of you I guess. Looking at our real main requirements in documentation systems, I think that Industry, at least critical embedded systems I work for needs:

  • A programmable document system; where you can can process customer requirements within informal English statements to derive and automate many things like requirement traceability, design doc, tests sequences,...

  • A very nice/professional rendering, perfect graphs, tables, diagrams...

  • Insurance that such document is such version and the content won't change. The Web does not provide some "digital signature/ digest" visible on print-out. The best "permalink","perma-content" system is the PDF format and that is why official documents are PDF (unfortunately, this is a not optimized format, but is it used every where you need static documents)

It is well known that PDF document produced from LaTeX satisfy really better those requirements than MS Word or other LibreOffice when only the latter are used in the industry.

What may change this approach is the arrival of "cloud computing", not a revolution idea by itself, but the fact that you are never Downloading files.

The jsPDF extension from Mozilla and the Chrome embedded PDF reader are making the first step, showing that PDF are really like other HTML pages (Google is also finding them) and this is very important for industry that requires those static (permalink/perma-content) documents.

Because best quality PDF are coming from LaTeX/TikZ source, it is now an opportunity to provide to the industry a real efficient document system on the cloud.

But if you (TeX experts) are fighting on such or such tiny advanced function for a variant of TeX, we won't have any chance to see a Web LaTeX and more important any chance to see LateX used in the industry one day.

You might be right to say this is impossible because of the complexity. I had exactly the same thought two years ago about a JavaScript PDF reader and it seems now that the result is being pretty good compared to Adobe native reader.

About JavaScript, I hate this language, but this is the only one supported client side.

  • 2
    Could you make the question a little more explicit please? At the moment, it doesn't really make a great fit for a question-and-answer site. There are quite a few questions already about other TeX implementations - you could take a look at those first as they probably answer the question "Is there a javascript implementation of TeX?" (and probably answer it "No"). – Andrew Stacey Aug 24 '12 at 11:36
  • 1
    I'm pretty not sure that it is possible to efficiently implement TeX translator in JavaScript. Just look at LuaTeX and its (rare but existing) problems with correct behaviour. – yo' Aug 24 '12 at 11:41
  • 1
    @tohecz But LuaTeX is not an implementation of TeX in Lua. However, I completely agree with your first sentence. Just imagine what fun one could have with \newcommand{\killyourbrowser}{\killyourbrowser}\killyourbrowser – Andrew Stacey Aug 24 '12 at 11:42
  • 1
    Looking at tex.stackexchange.com/q/18637/86 I would guess the answer is "No" (and I would take very seriously Herbert's answer to that question). – Andrew Stacey Aug 24 '12 at 11:46
  • 1
    @user1004847 But why would I want to? If there's source code, it would be simpler for me to download it and compile it on my laptop using genuine TeX. – Andrew Stacey Aug 24 '12 at 12:07

I do not want to spoil the fun, but there are some issues to consider.

  • LaTeX is just a macro format/package for the macro language TeX. But there are many TeX compilers:

    • TeX
    • TeX with e-TeX
    • pdfTeX
    • XeTeX
    • LuaTeX
    • VTeX
    • many other …

    A LaTeX file might depend on a particular compiler because it uses features of the compiler that are not provided by the other compilers.

  • I do not know a JavaScript version of TeX. Even the projects that tried Java have more or less failed (NTS, ExTeX).

  • There are other programs that might be needed to compile the file:

    • Index generation: Makeindex, Xindy
    • Bibliography: bibtex, bibtex8, biber, …
    • There is a shell escape feature that allows calling external programs.
  • A LaTeX file does not say, how it should be compiled, which programs are needed in which order, which arguments, how often, …

  • A "LaTeX file" can be organized in a master file that include other files, external images, …

  • Compiling LaTeX files usually require the possiblity to write and read auxiliary files.

  • Usually a LaTeX file need other packages, files, and fonts. Therefore you would more or less need a whole TeX distribution with its (daily) updates.

| improve this answer | |
  • 3
    regarding the need for other packages and files, rather often the need is for particular versions of those packages, so a continually -updated installation of tex itself is not necessarily appropriate for processing a random (la)tex source. – barbara beeton Aug 24 '12 at 12:16
  • 2
    At least there is a syntax for requesting a minimal version date for packages and classes. Also, remembering the generation of older LaTeX formats, there are files that can only processed at some period of time. – Heiko Oberdiek Aug 24 '12 at 12:50
  • 3
    @HeikoOberdiek: If the system resides in the cloud with access to all possible packages and sends to the client only the rendition of the (La)TeX source, most if not all of your concerns listed could be eliminated. The system should be able to automatically resolve errors and warnings, though, and be able to pick the correct TeX 'flavor' to compile the document. I contend, that's far from simple. It would blur the line between programming language and markup on which (La)TeX is currently saddled. – Count Zero Aug 24 '12 at 14:39
  • 1
    I feel compelled to mention that arXiv manages to figure out the correct engine to run on people's submitted TeX files. From logs I've seen, they simply try various methods, until one of them compiles without error. – Bruno Le Floch Aug 24 '12 at 17:17
  • 1
    Using pdflatex on a file with \usepackage[dvips]{color} also compiles without errors. There are only warnings Non-PDF special ignored!. Therefore it remains a non-trivial task. – Heiko Oberdiek Aug 24 '12 at 18:49

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