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

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

[Carsten Kunze]

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

Sorry for that!

> 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.

Since nobody seems to use troff on P9 I regarded it as off-topic.

> http://9fans.net/archive/2011/11/106

Thank you!

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

I can't believe that TeX should not produce better results, but
thats really OT...

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

Not dead ... lets call it freezed or so ...

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

Really?  Ok, if I compare the sources it looks like this.  Is this
true for troff only or for p9p in general?

So p9 troff posts may be better done on the p9p list?

> troff is a macro language.

This I completely don't understand.  If someone has much time
and uses only low level requests than the word "macro" should
be improper?

What is not a macro language, i.e. what do you suggest to use instead?

> Page makeup by postprocessing text formatter output
> by Kernighan & Wyk

I also do not understand that.  It is possible to write very good macro
packages for troff.  Also TeX can produce very good documents.  Ok,
this is OT again.

Carsten

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

[Rudolf Sykora]

On 13 August 2014 12:57, Carsten Kunze <carsten.kunze@arcor.de> wrote:

> Since nobody seems to use troff on P9 I regarded it as off-topic.

The traffic is low enough to discuss any matter related to p9(p) here,
I believe. And it can be used as a back-reference in the future.


>> http://9fans.net/archive/?q=sykora+eqn&go=Grep
>
> I can't believe that TeX should not produce better results, but
> thats really OT...

I don't understand what you mean.


>> I'd rather say that p9p software is the source these days.
>
> Really?  Ok, if I compare the sources it looks like this.  Is this
> true for troff only or for p9p in general?
>
> So p9 troff posts may be better done on the p9p list?

I think whoever uses p9p reads this list.
I personally even don't know there is a special p9p list.


>> troff is a macro language.
>
> This I completely don't understand.  If someone has much time
> and uses only low level requests than the word "macro" should
> be improper?
>
> What is not a macro language, i.e. what do you suggest to use instead?
>
>> Page makeup by postprocessing text formatter output
>> by Kernighan & Wyk
>
> I also do not understand that.  It is possible to write very good macro
> packages for troff.  Also TeX can produce very good documents.  Ok,
> this is OT again.

Just read the document.
And it is not only about producing good documents meaning
good-looking. It's about scalability and readability, too.
Nobody would tell you LaTeX is readable. PlainTeX is, but
by itself, it doesn't know much (like plain troff).
Twisting a macro language around is often difficult, has many
pitfalls, may be difficult to debug, and if it grows beyond a certain
level, it collapses. That's at least what I think.

Ruda

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

[Carsten Kunze]

> >> http://9fans.net/archive/?q=sykora+eqn&go=Grep
> >
> > I can't believe that TeX should not produce better results, but
> > thats really OT...
>
> I don't understand what you mean.

I refer to http://9fans.net/archive/2011/12/113.  I would expect
TeX to produce the best math results.  But this should not be
discussed here.

> Just read the document.
> And it is not only about producing good documents meaning
> good-looking. It's about scalability and readability, too.
> Nobody would tell you LaTeX is readable. PlainTeX is, but
> by itself, it doesn't know much (like plain troff).

I would completely disagree :)
LaTeX is very good readable (IMO better than e.g. troff -ms),
PlainTeX is totally unreadable to me (I'v used it for a longer time.)

Ok, lets close this thread for now.  I look at your posts regarding
the brackets and for the root sign problem, that may take some
time.

Cheers,
Carsten

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

[Rudolf Sykora]

On 13 August 2014 14:16, Carsten Kunze <carsten.kunze@arcor.de> wrote:
>> >> http://9fans.net/archive/?q=sykora+eqn&go=Grep
>> >
>> > I can't believe that TeX should not produce better results, but
>> > thats really OT...
>>
>> I don't understand what you mean.
>
> I refer to http://9fans.net/archive/2011/12/113.  I would expect
> TeX to produce the best math results.  But this should not be
> discussed here.

Still I don't get what you mean. In that message we say
1) quality of TeX typesetting is better,
2) the way the equation is written (the syntax) in eqn feels
better to me.


>> And it is not only about producing good documents meaning
>> good-looking. It's about scalability and readability, too.
>> Nobody would tell you LaTeX is readable. PlainTeX is, but
>> by itself, it doesn't know much (like plain troff).
>
> I would completely disagree :)
> LaTeX is very good readable (IMO better than e.g. troff -ms),
> PlainTeX is totally unreadable to me (I'v used it for a longer time.)

Just to be sure. I don't mean readability of documents to be typeset.
I mean the source code of the whole system. I.e., in the case of LaTeX,
the readability/understanding/hackability of the macros' definitions.

R

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

[Carsten Kunze]

> Still I don't get what you mean. In that message we say
> 1) quality of TeX typesetting is better,
> 2) the way the equation is written (the syntax) in eqn feels
> better to me.

Ok, I got that wrong.

> Just to be sure. I don't mean readability of documents to be typeset.
> I mean the source code of the whole system. I.e., in the case of LaTeX,
> the readability/understanding/hackability of the macros' definitions.

I got that wrong too...

And thank you for the advice regarding gv(1) and printed output.  I had
not expected a difference there.  With printed output I have no errors
with DWB (except the TAB).  (With P9P there is still the root sign shift.)

Carsten

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

[tlaronde]

On Wed, Aug 13, 2014 at 03:13:38PM +0200, Rudolf Sykora wrote:
>
> Just to be sure. I don't mean readability of documents to be typeset.
> I mean the source code of the whole system. I.e., in the case of LaTeX,
> the readability/understanding/hackability of the macros' definitions.
>

And this links to another thread: the base plainTeX system, with fonts,
is 8Mo; with the AMS this may reach 16Mo. With LaTeX and al. (I don't
use, but others do and I need to test somewhat), the whole thing reach
250Mo. PlainTeX is not a litteracy exercice, sure, but is documented and
small. And riding piggyback on plainTeX, I'm mainly covering my needs.
And I decided to use plainTeX whan I saw that there were less pages,
written by the author: D.E. Knuth to explain fully how to use and
program TeX, than pages trying partly to explain how to use LaTeX
without attempting to explain how TeX was working underneath. And if one
doesn't understand TeX, one is unlikely to even have a clue about why
the LaTeX macros do not do what one supposed them to do...
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
              http://www.renaissance-francaise.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

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

[Steve Simon]

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

I wouldn't agree, p9p is a fork, much stuff gets ported both ways,
though some changes may have been missed.

I still use troff and tbl on plan9, occasionally I use eqn, last week
for the first time in ages.

I know there are some bugs but I find it much easier to generate a simple
document in troff than with MS Word, its a metter of what you are used to.

I'am sure latex is capable of genatiing better documents, but i have
never had the need to learn it so I don't use that. Troff is good enough
for what I need.

-Steve

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

[Carsten Kunze]

> I still use troff and tbl on plan9, occasionally I use eqn, last week
> for the first time in ages.

What are the bugs in tbl you found?  (I think it had been you who mentioned
it.)

> I know there are some bugs but I find it much easier to generate a simple
> document in troff than with MS Word, its a metter of what you are used to.

You can be sure MS word has bugs too :-)

> I'am sure latex is capable of genatiing better documents, but i have
> never had the need to learn it so I don't use that. Troff is good enough
> for what I need.

Good opinion!

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

[Steve Simon]

> What are the bugs in tbl you found?  

Mmm, I was worried you might ask that. I have an old document
that used to layout incorrectly, however I just tried it and it
is now fine - I wonder if the bug has been fixed ☺

The problem I had was a small - 1/23 inch, misalignment of
vertical edges of table bounding boxes. This is quite obvious
as the vertical like sproject beyond the bottom edge of the
table and there is a gap between the top and the sides.

This bug was content dependent but as I said it now seems fine.

I will dig through my venti and see if I can find an old copy
which exhibits the problem...

-Steve

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

[Carsten Kunze]

> Mmm, I was worried you might ask that.

:-)

> I will dig through my venti and see if I can find an old copy
> which exhibits the problem...

Ok.  If possible the lines between .TS/.TE to reproduce it (you may change the text if its confidential).

--Carsten

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

[Steve Simon]

I have had a look, found a copy of the doc from 1996 and failed to reproduce the problem.

I withdraw the accusation - tbl you are without bugs.

Sorry for the noise.

BTW: for troff related stuff I should mention http://www.troff.org is a good resource.

-Steve

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

[erik quanstrom]

On Thu Aug 14 02:55:58 EDT 2014, steve@quintile.net wrote:
> I have had a look, found a copy of the doc from 1996 and failed to reproduce the problem.
>
> I withdraw the accusation - tbl you are without bugs.

but there are some font bugs that cause the small errors when converting to ps.
e.g.: http://www.quanstro.net/plan9/tcp/perf.png

- erik

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

[tlaronde]

On Wed, Aug 13, 2014 at 02:22:00PM +0200, Carsten Kunze wrote:
>
>
> Is this really necessary for the system documentation?  AFAIK P9 nroff/troff
> can handle utf-8.  If there are problems with *roff they should be solved.
> *roff is a Bell Labs documentation system--it should be used for P9--IMO.

IMO, the advantages are multiple:

1) TeX is a complete system: not only the layout engine, but the means
to draw the fonts. METAFONT is also a rasterizer engine. This means that
the system can be self-sufficient allowing to render the result without
resorting to huge external PS dependencies;

2) TeX programs (for the D.E.K. parts) are fully documented and fully
debugged. Before, I thought that using Pascal as the programming
language was a problem (I never managed to like Pascal). But having
work for kerTeX with the WEB programs, I understand now that this
is not really Pascal, but some Algol. The translation from _this_
Pascal to C is under control, so the programming language is not a
problem after all and probably prevents lots of people from tempering
with it: TeX is stable;

3) The "typesetting" system is not my aim. My aim is to use it as a mean
for producing documentation about something else. Having several
languages to learn for, in fact, doing the same thing while it has
been recognized that for math, TeX is an improvement, is suboptimal;

4) TeX and al. and the original Web-to-C were not bundled under GPL.
Now, with kerTeX, the bundle is not anymore with GPL (and for systems,
whether Plan9 or the *BSD, since what I did use was under public
licence, and what is added is mine, I could re-licence my contributions
to the very licence of the systems). Other troff implementations
are whether under GPL, or the improvements were made taking from
TeX (Heirloom);

5) With kerTeX, we are back with the needle only and not the whole
hay stack and the whole core thing is really, really small. Including
fonts.

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
              http://www.renaissance-francaise.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

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

[Carsten Kunze]

> Does anyone know if there has been any effort to use TeX and al. for the
> system typesetting i.e. the manpages and docs? (Translation of the troff
> macros to TeX ones etc.---not to mention that for TeX (kerTeX), it needs
> to be converted for utf-8 input; that's on my TODO list but I need to
> finish the rewrite of the T1 lib for dvips(1) first, and the display for
> METAFONT.)

Is this really necessary for the system documentation?  AFAIK P9 nroff/troff
can handle utf-8.  If there are problems with *roff they should be solved.
*roff is a Bell Labs documentation system--it should be used for P9--IMO.

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

[tlaronde]

On Wed, Aug 13, 2014 at 03:30:37AM -0700, cam@9.SQUiSH.org wrote:
>
> sorry, i am unable to help with this specific problem.  i only
> use the ms macros and use tex for anything more.
>

Does anyone know if there has been any effort to use TeX and al. for the
system typesetting i.e. the manpages and docs? (Translation of the troff
macros to TeX ones etc.---not to mention that for TeX (kerTeX), it needs
to be converted for utf-8 input; that's on my TODO list but I need to
finish the rewrite of the T1 lib for dvips(1) first, and the display for
METAFONT.)
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

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

[cam]

sorry, i am unable to help with this specific problem.  i only
use the ms macros and use tex for anything more.

however, just fyi:

> Further there is a licencing issue on (I think) Lucida fonts
> (which can be only used on p9 but not on p9p),

the license for the lucida* fonts prohibits the creation
of derivative fonts.  redistribution is only allowed with
plan9, which is as specific as the license gets.  other
forks of plan9 still include them.  the license is at:

/lib/font/bit/lucida/NOTICE

> some of it, however, was replaced by another set.

the vera bitstream fonts.  you can download the set
that has been converted to plan9's font format here:

http://www.bx.psu.edu/~schwartz/vera.tar.bz2

> I believe that majority of font problems would now be solved
> differently; note that heirloom troff (contrary to groff) can
> read opentype.

there is also ttf2subf which will convert true-type fonts
to the plan9 format.

/n/sources/contrib/quanstro/ttf2subf

if you are using plan9port on a mac, the p9p font server will
let you use your mac fonts as well.

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

[Rudolf Sykora]

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

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

[Rudolf Sykora]

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

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

[Steve Simon]

There are several plan9 repositories as there are several distribuitions,
however I am pretty sure all these keep in sync with the labs (bell labs)
code so I would suggest you start with that (unless somone else on this list shouts).

from plan9 its just a case of:
	9fs sources
	ls /n/sources/plan9/sys/src/cmd/eqn

if not then you should be able to use:

	http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/eqn

and a little hacking to trim headers and taililers.

-Steve

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

[Carsten Kunze]

> It is a shame if there are bugs in eqn - tbl has one or two also
> but the source is there and it is all fixable. You could submit a patch.

I'm working on it.  But not just eqn--on a DWB port in general (to current
UNIX versions).  So it may take some time but I'll work on a fix.

Is there a plan9 repository so I'm able to work on the most current code
version?

> You mention the DWB eqn (neqn I assume) - the plan9 eqn is (i believe)
> a direct descendent of that and the solaris one a cousin so by comparing
> code the bug may become obvious...

No, I ment eqn. neqn I will test next (Usually I'm more interested in typeset
output).
Comparing with solaris is a good plan.

Cheers,
Carsten

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

[Steve Simon]

It is a shame if there are bugs in eqn - tbl has one or two also
but the source is there and it is all fixable. You could submit a patch.

You mention the DWB eqn (neqn I assume) - the plan9 eqn is (i believe)
a direct descendent of that and the solaris one a cousin so by comparing
code the bug may become obvious...

-Steve

[9fans] Many bugs in eqn(1)

[Carsten Kunze]

[-- Attachment #1.1: Type: text/plain, Size: 648 bytes --]

Hello,

I'm somewhat disappointed about the troff software in Plan9.

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

eqn eqn.tr | troff | tr2post | psfonts > eqn.ps

(Actually on UNIX using plan9port.)

Does nobody use troff on Plan9? eqn(1) is maybe from around 1990, why had these bugs not been fixed?

Also the font for e.g. "pi" is not as expected (like from DWB or Solaris or groff).

Why does Plan9 troff uses other fonts than UNIX troff does?

--Carsten

[-- Attachment #2: eqn.tr --]
[-- Type: text/troff, Size: 320 bytes --]

.nf
TAB does not work:
.sp
.ta 0.5i +0.5i +0.5i
.EQ
x sub 1	+x sub 2	+s sub 1	=^10
.EN
.EQ
-2x sub 1		+s sub 1	=^42
.EN
.EQ
delim $$
.EN
.sp
Root sign line is shifted to the right side:
.sp
.EQ
sqrt {b sup 2 - 4ac}
.EN
.sp
Brackets are not aligned:
.sp
$P=R left [ 1^-^{1+1 sup n} over i right ]$