Re: [TUHS] TeX and groff (was: roff(7))

Blake McBride wrote in <CABwHSOuMxgEJnNUczbcGhA_939q_XfwCLyqacaGpz3+AjdSqSQ(a)mail.gmail.com>: |I've used nroff/troff/TeX with many of their various macro packages over |about a 35 years span. During that time, I've done many single-page |documents as well as documents as long as 350 pages. I also modified a |version of nroff to create business forms for Laster printers. This is |still being used commercially. This is one person's opinion: | |1. Perhaps owing to my limited intelligence, and in spite of the fact that |I've used TeX successfully on many documents, I have never been able to |fully understand TeX. Apparently, it is too much for me. Troff, on the |other hand, has made full sense to me. I was able to make it do what I |wanted almost always. I enjoy using troff more because I find it simpler, |and therefore, more pleasant to use. | |2. Looking at the output, it is my opinion that TeX produces |better-looking documents. Perhaps this is just no more than one man's |esthetic opinion. I do not know what it is that I find better. It's just |the sense I get. On the other hand, I find troff output to be sufficiently |good in nearly all cases. Note that heirloom doctools (on github) is a SysV-derived *roff codebase which has been extended to use TeX paragraph algorithm, font kerning, true type fonts, etc. You need to explicitly code your macros to use these features. |3. troff is a good and reasonable tool. TeX is too big and complex an |environment in most cases. Although it is true that all of the complexity |of the TeX environment is successfully hidden in virtually all cases. I |find the huge and complex environment offputting. That is overly not true. You can start off with nothing but what TeX loads by default, plus epsf.tex and maybe colordvi.tex for some use cases and you have everything you need. I have never used it, but there is kertex and i am tracking it since, eh, July 2012. It is maintained. It is just the bare core, but includes more than i ever needed #?0|kent:kertex.tar_bomb_git$ git loca|wc -l 20 #?0|kent:kertex.tar_bomb_git$ du -sh . 13M . |Very unfortunately, I see troff disappearing. I've worked with a number of |teams over the last ten years. In every case, I was the oldest engineer. |Also, in each case, I was the only engineer who had even heard of troff. |They understand the problems of binary formats such as Word and |OpenOffice. Their solutions are things like markdown, AsciiDoc, et al. |They are doing this development and making use of these tools without |knowledge of troff. The same is true to a greater or lesser degree with |TeX, except that I've seen TeX used at universities. | |I like that groff and TeX are rock solid and well supported. In fact, I |wrote a report generator for a modern web development framework using |troff. I use it to develop reports on a routine basis. (kissweb.org) |Sadly, however, if word of their existence doesn't get out there, I see |them both disappearing in not much longer than a generation. This would be |sad indeed. Gee, the current hip top of the pops is to not even include generated documentation in release tarballs no more! Heck, i even know a project that took a year-long-not-modified manual page and converted it into some so-called text format. It thus needs a software which happily announces itself as "ronn: the opposite of roff", yieha! I mean ruby ok, there are some such tools which require Haskell, which in turn requires a binary runtime package (or a huuuuge source ball). No no, really not. I mean really. You develop it, you decide it is time for a release, you do test the convertability do you, why not include the 10 kilobytes for your is-anyway-almost-a-stub manual?? In fact these balls nowadays include .github subirectories for github workflows, which is much larger than the manual. Sigh. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)