2

So I want to have a system where some user document is fully processed by TeX engine (full TeX engine!) and some data is collected to some helper file (saying "helper" just not make you think it's standard .aux file), which is then used for some processing of original document to produce standard (AMS)LaTeX which can be processed by something incapable of handling macros, like latex2html. What can I do if I want the user to have ability to define his own macros? What interface can I provide? What restrictions (i.e. rules to follow) on user macros are reasonable?

  • 2
    You'll probably want to provide a command that allows users to write out necessary definitions to the helper file, somewhat like the \addtocontents command allows insertion of arbitrary code to the .toc file. About restrictions, I doubt you can enforce any... but you could formulate rules about what is acceptable. – alexis Jan 25 '14 at 9:42
  • 1
    I suppose you could write a document class and require the users to (i) use that class in their \documentclass instructions, (ii) tell them that must refrain from any visual formatting in their documents, and (iii) tell them that any helper macros must be in the preambles of their documents. For this to have a chance to succeed, your document class will have to be well debugged, robust (& provide meaningful error messages if the user's document does something bad) as well as sufficiently rich to provide many of the macros that (more or less sophisticated) users tend to write for themselves. – Mico Jan 25 '14 at 10:06
  • @Mico Why (ii)? The thing is I can use data from my helper file (which is generated by full TeX engine, including stomach) to replace user macros to something standard. – Andrew Zabavnikov Jan 25 '14 at 10:39
  • Why (ii)? So that you won't need to spend a lot of time creating helper macros aimed at undoing whatever visual formatting instructions the users might be inserting... – Mico Jan 25 '14 at 11:33
  • @Mico Well I don't actually plan to undo them. Unless you are talking about visual formatting commands not supported by my minimal supported renderer (that's latex2html or MathJax - don't know for sure now), I plan to let user use them. – Andrew Zabavnikov Jan 25 '14 at 14:10
2

When a latex source gets processed, the structure information get's converted into a visual presentation, which is definitely not what you want (good luck trying to converting a pdf into html).

So you have to stop the process somewhere in the middle where it's still LaTeX code with presentation but all user macros were being expanded.

I think your questions can be answered best by showing how you could do this and show the limitations of the approach (there can only be less limitations):

\newcommand{\mysamplecommand}[1]{Look at this: \textit{#1}!}

\section{Sec}
Normal text, \textit{italic}, \emph{italic}.

\subsection{sub}
Math works too: $\sum_{x=0}^\infty 1+1$.

\subsubsection{subsub}
\mysamplecommand{It works}

into

\begin{document}
\par
  \section{Sec}
  Normal text, \textit{italic}, \emph{italic}.
\par
  \subsection{sub}
  Math works too: $\sum _{x=0}^\infty 1+1$.
\par
  \subsubsection{subsub}
  Look at this: \textit{It works}!
\par 
\end{document}

(line breaks inserted from me by hand for better readability)

The idea is to expand the tex markup and write it into a file.

\usepackage{newfile}
\newoutputstream{markupfile}
\openoutputfile{\jobname.markup}{markupfile}
\addtostream{markupfile}{\fakebackslash begin{document}}
\edef\markuptowrite{   <thecontent>   }
\addtostream{markupfile}{\markuptowrite}
\addtostream{markupfile}{\fakebackslash end{document}}
\closeoutputstream{markupfile}

Of course, <thecontent> has to be replaced by the content the user writes (like the code above). Note that \edef defines \markuptowrite to the expanded form of <thecontent> that is, it performs all possible macro expansions.

Now, the problems is that most macros get expanded to TeX primitives that are irrelevant (like kernings) and contain characters that can't be displayed.

Therefore, we want a set of primitives that aren't expanded, like \textit or \section so that latex2html can convert them to and .

\def\fakebackslash{(((fakebackslash)))}
\newcommand{\defmarkupprimitive}[1]{\expandafter\def\csname #1\endcsname{\fakebackslash #1}}
\defmarkupprimitive{textit}
\defmarkupprimitive{emph}

\makeatletter
\def\@startsection#1#2#3#4#5#6{\fakebackslash #1}
\makeatother

You would have to define a primitive for each macro that latex2html (or similar) knows of and that isn't a tex primitive. I guess this can be done in a smart way to reduce the amount of primitives like I did with \@startsection which works for section, subsection and subsubsection.

We use \fakebackslash for a \ that doesn't introduce control sequences. This could maybe be done in a better way, but the only thing left is a simple string replacement of (((fakebackslash))) into \. So the real output of the first example is

(((fakebackslash)))begin{document}
 \par (((fakebackslash)))section{Sec} Normal text, (((fakebackslash)))textit{italic}, (((fakebackslash)))emph{italic}. \par (((fakebackslash)))subsection{sub} Math works too: $\sum _{x=0}^\infty 1+1$. \par (((fakebackslash)))subsubsection{subsub} Look at this: (((fakebackslash)))textit{It works}! \par 
(((fakebackslash)))end{document}

which can than easily passed to sed and latex2html to produce the final html.

This output is partially processed latex. Expansion has stopped at our self-defined primitives which is what the converting program should be able to understand.

The user is able to write all sorts of macros (abbreviations, counters, etc); as long as they finally boil down into our primitives, everything works fine.

We could also add a \rawhtml primitive that protect it's input from being processed by latex2html and if -shell-escape is allowed, the motivated user would be able to write macros that convert write tikz pictures into standalone tex files, convert them into pdfs and then pngs and include the png with the \rawhtml.

Basically, with this approach there is no limit for the user. If you're lucky, the primitives could be chosen in a way that every package works out of the box. However, I suspect lots of them would be broken, as many raw formatting commands are meaningless in html.

Nevertheless, if you wan't to do try that for yourself, I think it's possible to provide a reasonable implementation that works for most parts of LaTeX.

  • Actually there is quite a limitation in your approach - some macros cannot be fully expanded. For example, \def\abc#1{\ifx\empty#1\empty a \else b \fi}. – Andrew Zabavnikov Jan 25 '14 at 16:10
  • So my idea was to let macros execute in full, but let them write some info to helper file. After that with that info some (maybe external) processor should have an opportunity to replace these macros with what they desired to be replaced when writing to helper file. – Andrew Zabavnikov Jan 25 '14 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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