groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Groff] -ms and PO bug? (was: Weird problem; .ig is not ignored)


From: Jörgen Grahn
Subject: [Groff] -ms and PO bug? (was: Weird problem; .ig is not ignored)
Date: Mon, 20 Jun 2005 22:14:28 +0200
User-agent: Mutt/1.5.9i

On Mon Jun 20 15:37:52 2005, address@hidden wrote:
> But, even if I omit
> these marks, I still see absolutely no difference in output samples,
> with or without the .ig block.
...

Okay, I'm seriously confused here, but here are three more test cases:
A, B and C.  To sum up the rest of this longish mail, they point away /from/ .ig
as a source of problems. Instead, evaluating the PO register before the
start of the real -ms document seems to be what creates the mess.

If noone can duplicate the problems I see with these examples /and the exact
same command line/, I'll shut up and blame it on my groff 1.19.x
installations.

BR,
/Jörgen

A:

.ig
.tm Before the LP, the value of PO is \n(PO.
..
.LP
Example text, example text, example text, example text, example text,
example text, example text, example text, example text, example text,
example text, example text.
.tm After the LP, the value of PO is \n(PO.

B, the one that doesn't involve .ig:

.tm Before the LP, the value of PO is \n(PO.
.LP
Example text, example text, example text, example text, example text,
example text, example text, example text, example text, example text,
example text, example text.
.tm After the LP, the value of PO is \n(PO.

C, the reference:

.LP
Example text, example text, example text, example text, example text,
example text, example text, example text, example text, example text,
example text, example text.
.tm After the LP, the value of PO is \n(PO.

I am still confused about how much of a "block comment" request .ig really is.
All I know is that current groff evaluates number registers within .ig blocks.
Did it always do it? Do other troffs do it? I don't know.

Anyway, that isn't as important as I thought. What I /know/ to be
different in CVS groff compared to older releases is that evaluating
PO before the first .LP zeros it, causing this zero-margin effect.

Here's what I get when I run A, B and C:

Solaris 8 troff: all generate properly indenteded typeset output.

> troff -ms -Tpost a |dpost >a.ps
After the LP, the value of PO is 720.
> troff -ms -Tpost b | dpost > b.ps
Before the LP, the value of PO is 720.
After the LP, the value of PO is 720.
> troff -ms -Tpost c | dpost > c.ps
After the LP, the value of PO is 720.
> 

groff 1.18.1: all generate properly indenteded typeset output.

> groff -ms -Tps a >a.ps
After the LP, the value of PO is 72000.
> groff -ms -Tps b > b.ps
Before the LP, the value of PO is 0.
After the LP, the value of PO is 72000.
> groff -ms -Tps c > c.ps
After the LP, the value of PO is 72000.
> 

CVS groff: C is properly indented; A and B have no left margin.

> /usr/local/opt/groff-20050620/bin/groff -ms -Tps a >a.ps
After the LP, the value of PO is 0.
> /usr/local/opt/groff-20050620/bin/groff -ms -Tps b > b.ps
Before the LP, the value of PO is 0.
After the LP, the value of PO is 0.
> /usr/local/opt/groff-20050620/bin/groff -ms -Tps c > c.ps
After the LP, the value of PO is 72000.
> 

-- 
  // Jörgen Grahn       "Koka lopplummer, bada Ross, loppor borta."
\X/ <address@hidden>                                   -- Jonas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]