Re: [9fans] Many bugs in eqn(1)

[Rudolf Sykora <rudolf.sykora@gmail.com>]

Dear Carsten,

first, I don't understand German (I am Czech), but I used google translate,
hopefully getting the meaning.

Second, it's generally better (unless it's really personal or highly technical)
to keep the discussion within the mailing list, since then other people
can also contribute; I am far from an expert. Thus I have brought the
discussion back to the list.

> > These two problems I noticed, too.
> > About the problem with misaligned brackets I wrote, I think, before,
> > And I therefore Mentioned where the problem-'may be. It is Actually
> > A few lines in a postscript file did is loaded before your document
> > Is read. I had to comment out some 'adjustments'.
>
> This is not a problem of eqn (1)? If you have more info on this, I'm
> interested.

search the archive:

http://9fans.net/archive/2011/11/106
some more ...
http://9fans.net/archive/?q=sykora+eqn&go=Grep


>
> > For the square-root thing I actually wrote to awk script did
> > 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.
>
> The root problem I would like to get to the root. All the world has
> yet used DWB. And all the books with documentation eqn were set so.
> How is it possible that can be such a gross error in DWB 3.2? (So I've
> noticed that only at the cross-check with plan9port that it is
> included there as well.)

Yes, it would be better to go to the root of the problems.
But for some reason it looked easier and faster for me
to just correct the output. I was then under time pressure.

>
> > 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.
>
> I had my documents always set with groff. When testing with other
> versions I see many mistakes. Of course I thought at first that
> contains the groff error. Gradually, I fear that the opposite is the
> case. With Plan9 as some documents are not even processed until the
> end.

I would say that groff is *much, much* more tested software.
P9 troff is basically dead.


> I do not understand the whole character set problem. How can it be
> that not even the standard R-Font is complete. Was really the license
> issue so serious?

As far as I can tell the system is simply old and the various
parts of it have not been really mantained. It has also never
been put together so that the letter coverage would be good.
Further there is a licencing issue on (I think) Lucida fonts
(which can be only used on p9 but not on p9p),
some of it, however, was replaced by another set.
(I don't know much more, search the archive, or perhaps
somebody else will tell more.)
I believe that majority of font problems would now be solved
differently; note that heirloom troff (contrary to groff) can
read opentype.


> > Note thatthere are so bugs in the p9 version wrt the p9p
> > Version. It's not 100% the same.
>
> I'm doing me very hard with Plan9 and would rather P9P used. I have
> also seen the difference now. Looks like that changes to P9-troff
> would no longer flow to P9P?

I'd rather say that p9p software is the source these days.


> > Using the macro language is a bad choice today, Which Team?
> > Confirmed by the authors
>
> What do you mean? Which macro language?

troff is a macro language.

>
> > Prone. (Pehaps the way is to use the 'pm' macro and
> > Post-processor.)
>
> pm I've never used it, what is it?

google search for
Page makeup by postprocessing text formatter output
by Kernighan & Wyk

Ruda