3 ms·

Let me be more clear: Long ago a friend kept suggesting that I write a converter from TeX (maybe also LaTeX) to HTML. I kept telling him that that was essenti

by graycat 12y ago

Let me be more clear: Long ago a friend kept suggesting that I write a converter from TeX (maybe also LaTeX) to HTML. I kept telling him that that was essentially impossible because TeX is a programming language, likely Turing machine equivalent, complete with if-then-else, allocate-free, file read-write, while HTML is just a text markup language. No doubt JavaScript is Turning machine equivalent, but I'd have a tough time believing that HTML is. So, my suggestion here was not to convert TeX input to HTML. Instead my suggestion was just to convert TeX output, that is, a DVI file, to HTML. Why? Because a DVI file is essentially just text, or, as I outlined, it specifies put this character at these coordinates on the page, put that character there on the page, go to a new page, etc. To be more clear, say, about the file reading-writing, that happens when the TeX program reads the user's TeX input and before the DVI file is generated. Given only the DVI file and displaying it, there is no file reading-writing. So, it looks like could convert TeX DVI output to HTML. You pointed out that maybe HTML with a browser has more flexibility than TeX output. Okay, maybe. But I didn't claim that, given an HTML file, there would be a TeX input file and a corresponding TeX DVI output file that my envisioned converter would convert to the given HTML file. Instead, I just claimed that for a given TeX and DVI file, the converter would generate an HTML file. Or the converter would be a function from the set of all TeX DVI files to the set of all HTML files. That is, for each TeX DVI file there would be a corresponding HTML file from the converter. But the function would not be onto the set of HTML files, that is, not all HTML files would be a value of the converter; not all HTML files could be obtained by using TeX input, the TeX program, the DVI file and the envisioned converter. You also mentioned some ways in which HTML, say, with <div>, is more flexible than TeX. Fine. But I was discussing just converting TeX DVI to HTML. And, again, I see no way to convert TeX input, which is a programming language, to HTML, which is not a programming language. Whew! More clear now?

Leszek 12y ago
The point isn't to convert a TeX program into an equivalent HTML program, it's to be HTML an output of a TeX program. For example, make \emph{foo} output "foo" instead of "/Times-Italic 12 selectfont (foo) show" or whatever the PS output would be.
- graycat 12y ago
 > The point isn't to convert a TeX program into an equivalent HTML program. You are correct, of course. And one of my main points is that such a conversion is essentially impossible. E.g., TeX can read and write files, but, thankfully for Internet security, HTML can't. So, my solution and envisioned converter is to convert TeX output in a DVI file to an HTML file. Such a converter seems doable and to solve a concern the OP had. Further, my envisioned converter from DVI to HTML would do just what you are describing. Or, the DVI file has to put the 'f' of 'foo' at some coordinates (x,y) on the page in some font, say, some bold font. Fine. TeX can handle lots of fonts, the many standard ones and more if want to make routine use of the ability of TeX to handle essentially any font given in the form TeX wants. Want to create your own fonts? Knuth has been there, done that, and left a terrific tool MetaFont, open source, beautiful documentation. Create all the fonts you want and have TeX use them. Then create equivalent fonts for HTML and that a Web browser can use. Such work with fonts is just making routine use of what TeX has had for decades. So, from the DVI, write to the HTML the markup string f at a position given by absolute coordinates while also specifying the desired font. That's about all there is to it. Seems quite doable to me. Want to convert to PS? Okay, from the times I read the big, red Adobe books on PS, converting from DVI to PS is also quite doable. Indeed, there is likely a TeX device driver for that conversion now, as there is from DVI to PDF -- which I use heavily. Indeed, checking, my script for converting DVI to PDF uses EXE I:\protex1p2_run\miktex\bin\dvipdfm.exe and that EXE is standard in the TeX world. It works fine.
 - Leszek 12y ago
 Any reasoning about TeX being able to do things that HTML can't is irrelevant. TeX -> PDF can be done without an intermediate DVI stage using pdftex. There could therefore be a similar "htmltex" which could directly convert TeX -> HTML. In the same way that pdftex has the advantage of knowing its output format (and can e.g. write pdf metadata), this hypothetical "htmltex" would know that its output is html, and could do things like allowing paragraph re-flow and embedding maths using MathJax. Of course, this wouldn't be easy, you'd likely need to fork TeX to implement it correctly (or only support a subset of LaTeX features like the current TeX->HTML converters), but it's far from impossible.

by graycat 12y ago

Leszek 12y ago

The point isn't to convert a TeX program into an equivalent HTML program, it's to be HTML an output of a TeX program. For example, make \emph{foo} output "foo" instead of "/Times-Italic 12 selectfont (foo) show" or whatever the PS output would be.

graycat 12y ago
> The point isn't to convert a TeX program into an equivalent HTML program. You are correct, of course. And one of my main points is that such a conversion is essentially impossible. E.g., TeX can read and write files, but, thankfully for Internet security, HTML can't. So, my solution and envisioned converter is to convert TeX output in a DVI file to an HTML file. Such a converter seems doable and to solve a concern the OP had. Further, my envisioned converter from DVI to HTML would do just what you are describing. Or, the DVI file has to put the 'f' of 'foo' at some coordinates (x,y) on the page in some font, say, some bold font. Fine. TeX can handle lots of fonts, the many standard ones and more if want to make routine use of the ability of TeX to handle essentially any font given in the form TeX wants. Want to create your own fonts? Knuth has been there, done that, and left a terrific tool MetaFont, open source, beautiful documentation. Create all the fonts you want and have TeX use them. Then create equivalent fonts for HTML and that a Web browser can use. Such work with fonts is just making routine use of what TeX has had for decades. So, from the DVI, write to the HTML the markup string f at a position given by absolute coordinates while also specifying the desired font. That's about all there is to it. Seems quite doable to me. Want to convert to PS? Okay, from the times I read the big, red Adobe books on PS, converting from DVI to PS is also quite doable. Indeed, there is likely a TeX device driver for that conversion now, as there is from DVI to PDF -- which I use heavily. Indeed, checking, my script for converting DVI to PDF uses EXE I:\protex1p2_run\miktex\bin\dvipdfm.exe and that EXE is standard in the TeX world. It works fine.
- Leszek 12y ago
 Any reasoning about TeX being able to do things that HTML can't is irrelevant. TeX -> PDF can be done without an intermediate DVI stage using pdftex. There could therefore be a similar "htmltex" which could directly convert TeX -> HTML. In the same way that pdftex has the advantage of knowing its output format (and can e.g. write pdf metadata), this hypothetical "htmltex" would know that its output is html, and could do things like allowing paragraph re-flow and embedding maths using MathJax. Of course, this wouldn't be easy, you'd likely need to fork TeX to implement it correctly (or only support a subset of LaTeX features like the current TeX->HTML converters), but it's far from impossible.