From mboxrd@z Thu Jan 1 00:00:00 1970 From: gtaylor@tnetconsulting.net (Grant Taylor) Date: Mon, 4 Sep 2017 20:42:00 -0600 Subject: [TUHS] Introduction to {t,r,g}roff & co... In-Reply-To: <20170905021957.GF14353@mcvoy.com> References: <55023784-D0BB-48FF-9337-0C070FD02CEC@orthanc.ca> <20170905021957.GF14353@mcvoy.com> Message-ID: <65f82734-df50-2d7f-3e67-37f5eaefbcb5@tnetconsulting.net> On 09/04/2017 08:19 PM, Larry McVoy wrote: > Hi Grant, Hi Larry, > Somehow I missed your initial email, time to check my spam filters > I guess. Ah, spam filters, the never ending battle. I've been doing that for ... much longer than I care to admit. (Double digit years.) > All this rambling below boils down to one thing: if you need help > with roff, I'm your guy. Tell me what you want to do and I can > probably come up with some example stuff that you can play with. Thank you Larry, your offer is very much appreciated. I don't have a project that I'm working on per say. Rather I've always respected *roff and the recent threads on the TUHS list have stirred a long standing interest. > I would suggest groff as a good start. James did a great job. There is > the heirloom stuff, I've played with it, my take is that it is like > Keith's nvi stuff, true to the origin but not useful because the world > has moved on. Groff is my goto roff tool. I'm okay learning some history while learning new things. What I don't learn initially, I like to circle back and learn more. - Sort of like why I subscribe and participate in TUHS. > Anyhoo, I *love* troff and the preprocessors, I can draw pictures in my > head and then draw them in pic (I've done a lot of pic, got James to put > an extension in gnu pic so that you could iterate through the N things > you just drew, I can show you an exampe). I'd be interested in seeing an example, if it's handy. I was going through "troff and its companion programs" (troff and its companion programs) briefly at work and found it to be fairly easy to follow to see some initial results. > I _think_ I have the sources to the troff docs, I feel like I did a > project at one point to modernize how they looked. I have a dead tree copy of "UNIX Text Processing" somewhere and have thumbed through it multiple times. I was pleasantly surprised to see m4 in there, something I occasionally choose to use for new projects. > So you've gotten some good suggestions, I'm a fan of the original > docs though. I still have the stack of docs that I bought at the > UW Madison computing center - n/troff doc, pic, eqn, tbl. Then > there were various others, like grap, chem, etc. I've already started lifting an eyebrow at things like the fact that chem is an awk script. - I've done more in awk than some, but am impressed, and want to learn more. - What it does, how it does it, and how I might be able to apply that methodology to other things. > I love all that stuff because it was designed at a time where you did > your markup and you sent it to the lab where the printer was and you > got it the next day or so. There were no bitmapped displays, all this > stuff was done on 80x24 CRTs. So the markup language, the pic stuff, > the eqn stuff, it all had to be something that you could see in your > head and put down in text. I'm cool with that. One of the current questions is how, and why, people chose different macro packages. I do see why someone would use (or write / modify) macros to do some basic things in *roff. - I suspect it's similar to what I've hard of people do in assembly programming. Namely write in the macro language that is then expanded to the lower layer *roff. My knee jerk reaction for expanding short text (macros) into longer text with logic would be m4. But I want to learn the *roff world before I get off course. > That fits really well with how I think, I love the roff ecosystem to > this day (and I've done conference proceedings in roff and in LaTex, > I much prefer roff and the funny thing is when I show LaTex people > roff they go, wow, simple). :-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: