From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1488628310.1109153.1407858103209.JavaMail.ngmail@webmail18.arcor-online.net> References: <1488628310.1109153.1407858103209.JavaMail.ngmail@webmail18.arcor-online.net> Date: Wed, 13 Aug 2014 09:56:32 +0200 Message-ID: From: Rudolf Sykora To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Many bugs in eqn(1) Topicbox-Message-UUID: 0edb3c0c-ead9-11e9-9d60-3106f5b1d025 Hello, > I'm somewhat disappointed about the troff software in Plan9. Yes, that's understandable... It seems to me nobody actually uses the software heavily here. > I did few initial tests with eqn(1) and in addition to the TAB problem > I saw that the root sign line and large brackets are not aligned. The > attached file shows these problems. It can be processed to PostScript > with These two problems I noticed, too. About the problem with misaligned brackets I wrote, I think, before, and I also mentioned where the problem may be. It is actually a few lines in a postscript file that is loaded before your document is read. I had to comment out some 'adjustments'. For the square-root thing I actually wrote an awk script that corrects it in the ps output. Not really the right solution, but works. I may share it and/or find some more details if you want it. > Does nobody use troff on Plan9? eqn(1) is maybe from around 1990, why > had these bugs not been fixed? Simply people don't use it. It's a pitty, but it's so. I tried and finally managed to write my PhD thesis with it, even full of mathematics... I set up means for back-references, creation of contents, etc. Note that there are also bugs in the p9 version wrt the p9p version. It's not 100% the same. But the topic is broader as well. E.g., if you just compare what you get from groff eqn, heirloom eqn, ..., you don't get the same. Further there is the unicode support issue, use of opentype fonts etc. The mathematics is not on par with TeX, it needs much more attention to get a good result. Using the macro language is a bad choice today, which was confirmed by the authors --- it's not lucid and is error prone. (Pehaps the way is to use the 'pm' macro and post-processor.) (Perhaps see also the work by Ali Gholami Rudi and his neatroff.) Ruda