[bug #57538] [me] incorrect computation of space `ne`eded by `(b` blocks

[G. Branden Robinson]

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

[comment #14 comment #14:]
> The upshot (which I fear may have gotten lost in the minutiae)
> is that the proposed fix to .)b in comment #8 amounts to "lie
> to .ne about how many lines are needed."  But there are
> numerous other cases, as comment #13 demonstrates, where lying
> to .ne by telling it one fewer line is also necessary to
> produce the correct result.

Well, yes and no.  I think the problem isn't that we need to lie
to .ne about how many vees of space are needed, but that we
(me(7)) has _been_ lying to the `ne` request for a long time.

All of the me(7) keep macros emit a break request before closing
the diversion.  That means there's _always_ an extra space down
to the next baseline at the ends of the diversions.

It's _really_ reliable about this.  Let me show you.


1133 .de @)                  \" --- end keep
1134 .br
1135 .if !"\\n(.z"|k" .do @err attempted close of never-opened keep
1136 .nr ?k 0
1137 .di
1138 .in 0
1139 .ce 0
1140 ..

1154 .de )c                  \" *** end block centered text
1155 .if !"\\n(.z"|c" .do @err unmatched block centering call
1156 .br                             \" force out final line
1157 .di
1158 .if \n@>4 .tm >> .)c .l=\\n(.l .i=\\n(.i $i=\\n($i dl=\\n(dl
1159 .ev 1
1160 .ls 1
1161 .nr __ (\\n(.lu-\\n(.iu-\\n(dlu)/2u
1162 .if \\n(__u<0 .nr __ 0
1163 .in \\n(__u
1164 .rr __
1165 .if \n@>4 .tm -- .)c << .in .l=\\n(.l .i=\\n(.i dl=\\n(dl
1166 .if \\n(?n \
1167 .       nm \\n(ln
1168 .nf
1169 .|c
1170 .in
1171 .ls
1172 .if \\n(?n \
1173 .       nm
1174 .ev
1175 .rm |c
1176 .if \\n(?n \
1177 .       nm \\n(ln
1178 ..

1253 .de EN                  \" *** equation end
1254 .br
1255 .do HTML-IMAGE-END
1256 .if "\*(.T"html" \
1257 .       do ll \\n[e-EQ-ll]u
1258 .ie "\\$1"C" \
1259 \{\
1260 .       nr ?e 1
1261 .       sp \\n(esu
1262 .\}
1263 .el \
1264 \{\
1265 .       nr ?e 0
1266 .       di
1267 .       if \\n(dn \
1268 .               @q\"            \" actual equation output
1269 .       rm |e
1270 .       ev
1271 .\}
1272 ..


(In fact, we can see that, if I'm right, the `if` at line 1267
is unnecessary; its condition is always true.)

Since this is groff, we could just `.chop` that line break away.
Alternatively, and for portability to less featureful troffs,
we could do a subtraction after closing the diversion,
decrementing 'dn'.  I'm leaning toward the latter.

> So the first fix should be figuring out how to tell .ne the
> truth in general.  Only then, if the -1v is still needed in
> .)b due to diversion semantics, should that change be
> considered.  (But I bet it won't.)

I think you're right, given the foregoing.

I'll give a subtracting 1v from 'dn' after closing these
diversions a try.


    _______________________________________________________

Reply to this item at:

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

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