bug-groff
[Top][All Lists]
Advanced

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

[bug #57538] [me] incorrect PostScript output of macro .(b


From: G. Branden Robinson
Subject: [bug #57538] [me] incorrect PostScript output of macro .(b
Date: Tue, 21 Dec 2021 20:09:24 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #6, bug #57538 (project groff):

[comment #5 comment #5:]
> [comment #4 comment #4:]
> > I therefore do not think there is a bug here; if only half a
> > line of space is available, a full-height line cannot be typeset.
> 
> Yes, but we know that a full-height line can be typeset, because when that
line appears below the .(b block, a full-height line _is_ typeset.  Moving it
from below to above the block shouldn't change how many full-height lines fit
on the page.

That certainly makes intuitive sense.

I went back and re-instrumented e.tmac and keep.me a bit differently, and
parameterized the latter so that it was easy to control the output of lines
before and after the block.  I added Boolean flags for them, so that gives us
four combinations.  All I can find is internal consistency.


$ tg -me -rA1=0 -rA2=0 EXPERIMENTS/keep.me >| keep-00.ps
GBR: height of 7 lines: 84000u
GBR: before (b: nl=624000u
GBR: )b: dn=84000u, .t=90000u
GBR: height of 7-line diversion: 84000u
$ tg -me -rA1=0 -rA2=1 EXPERIMENTS/keep.me >| keep-01.ps
GBR: height of 7 lines: 84000u
GBR: before (b: nl=624000u
GBR: )b: dn=84000u, .t=90000u
GBR: height of 7-line diversion: 84000u
$ tg -me -rA1=1 -rA2=0 EXPERIMENTS/keep.me >| keep-10.ps
GBR: height of 7 lines: 84000u
GBR: before (b: nl=636000u
GBR: )b: dn=84000u, .t=78000u
GBR: height of 7-line diversion: 84000u
$ tg -me -rA1=1 -rA2=1 EXPERIMENTS/keep.me >| keep-11.ps
GBR: height of 7 lines: 84000u
GBR: before (b: nl=636000u
GBR: )b: dn=84000u, .t=78000u
GBR: height of 7-line diversion: 84000u


I observe that (1) the diversion is always the height we expect (I think this
rules out confounding effects of vertical spacing or the presence/absence of
an additional break); (2) adding a line before it increases the page position
by 1v; and (3) that increase makes me(7) decide there is not enough room for
the diversion on the page, so the break happens when and where you expect
based on these numbers.

I'll attach my new keep.me (I might have to name it keep2.me).  Here's the
diff to e.tmac.


diff --git a/tmac/e.tmac b/tmac/e.tmac
index cbe4ae6a7..ba8ac212f 100644
--- a/tmac/e.tmac
+++ b/tmac/e.tmac
@@ -1071,6 +1071,7 @@
 .
 .de )b                 \" *** end block
 .@)
+.tm GBR: )b: dn=\\n(dnu, .t=\\n(.tu
 .if (\\n(bt=0):(\\n(.t<\\n(bt) \
 .      ne \\n(dnu              \" make it all on one page
 .@k |k ns


> However, this may be less a -me bug and more a groff one: replacing the
".(b" and ".)b" bracketing the block with a ".ne 7" before the block exhibits
the same behavior.

I'm not sure precisely _what_ behavior we're observing.  Motivated by your
remark above, I presumed that I could get groff to produce two pages from the
following input.


$ cat EXPERIMENTS/ne.roff 
.nf
.ne 66v
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66\c


...but I can't.  (Note the absence of a break on the very last line of the
page--it makes all the difference.)

Starting from there, can you elucidate where the surprise creeps in?

(I tried to reason directly from that example, particularly including the `\c`
factor, but I can't--me(7) always inserts `br` requests around diversions
anyway (similarly to groff's "box" diversions), and anyway if there were a
missing line break at the end, the diversion's height would be shorter. 
Trying it out, adding `\c` after "fifty-two" made no difference.)

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57538>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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