In the TeX output, say the DVI file, we can (I presume, though I don't know any details) find all the information about detailed placement and size of all the characters and diagrams. This is provided in a certain format, according to certain conceptual framework.
On the other hand, the web technologies, including javascript, can theoretically be programmed to respond to such instructions and recreate the same kind of control we get with PDFs, and even go beyond it.
What I wonder is: if we want this kind of inter-operability, what is the crux of the matter? Where precisely does the mapping have to be made?
Thanks for your 2 cents, I "ain't" asking for your "help".
Three things come immediately to mind: non-paginated layouts, immutable output, and tool support.
First, while most of the basic TeX algorithms for things like line-breaking and hyphenation could be implemented in terms of browser primitives, the overall TeX system is irrevocably page-oriented. While the maximum page length could theoretically be increased to "essentially infinite" through judicious widening of TeX's integer data types, this would break lots of TeX code and documents, for both performance and layout reasons.
Second, one of Knuth's main design goals for TeX was "perfect" backwards and cross-platform compatibility for documents, to the extent that he implemented everything in terms of integer math to avoid minor output variations due to slightly different floating-point implementations on various systems. If this is a design goal for a "drop-in" replacement system, it's not clear that the browser is a good target platform, because you generally want browser vendors to take advantage of things like hardware accelerated rendering that tend to be incompatible with "pixel-perfect" output for all permissible resolutions.
In both of the above cases, it's clear that lots of preparatory work needs to be done simply to understand what a high-quality platform for technical publishing in "native Web form" should even look like — but chances are good that it'll look quite a bit different than TeX, if only because the browser is quite a bit different than the printed page.
Finally, I use Emacs to write TeX documents and I rarely use any particularly sophisticated editor support beyond simple syntax awareness and highlighting — and I'm hardly alone. The fact that TeX is, like Emacs, largely implemented "in terms of itself" means that it's often more natural to implement automation in the document (where I include various third party packages in my definition of the "document", my point being simply that the document itself drives the automation at "runtime") rather than relying on powerful external editing and preprocessing tools. For authors like me who aren't professional Web designers and/or JavaScript programmers, the prospect of using anything related to HTML and DOM as bases for input and macros sounds like a nightmare. People commonly use TeX equation notation in plain text contexts, because, unlike SGML derivatives like HTML and MathML, TeX was designed to be written and (at least to some extent) read by humans. Again, there are lots of reasonable alternatives ranging from powerful editing tools that could potentially at this point be implemented in the same language as the document itself, which would have certain advantages, to extended versions of preprocessed input formats like Markdown. But again, it'd take lots of work to establish "one and only one" of these options as a standard.
Comments
In the TeX output, say the DVI file, we can (I presume, though I don't know any details) find all the information about detailed placement and size of all the characters and diagrams. This is provided in a certain format, according to certain conceptual framework.
On the other hand, the web technologies, including javascript, can theoretically be programmed to respond to such instructions and recreate the same kind of control we get with PDFs, and even go beyond it.
What I wonder is: if we want this kind of inter-operability, what is the crux of the matter? Where precisely does the mapping have to be made?
Thanks for your 2 cents, I "ain't" asking for your "help".
Three things come immediately to mind: non-paginated layouts, immutable output, and tool support.
First, while most of the basic TeX algorithms for things like line-breaking and hyphenation could be implemented in terms of browser primitives, the overall TeX system is irrevocably page-oriented. While the maximum page length could theoretically be increased to "essentially infinite" through judicious widening of TeX's integer data types, this would break lots of TeX code and documents, for both performance and layout reasons.
Second, one of Knuth's main design goals for TeX was "perfect" backwards and cross-platform compatibility for documents, to the extent that he implemented everything in terms of integer math to avoid minor output variations due to slightly different floating-point implementations on various systems. If this is a design goal for a "drop-in" replacement system, it's not clear that the browser is a good target platform, because you generally want browser vendors to take advantage of things like hardware accelerated rendering that tend to be incompatible with "pixel-perfect" output for all permissible resolutions.
In both of the above cases, it's clear that lots of preparatory work needs to be done simply to understand what a high-quality platform for technical publishing in "native Web form" should even look like — but chances are good that it'll look quite a bit different than TeX, if only because the browser is quite a bit different than the printed page.
Finally, I use Emacs to write TeX documents and I rarely use any particularly sophisticated editor support beyond simple syntax awareness and highlighting — and I'm hardly alone. The fact that TeX is, like Emacs, largely implemented "in terms of itself" means that it's often more natural to implement automation in the document (where I include various third party packages in my definition of the "document", my point being simply that the document itself drives the automation at "runtime") rather than relying on powerful external editing and preprocessing tools. For authors like me who aren't professional Web designers and/or JavaScript programmers, the prospect of using anything related to HTML and DOM as bases for input and macros sounds like a nightmare. People commonly use TeX equation notation in plain text contexts, because, unlike SGML derivatives like HTML and MathML, TeX was designed to be written and (at least to some extent) read by humans. Again, there are lots of reasonable alternatives ranging from powerful editing tools that could potentially at this point be implemented in the same language as the document itself, which would have certain advantages, to extended versions of preprocessed input formats like Markdown. But again, it'd take lots of work to establish "one and only one" of these options as a standard.