The primary concern of this platform is rendering on the Web, \TeX\ already handles rendering to PDF and paper. The primary duties include controlling the DOM and DOM events, and also managing and multiplexing environments into their respective rendering hierarchies


The platform calls MathJAX on the pieces it wants to, but not on all parts, and also prepares \TeX\ items for MathJAX that it would not normally render without some modification.


\begin{center}
\begin{pspicture}(0,-1.5)(12,3.5)

\rput(1.5,1){\LaTeX}
\rput(4.5,1){Parser}
\rput(7.5,1){Renderer}
\rput(10.5,1){HTML5}

\rput(6,2){LaTeX2HTML5}
\psframe(3,-0.5)(9,2.5)


\psframe(0.5,0.5)(2.5,1.5)
\psline{->}(2.5,1)(3.5,1)

\psframe(3.5,0.5)(5.5,1.5)
\psline{->}(5.5,1)(6.5,1)

\psframe(6.5,0.5)(8.5,1.5)
\psline{->}(8.5,1)(9.5,1)

\psframe(9.5,0.5)(11.5,1.5)


\end{pspicture}
\end{center}

The parser generates the various environments after parsing the \TeX, and the renderer manages views that generate HTML, CSS, and JavaScript to create interactive content on the fly.


{\bf This is done completely in the browser}, no server-side rendering is required. The server is purely used to store \LaTeX\ in a database.

How it works

The code was designed to have extendability, and uses a basic parsing and evaluation model. Every command has a hash that references a regular expression in the {\tt Expressions} object defined in {\tt expressions.js}, and a function in the {\tt Functions} object also defined in {\tt expressions.js} for what to do once the expression matches. 


To add new commands, you can simply add a new regular expression inside the {\tt Expressions} object, and a match function in {\tt Functions} object of the same hash name. If you defined a new command to be evaluated within a PSTricks environment, then you should also add a graphing function inside of {\tt psgraph.js}. If you want to add a new environment, then you can add a regular expression to the {\tt Delimiters} object in {\tt expressions.js} and add a new block inside of the {\tt renderer.js} file's {\tt beforeRender} method.


The parser located in {\tt parse.js} chops and dices all text into an array of lines using the newline character as the delimiter. This is a very simple model for parsing, as it enabled focus to be on the commands instead of writing a full grammar. Writing a full parser would be ideal for future versions to be able to properly parse multi-line environments that use opening braces '{' and closing braces '}' on separate lines. 


After the parser creates an array of text it passes all the lines through the defined regular expressions, first parsing any text-based expressions primarily for \TeX\ commands, and then parses more advanced expressions such as PSTricks variables and expressions as they are defined within their respective environments.


The parser instantiates and manages environments during parsing, and creates new environments packing them with state when any delimiters are detected, which are also defined as regular expressions inside of {\tt expressions.js}.


Each environment has its own execution context, and a hash of matched objects that map to \TeX\ commands. It also stores the intial settings, which can be modified during evaluation. When the match functions are called, they are given the context using the JavaScript {\tt Function.call} passing the context to be evaluated for {\tt this} object. The reason for this is to properly address coordinate transformations, which requires access to the current environment's variables and context and is at the core of the platform.
 

Certain expressions can modify the current environment variables and settings, so that during evaluation, the graphics and text can update accordingly. Some commands that modify the environment are {\tt pspicture} and {\tt psset}, because they define the size of pictures and units or dimensions. 


Expressions and Parsing

The renderer contains a set of view objects that inject themselves with subviews that are rendered in specific ways depending on the environment. After the parser is complete, it then passes the completed objects into the renderer's main view, called {\tt TEX} located inside of {\tt renderer.js}.


Upon initialization of the {\tt TEX} view, it stores the current scroll position of the document, to enable flawless real-time editing upon re-render, which we will discuss more in detail later. Once the {\tt TEX} view's {\tt render} method is called, this triggers the {\tt beforeRender} method, which multiplexes the injection of various views depending on the environment, and passes in the appropriate contexts. 


It is within these subviews where the magic happens. The view associated with a {\tt verbatim} environment will wrap the text in {\tt pre} tags, for example, and the view associated with the {\tt enumerate} environment will iterate over the items and generate the HTML elements {\tt ul} and {\tt li} to render lists.


The views have access to their representation in the DOM via a variable {\tt this.el}. The math environment will simply make a call to MathJax in its {\tt afterRender} method. This method means that {\tt this.el} exists in the DOM, thanks to the layout manager. The view specifically calls the MathJax {\tt Typeset} method for {\it only} that DOM element. This controls the rendering so that we do not attempt to render the entire page, which we do not want. It is this fine grained control that enables the system to function as expected. 


The more advanced view is probably for the PSTricks environment, however. Upon initialization, the PSTricks view will store a reference to the environment and execution context that was passed in. It then creates a new SVG element based on these parameters, and then registers touch and mouse events that call a user event function to trigger re-rendering of various graphical elements when the user interacts with the SVG.


In the PSTricks view's {\tt afterRender} method, it iterates over all objects that are not {\tt rput} first, rendering those using the graphing function that matches the hash inside of the {\tt psgraph.js} file. For example, a {\tt psline} expression that may be defined in the {\tt Expressions} object inside of {\tt expressions.js} corresponds to a {\tt psline} function defined inside of {\tt psgraph.js}. So the corresponding graph function is called, and the context of the environment is passed along, as well as the reference to the SVG element. 


The various functions within the {\tt Functions} object inside of {\tt psgraph.js} contain the drawing commands for the respective PSTricks commands. Most employ turtle drawing to create {\tt svg:path} elements using notation such as: 

\begin{verbatim}
M 0 150 L 0 3 4 5 6 6
\end{verbatim}
What this means is move to position {\tt (0,150)}, then draw a line to {\tt (0,3)}, then draw a line to {\tt (4,5)}, and so on. Then the associated styles and settings are applied, for example, if there is a fillcolor or a stroke width specified. 


Before the {\tt afterRender} method is complete, the {\tt rput} elements are ``absolutely relatively'' positioned on top of the {\tt this.el} which is enabled because it's parent's {\tt width} is set, and it
s parent's {\tt position} is set to {\tt relative}. The {\tt rput} method defined in {\tt psgraph.js} generates a new {\tt div} element, and sets the CSS properties to be {\tt position:absolute}, and {\tt top} and {\tt left} properties mapped {\tt this.x} and {\tt this.y}, which are the transformed coordinates specified form the original {\tt rput} command written in text. The second to last step is calling the MathJax {\tt Typeset} method on the DOM element for math rendering.


Because {\tt rput}'s definition is that it is centered at the specified position, and we require the MathJax rendering to be complete to get the width of the resulting div element, we use a {\tt setTimeout} of 0 milliseconds, which is a trick to get access to the DOM element during the next repaint of the browser. Think of it as an {\tt afterAfterRender} method. If this code could be included in the MathJax library, perhaps this step would be unnecessary. It is in this critical step where we get the width and height of the div, and offset the {\tt top} and {\tt left} CSS parameters by half of the height and width respectively. 


In totality, this system of managing the rendering of DOM and SVG elements enables us to fully control the rendering of math and any related graphics or diagrams, so that they can be rendered on the Web, and match those graphics that are output to PostScript, PDF, or paper. 

Rendering and Graphing

A core component of the platform is coordinate transformations. \TeX\ has its own coordinate system, as well as the {\tt pspicture} and {\tt psset} commands, which can modify the coordinate systems. The Web has a system for describing the DOM elements on the page, and even the SVG element that we use to render graphics has its own local coordinate system for describing the graphical elements that it contains. Touch and mouse events from user input are associated with these coordinate systems, and it is the harmonious transformation between the various coordinate systems that enables the flawless rendering of mathematical diagrams and figures. 


A change of coordinates is required to map PSTricks code to the SVG coordinate system, as well as inverse transformations to go from SVG back to PSTricks in the case of user mouse or touch events.


If you recall, we store an execution context within each environment. This also contains references to the scale of the current environment, which can be manipulated using {\tt pspicture} and {\tt psset}. 


The transformations are as follows:

\begin{nicebox}
Let $X$ be the transformation function that maps a x-coordinate $v$ from PSTricks $\rightarrow$ SVG:
	$$
	X(v) = \left( w - \left( x_1 - v\right)\right) x_{unit}
    $$
\end{nicebox}


\begin{nicebox}
Let $X^{-1}$ be the transformation function that maps a x-coordinate $v$ from SVG $\rightarrow$ PSTricks:
    $$
    X^{-1}(v) = \frac{v}{x_{unit} - w + x_1}
    $$
\end{nicebox}


\begin{nicebox}
Let $Y$ be the transformation function that maps a y-coordinate $v$ from PSTricks $\rightarrow$ SVG:
	$$
	Y(v) = \left( y_1 - v \right) y_{unit}
	$$
\end{nicebox}


\begin{nicebox}
Let $Y^{-1}$ be the transformation function that maps a y-coordinate $v$ from SVG $\rightarrow$ PSTricks:
	$$
	Y^{-1}(v) = y_1 - \frac{v}{y_{unit}}
	$$
\end{nicebox}

The values {\tt this.x1}, {\tt this.y1}, {\tt this.xunit}, {\tt this.yunit}, {\tt this.w}, {\tt this.h} are associated with every PSTricks environment. The $x_{unit}$, which corresponds to {\tt this.xunit} is the amount the diagram gets scaled in the $x$-axis. The same true for $y_{unit}$ in the $y$-axis.


Note that if an author uses the {\tt psplot} environment with any interactivity, we must first apply an inverse transformation, apply the function, and then apply the transformation function to get the accurate values. 


The two X transformation functions utilize {\tt this.w} which represents the width of the graphic which is determined by {\tt psset} and {\tt pspicture}. However, because of the CSS positioning, the height is irrelevant in these calculations. 

Coordinate Systems

As soon as information is digitized today, it becomes a sequence of bits that by the nature of the operating system can be copied very easily. To address the digital rights issues associated with digital publishing, this platform has taken a few steps. 


Every page is dynamically generated after the first HTML page is served to the client. The JavaScript that is included in the HTML page generates a series of interface components on the client side to render the page. If somebody tried to view the source of a page, they would not get any information about the book, whatsoever. They also do not get any access to the \LaTeX. 


You would have to know quite a bit about networks to get access to the source of the book. Every page is sent to a client via {\it Secure Sockets Layer} (SSL), a cryptographic protocol, over a Secure HTTP connection (HTTPS).


Last but not least, authors can make their writing public or private. Private books will only be viewable by the author themselves, or by any authenticated users that have permissions. Readership and authorship permissions are stored in the database, and enable an author to create a white-list of readers or collaborative authors. 


\begin{print}
\begin{center}
\includegraphics[width=300pt]{images/public-private.ps}
\end{center}
\end{print}
\begin{interactive}
\img{/app/assets/paper/public-private.png}
\end{interactive}

Privacy and DRM

Often, rendering graphics is a very disconnected process from the editing of the \TeX\ source. First, the author must write or edit a .tex file, that contains the source to generate the graphic, usually describing the digram using PSTricks or TikZ. The author then runs a series of commands to generate a PostScript or PDF file, which they can then open to preview the results. For example, to render a latex document often requires use of terminal and you may use these commands:

\begin{verbatim}
latex paper.tex
dvipdfm paper.dvi
xpdf paper.pdf
\end{verbatim}
That required {\it three} steps in order to view the actual graphic. But that is not the only step required by the user. They also have to context switch between the text editor and the terminal and the graphics display program. The process then becomes more fragmented. Here is a graphic where each arrow represents a context switch:


\psset{unit=1.5cm}
\begin{center}
\begin{pspicture}(-1,-2)(6,2)

\rput(0.5,0.5){text edit}
\rput(2.5,0.5){compile}
\rput(4.5,0.5){preview}
\rput(2.5,-1.25){repeat if needed}

\psframe(0,0)(1,1)
\psline{->}(1,0.5)(2,0.5)
\psframe(2,0)(3,1)
\psline{->}(3,0.5)(4,0.5)
\psframe(4,0)(5,1)
\psline(4.5,0)(4.5,-1.5)
\psline(4.5,-1.5)(0.5,-1.5)
\psline{->}(0.5,-1.5)(0.5,0)


\end{pspicture}
\end{center}

The user has a series of steps within these contexts:

\begin{enumerate}
\item switch to text editor
\item edit the .tex
\item switch to terminal
\item run {\tt latex} command on .tex file
\item run {\tt dvipdfm} command on generated .dvi file
\item open preview the pdf
\item if the graphic is incorrect, repeat
\end{enumerate}


\psset{unit=1cm}
\begin{center}
\begin{pspicture}(0,0)(9,2)

\rput(1.5,1){.tex}
\rput(4.5,1){.dvi}
\rput(7.5,1){.pdf}
\psframe(0.5,0.5)(2.5,1.5)
\psline{->}(2.5,1)(3.5,1)
\psframe(3.5,0.5)(5.5,1.5)
\psline{->}(5.5,1)(6.5,1)
\psframe(6.5,0.5)(8.5,1.5)

\end{pspicture}
\end{center}

This process takes anywhere from seconds to minutes. If the user must make a change, they have to repeat the entire process which can be frustrating. How can we minimize amount of time and space it takes to render a document? Enable real-time editing and preview.

\begin{interactive}
\img{/app/assets/paper/realtime.png}
\end{interactive}
\begin{print}
\begin{center}
\includegraphics[width=300pt]{images/realtime.ps}
\end{center}
\end{print}

This platform provides an editing experience where the text editor and preview are on the same page, hence, updates appear in real-time within the same context. The real-time authoring aspects allow a user to get instantaneous feedback while creating these diagrams, and making changes becomes simple and the results are displayed right away. 


The user interface continuously evolved. At first, there was a text box that would scroll off the page as you scrolled down the preview content. It make it extremely hard to edit continuously. Then I created a fixed position text area, but then every re-render initially caused the page preview to scroll to the top of the page, so to mitigate this, at the initialization of a {\tt TEX} view, the platform stores a reference to the scroll height and repositions the window accordingly, so the user doesn't have to re-scroll the window to the point of interest. In fact, the experience is seamless now. You can scroll through the text and the preview independently on the same page while editing in real-time. 


Another issue was using {\tt keyup} events to trigger a re-render. Every time the user would type in the text editor, the page would re-render sometimes causing a lag for larger pages. A way to fix this was to use throttling. The framework stores a reference to an id that points to a callback function supplied by a {\tt setInterval} function that has a value of 500 milliseconds. Basically the system then only calls the function every half second, and only then. If a new {\tt keyup} event occurs, it only adds a callback if there isn't a reference to one already. This ensures a streamlined editing experience for the author.


Optimizing the Editing Flow

\begin{nicebox}
The purpose is to create a {\it beautiful} pages, whether on paper or the Web
\end{nicebox}

Using two standards, HTML5 and \TeX, we were able to produce a consistent look and feel across all devices, including paper:

\begin{interactive}
\img{/app/assets/paper/results.png}
\end{interactive}

\begin{print}
\begin{center}
\includegraphics[width=400pt]{images/results.ps}
\end{center}
\end{print}

8 LaTeX2HTML5