7

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.

user1004847
  • 79
  • Such a thing would come with a price: build time. Currently a typical 500+ book can take up to a few minutes to be built. That's not an acceptable waiting time for users. – raphink Aug 24 '12 at 11:34
  • 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
  • So yes, "Is there a PDFlatex implementation in Javascript" ? – user1004847 Aug 24 '12 at 11:42
  • 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 http://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
  • About 500+ book, you can do several HTTP requests and have cross references (index, bibTeX,...) not resolved at the first pass. You can imagine that the very first rendered pages are raw text. – user1004847 Aug 24 '12 at 11:49
  • 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
  • @AndrewStacey: I think the OP just means that: download the source and compile it locally, on your machine (or in the cloud, for that matter, according to the specs of your device and then serving the rendition of it), but 'in the background'. And I think he has a point there: LaTeX is in a way (but not only!) a kind of markup language. IMHO, while a laudable initiative, the huge ecosystem that was built around the original (La)TeX makes this task daunting if not impossible. – Count Zero Aug 24 '12 at 13:28
  • @CountZero The way I read it, the compilation would be done by a javascript program in the browser. That's not what I meant. I meant that I would download the code and run pdflatex what-I-downloaded.tex. LaTeX - or rather TeX - is not a kind of markup language. It is a programming language. That makes it a very different task than, say, converting Markdown. Moreover I disagree with your last sentence. I do not think this is a laudable initiative. LaTeX documents are source code. – Andrew Stacey Aug 24 '12 at 13:43
  • @AndrewStacey You are in the old paradigm of downloading other writers PDF and use pdflatex on your papers locally but it it usefulness on a cloud system. Unfortunately, other writers are never providing their LaTeX source code when it would be very useful...think of nice Tikz picture you want to reproduce. – user1004847 Aug 24 '12 at 14:40
  • Don't know what paradigm I'm in. Authors releasing their source code is very nice, but not essential and if someone doesn't do it then I don't hold it against them - I don't publish all mine because they can get very complicated and I don't want to be answering questions about them. If I see something I want to be able to reproduce, I ask. If I don't get an answer from the author, I ask here. But I'd rather just get the PDF and read it than mucking about with compiling others' source code. Just like I prefer to get a binary of a program than compile it from source. – Andrew Stacey Aug 24 '12 at 15:04
  • @AndrewStacey If your intention is "using" a program or just reading a PDF, OK the source code is not useful, but you might want to learn, test, copy from others code, and then having the LaTeX/TikZ code natively would be useful I think. – user1004847 Aug 24 '12 at 15:23
  • But this is a completely different set of circumstances to what you originally proposed. In the original, I would have to use your system to see the compiled document. Now, I could have the PDF and the source text both available and satisfy your requirements. – Andrew Stacey Aug 24 '12 at 15:40
  • @user1004847 At present, this looks more like a discussion than a question. Discussion does not fit the format here (somewhere like comp.text.tex might be more appropriate). That means this is likely to get closed, I'm afraid. – Joseph Wright Aug 24 '12 at 15:43
  • @JosephWright: Hmmm... too bad, this is really interesting, I like the idea of a universal TeX machine in the cloud, but I think I must agree, it's rather a discussion than a question. – Count Zero Aug 24 '12 at 16:51

1 Answers1

12

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.

  • …

Heiko Oberdiek
  • 271,626
  • 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