Donald E. Knuth's TeX outputs .dvi files.
Hàn Thế Thành's pdfTeX outputs .pdf files.
Is a program rtfTeX or docTeX or docxTeX conceivable that instead of .dvi or .pdf directly outputs Word .rtf or .doc or .docx files?
If not: Why is it impossible? Is this impossible due to the characteristics of the output formats in consideration, so that it is not worth thinking further into this direction?
Are there issues regarding output formats like rtf/doc/docx being proprietary?
Donald E. Knuth's TeX outputs .dvi files.
At the suggestion of Ulrich D.:
There are several issues. The the most basic level, which Ulrich already discussed, is the problem of workflow. But even if that is not the issue, there is the difficult problem of syntax. TeX is primarily intended for mathematics. Word processors are not. Visualize a conversation between someone doing Algebraic Topology, and someone doing Postmodern Deconstruction of literature. The underlying terminology is very different. You cannot "convert" between them.
If you use TeX only for literary work, where that markup involves little other than the occasional large type or Italics, then it is reasonable to strip a few standard TeX macros, and insert XML. And if you have XML with a very limited style sheet, it might be possible to strip the XML and insert TeX markup. I believe this has been done, with unknown (to me) results.
But that is not good enough. Going from TeX to XML would require using only a very limited number of TeX macros, in very limited contexts, and without custom macros. Going from a word processor output (which may be XML) is headache, because the XML is far more complex that it needs to be. For example, take what is probably the simplest word processor, AbiWord. Its native *abw format is XML, and can be read as plain text. Yet it is mind-boggling, even for a simple "hello World" text document.
And in the end... Even if all that could be done, the printed results would differ. TeX (and its varieties) and the various word processors use algorithms for determining exactly where each character will be printed on a page. The algorithms differ, and are likely to be proprietary. So, the printed results will look different, possibly even with different paragraph breaks and pagination. It gets worse,if there is active content (links, etc.) or forms.
Your best bet is to manually strip TeX code from a document, and send plain text. Have the word processor export as plain text.
Comparison: Hello, World.
Plain text: 14 bytes, including the final line ending.
AbiWord document, readable as plain text XML: 2468 bytes.
HTML, as exported from AbiWord (with styles): 1416 bytes.
HTML, above manually edited to minimal markup, no styles: 253 bytes.
Rich Text Format: 2472 bytes.
PDF from AbiWord: 5561 bytes.
Ultra-minimal helloworld.tex: 70 bytes.
Above compiled PDF: 3390 bytes.
About twenty five years ago I thought about this, too, and came to the conclusion that the benefits would be limited:
Word processors provide for input, editing, formatting, and output of text.
Thus, input file and output file is the same with word processors. Input/output files of word processors (.rtf/.doc/.docx) are to be edited directly, using the word processor.
TeX is not a word processor. TeX is a typesetter and provides for input (in the sense of reading .tex input files), formatting and output of text, but not for editing. Input file and output file is not the same. TeX's output files (.dvi/.pdf) are not intended to be editable directly easily by the user. Instead, one edits the .tex input file and (re)compiles.
These two workflows are not that compatible:
Assume two people work on the same project.
One of them uses the hypothetical program docxTeX and edits .tex input files and (re)compiles to get .docx output.
The other one does not work with .tex input files but edits the .docx files in a word processor like Libre Office or Word or whatever.
The other one's changes to the .docx files will not be reflected in the .tex input files.
Thus the .tex input files and the word files are easily out of synchronization.
So back then I came to the conclusion that thinking about the question whether implementing such a program is feasible is not worth it due to the incompatibility of the two workflows of modifying the content of the final output files.
|||Wikipedia contributors, "Word processor," Wikipedia, The Free Encyclopedia, https://en.wikipedia.org/w/index.php?title=Word_processor&oldid=1175641306 (accessed September 21, 2023).|