bugGNU roff - Bugs: bug #50770, .PSPIC macro at bottom of page...

 
 

bug #50770: .PSPIC macro at bottom of page causes unwarranted page break

Submitter:  Dave <barx>
Submitted:  Sun 09 Apr 2017 07:38:54 PM UTC
   
 
Category:  Macro package - others/general Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 19 Sep 2024 06:46:22 PM UTC, comment #21: 

Under the assumption that the info requested by comment #12 (when the ticket was put in Need Info status) and by subsequent follow-ups has now been supplied, I'm reverting status to Confirmed.

Dave <barx>
Group Member
Sun 15 Sep 2024 01:18:36 AM UTC, comment #20: 

comment #18:

> Our ideas about backward compatibility are probably quite close.


Yes, as Branden drove home, my analogy of compiled code is closer to the generated grout than to the final typographic layout.

But that was a flaw in my analogy.  My underlying point is that in limited circumstances it should be acceptable to change the final output, as the change in hyphenation patterns I cited could do.

> I have no problem with improvements to the compiler, but I would
> be annoyed if, when I compiled my program after installing the
> new version, its output had changed when I ran my program.


You might be annoyed, but it might be your fault if your code relied on undefined behavior. ;-)  That is, ultimately, what I claim the "+1v" in PSPIC's .ne is.

Dave <barx>
Group Member
Sun 15 Sep 2024 01:11:22 AM UTC, comment #19: 

comment #17:

> However, you might not be wrong in a practical sense.
>
> 5.28.1.3 Diversion Traps
> ........................
>
> A diversion is not formatted in the context of a page, so it lacks page
> location traps;


Right, and combined with a clause from the .ne description in the manual--"'ne' tests the distance to the next page location trap"--I don't see any practical way an .ne inside a diversion can have any effect (though I have not tried to test the limits of this), and it's not even clear what such an effect might be, since a page break within a diversion is also meaningless.

> It is possible that it's not a good idea to use `PSPIC` inside a
> diversion for other reasons,


The PSPIC documentation explicitly countenances such usage: groff_tmac(5) says, "To use PSPIC within a diversion, we recommend extending it with the following code."

I have successfully used PSPIC within a diversion (in order to use register dn afterwards to find the vertical size of the image) even without the recommended code amendment.  That's not to argue that it's a "good idea," necessarily, just that in some circumstances it works (and as a side benefit, sidesteps the bug at issue in this ticket).

> It does seem to me that I should be able to draw a horizontal rule 1u
> (or even 0u?) below a `PSPIC`-included image without having to do a
> reverse vertical motion first.  I haven't played with it much, so if
> that's not the status quo, that feels like a bug to me.


I have also not tested this, but the .ne under discussion here shouldn't affect this, as .ne only decides whether to insert a page break.  If there's a problem with vertical space below the PSPIC image, that's a separate issue.

> Time to start abandoning goals for groff 1.24. :(


I disagree with the ":(" here.  I think the number of 1.24 goals, and the complexity of some of them, was wildly ambitious -- which is a good thing.  But it's fine to ultimately let reality check some of that ambition.  And anyway, version 1.24 is merely one stop on the groff journey.

I'd argue that having a consistent release schedule is better than any particular set of changes making it into any particular release.  1.23, if anything, did a little too much: its NEWS section dwarfs that of almost any previous release.  1.24's NEWS section is already starting to rival it in length.  Even if code froze today, it would be a very respectable leap forward.

Dave <barx>
Group Member
Sat 14 Sep 2024 02:09:56 PM UTC, comment #18: 

Hi Dave,

Our ideas about backward compatibility are probably quite close.

> What he suggests seems akin to saying a compiler, in order to be backward compatible, must produce the same executable from version to version.  This philosophy would forestall any new optimizations a new version of a compiler might be able to make.


I have no problem with improvements to the compiler, but I would be annoyed if, when I compiled my program after installing the new version, its output had changed when I ran my program. Applying this to roff - groff compiles (and then runs) my document (the source code) and output is produced. Backward compatibility should mean that the output from both versions should be the same. Output in this sense is whatever gets printed or viewed on the screen. This is most important for troff produced output since we know that some of our users take a lot of time to make their output look as good as possible, it is probably less important for output destined for a terminal.

An example is if you compare the sizes of the mom/examples pdfs produced by 1.23.0 and current HEAD they are much smaller, because of improvements to gropdf, but if you "output" the pdfs they look identical.

Anyway, you have persuaded me that the chances of this change affecting a significant number of existing documents is small, so I have no objection, but I hope you understand my definition of backward compatibility is restricted to the typographical output produced. How it is produced can change, or new features added. I am not so much a luddite as you think. :-)


Deri James <deri>
Group Member
Sat 14 Sep 2024 08:28:44 AM UTC, comment #17: 

Hi Dave,

I'll give Deri some time to rebut you if he would like to, but in the
meantime...

At 2024-09-13T20:06:05-0400, Dave wrote:

> > Any change would also have to consider the impact if PSPIC is used
> > within a diversion, i.e. not at the point it is actually being
> > output to the page.
>
> AIUI, within a diversion, .ne is effectively a no-op, so changing the
> value given to .ne should not affect this case either.


Well...sort of.  There is no special logic in the `ne` request handler
to do nothing if the formatter is currently processing a diversion.


void need_space()
{
  vunits n;
  if (!has_arg() || !get_vunits(&n, 'v'))
    n = curenv->get_vertical_spacing();
  while (!tok.is_newline() && !tok.is_eof())
    tok.next();
  curdiv->need(n);
  tok.next();
}


However, you might not be wrong in a practical sense.

5.28.1.3 Diversion Traps
........................

A diversion is not formatted in the context of a page, so it lacks page
location traps; instead it can have a "diversion trap".  There can exist
at most one such vertical position trap per diversion.

 -- Request: .dt [dist name]
     Set a trap within a diversion at location DIST, which is
     interpreted relative to diversion rather than page boundaries.  If
     invoked with fewer than two arguments, any diversion trap in the
     current diversion is removed.  The register '.t' works within
     diversions.  It is an error to invoke 'dt' in the top-level
     diversion.  *Note Diversions::.

I haven't yet used a diversion trap in anger, but what I have twigged is
that, as a rule, we want diversion content to be closely cropped, if you
will.  It should have no negative space around its formatted elements
(glyphs and geometric figures).  Or, in this case, an opaque inclusion
of material inserted via a device extension and which occupies space in
the top-level diversion (if the diversion is ever called for).

At first blush that would seem to argue for your proposal...I think?

It is possible that it's not a good idea to use `PSPIC` inside a
diversion for other reasons, at least not directly.  It might be one of
those cases where you want to "bubble it up" via the `\!` escape
sequence,[1][2] and call the macro only once you truly are formatting
the page (a.k.a. top-level diversion).

It does seem to me that I should be able to draw a horizontal rule 1u
(or even 0u?) below a `PSPIC`-included image without having to do a
reverse vertical motion first.  I haven't played with it much, so if
that's not the status quo, that feels like a bug to me.

I will also say that I am emphatically not wedded to the immutability of
the "grout" that GNU troff emits for a given input.  I have several
complaints about it, from its esthetic of whitespace usage to its
frequent and seemingly redundant resets of the drawing position with
absolute positioning commands.  The former I am confident I can solve
(though it is not a matter of urgency); the latter seems trickier.

Bug #64484 and bug #66187 have gotten me as deep into the innards of the
formatter as I have yet explored, and I am consistently presented with
mixtures of mystery and code smells that I am challenged to distinguish.

I'm going to miss my self-imposed "freeze the formatter in early
September" deadline.  Time to start abandoning goals for groff 1.24. :(

Regards,
Branden

[1] or `output` request

[2] I'll confess that it was the example of page breaks in boxed tables
    that finally lit the bulb over my head with respect to this
    technique.  See tbl(1), section "Limitations".

G. Branden Robinson <gbranden>
Group administrator
Sat 14 Sep 2024 12:06:01 AM UTC, comment #16: 

comment #15:

> I guess I was simply casting about for something useful I can do
> to resolve this ticket.  :)


If you agree with my analysis in comment #11, I believe resolving this ticket is as simple as removing the "+1v" from the .ne line in the .PSPIC macro.

Deri previously raised some objections to this:

comment #6:

> The problem with changing it is that it breaks backward
> compatibility.... A document created 15 years ago should render
> the same now as it did then. This is an aspiration, it is not
> always true, but it is something we should aim for.


Deri and I seem to have different concepts of backward compatibility.  What he suggests seems akin to saying a compiler, in order to be backward compatible, must produce the same executable from version to version.  This philosophy would forestall any new optimizations a new version of a compiler might be able to make.

My concept is that the same input should continue to behave in the way it's documented.  Deri is right that the extra +1v in the .ne request has been around for groff's entire known history (though as I argue in comment #11, I believe it's an artifact from a very early version where it was necessary), but .PSPIC has never been documented to require this extra line at the bottom of a page.

The plain fact is, groff makes changes to improve typography all the time.  For example, by updating the hyphenation patterns, commit b2284ab01 may have changed where some word is broken, which might be trivial, or might have the cascading effect of changing the number of lines in a paragraph, which then changes the location of a page break, which then changes where a diversion is output.

I think groff needs to be able to make changes that demonstrably improve output as long as such changes are in line with its historically documented behavior.  And removing an undocumented adjustment to a .ne call--an adjustment that, if my comment #11 analysis is correct, remained in place only as an oversight in a 1992 update--seems to fall under that umbrella.

> If you consider the case where a graphic does not extend too
> close to the bottom of the page, it is "usual" to have a line of
> white space between the bottom of the image and following text.
> So, if this behaviour was altered, any document which relied on
> this behaviour would look ugly since this space would disappear.


This doesn't actually apply, as the .ne request affects only whether or not a page break happens.  It changes nothing about the spacing after the graphic if text continues on the same page.

> Any change would also have to consider the impact if PSPIC is
> used within a diversion, i.e. not at the point it is actually
> being output to the page.


AIUI, within a diversion, .ne is effectively a no-op, so changing the value given to .ne should not affect this case either.

Dave <barx>
Group Member
Sat 10 Aug 2024 01:10:29 AM UTC, comment #15: 

comment #14:

> comment #12:
> > and/or a documentation change cautioning the PSPIC user that the
> > macro doesn't handle "keeping" the image together with a
> > subsequent caption for them.
>
> I guess I can't raise any objection to such a caution, but in general I'm not sure it's useful to document everything a macro doesn't do, as that list is infinite.  If the documentation clearly indicates what the macro does do, readers can work out for themselves all the things that it doesn't.


Fair.  I guess I was simply casting about for something useful I can do to resolve this ticket.  :)

G. Branden Robinson <gbranden>
Group administrator
Fri 09 Aug 2024 07:54:59 PM UTC, comment #14: 

comment #12:

> and/or a documentation change cautioning the PSPIC user that the
> macro doesn't handle "keeping" the image together with a
> subsequent caption for them.


I guess I can't raise any objection to such a caution, but in general I'm not sure it's useful to document everything a macro doesn't do, as that list is infinite.  If the documentation clearly indicates what the macro does do, readers can work out for themselves all the things that it doesn't.

Dave <barx>
Group Member
Fri 09 Aug 2024 07:49:00 PM UTC, comment #13: 

I understood the purpose of comment #10 as explaining the mechanism of the behavior, which to me was a less interesting question than whether the behavior should be changed, so I didn't pay it much mind in writing comment #11.

But as I look at comment #10 closer now, I don't think I agree with its analysis (at least as I understand it--Deri, please correct me if I'm getting it wrong).

comment #10:

> After .sp 64 the text "Line 1" is on line 65. PSPIC causes a
> break, to force the previous line of text to be output, it
> will now be on line 66. This is the 1v, since calling PSPIC
> causes the break to the next line, and now it needs room for
> the graphic of 2pt, but since the top of the graphic is
> alligned to the base-line of line 66, there is no room.


This explanation, as I read it, would mean that the graphic would be kicked to the next page regardless of any .ne call: if the drawing position is as low on the page as allowable (the baseline of the lowest possible line), and the next requested drawing will go below that point, a page break is the only option, .ne or not.

But (testing with the input files from the original submission, with the ".sp 64" modification therein described) removing the "+1v" from .PSPIC's ".ne" line shows that it is in fact the .ne, not the act of drawing the graphic, that triggers the page break:

  • With PSPIC's "+1v" intact, the behavior is as described in the original submission: the graphic and "Line 3" are pushed to a new page.
  • With PSPIC's "+1v" removed, the graphic is at the bottom of the first page, and only "Line 3" is pushed to the next page.
Dave <barx>
Group Member
Fri 09 Aug 2024 08:25:44 AM UTC, comment #12: 

comment #11:

> comment #2:
> > Is this because line 90 of pspic.tmac "needs" the height of the
> > graphic PLUS 1v whilst the vertical movement after the graphic
> > is output is only the height of the graphic, so it is needing
> > more vertical space than it uses for the graphic.
>
> I delved further into this.


Dave, can you update (if necessary) your delving with respect to Deri's comment #10 and suggest a course forward for this ticket?

I'm not clear on whether we need a code change and/or a documentation change cautioning the PSPIC user that the macro doesn't handle "keeping" the image together with a subsequent caption for them.

G. Branden Robinson <gbranden>
Group administrator
Mon 29 Jul 2024 03:09:06 AM UTC, comment #11: 

comment #2:

> Is this because line 90 of pspic.tmac "needs" the height of the
> graphic PLUS 1v whilst the vertical movement after the graphic
> is output is only the height of the graphic, so it is needing
> more vertical space than it uses for the graphic.


I delved further into this.  The line in the .PSPIC macro (in tmac/pspic.tmac) to which Deri refers is:

.    ne (\\n[ps-desht]u + 1v)

I infer "ps-desht" is "desired height of the PostScript image", so this line is, as Deri said, "ne"eding vertical space equal to the image's scaled height plus 1v.  This is the only .ne request in .PSPIC.

This line is effectively unchanged (only parentheses and whitespace being added later) from the beginning of our git history, when the .PSPIC macro lived in ps/tmac.ps.

That primordial .PSPIC macro did not do a break (explicit or implicit) before the .ne, which could explain the "+1v": it would account for a (potential) partially collected line.

But that situation didn't last long: less than a year later, in commit a48ab7b6d, James Clark moved the .PSPIC macro out of ps/tmac.ps and into its own file, then named ps/tmac.pspic.  One of the changes accompanying this move was the addition of a .br request at the very top of .PSPIC.

Nonetheless, that "+1v" stayed in the .ne line.  Is it still necessary, with the explicit break before it?  Did James Clark leave it there for a reason, or was it an oversight?  What are situations where you should "ne"ed more space than the height of the scaled image?

> This ensures there is room for at least one line after the graphic.


It does--but it shouldn't.  An image should be allowed to be at the bottom of the page.

If the image requires a caption (as comment #4 suggests), the user must be responsible for ensuring the caption remains with the image.  .PSPIC does not know about any caption requirements, so should not presume there will be one, and that it will be exactly one line.

But ultimately I don't think space for a caption is the rationale for the "+1v"; I think it's an artifact of a missing break in the original .PSPIC implementation.

Dave <barx>
Group Member
Fri 05 May 2017 01:19:53 PM UTC, comment #10: 

Humble apologies! I've been wrong all along! I've now done some playing and THIS is how it works.

The default point size is 10 and the vertical size is 12, the page length is 792 (11 inches) so exactly 66 lines fit on a page. After .sp 64 the text "Line 1" is on line 65. PSPIC causes a break, to force the previous line of text to be output, it will now be on line 66. This is the 1v, since calling PSPIC causes the break to the next line, and now it needs room for the graphic of 2pt, but since the top of the graphic is alligned to the base-line of line 66, there is no room. So the  graphic and the text "Line 3" move to the next page.

When .vs 0 is active, the break caused by PSPIC (which causes zero movement), means the top of the graphic is aligned to the base-line of line 65, so there now is room for the graphic. If you compare the 3 pdfs, hopefully it illustrates what I am trying to explain.

So I was completely wrong to say the 1v occurs after the graphic, it is in fact the break onto a new line where the top of graphic aligns to tat base-line.

(file #40593)

Deri James <deri>
Group Member
Thu 04 May 2017 08:35:55 PM UTC, comment #9: 


> Yes, so the maximum amount of usable space which
> is lost, is 1v.


No, the maximum amount of usable space that is lost (for any size graphic) is the height of the graphic.

Consider three cases, with a 10cm x 10cm graphic as an example.

1. At the bottom of the page is room for the graphic plus one line of text.  PSPIC happily puts the graphic and its following line of text there.

2. Add one line of text above the graphic, so that there is no longer room on the page for the line of text below it.  There are still 10cm of usable vertical space at the bottom of the page.  But PSPIC will not use that space; because of the +1v requirement, it will move the entire graphic to the next page, resulting in a 10cm blank vertical space.

3. Add another line of text above the graphic.  Now there is insufficient space for the graphic on the page at all, so it must be moved to the next page.  This results in 10cm - 1v of blank space at the bottom of the page, but since the graphic had to appear at that point in the text, this space is unavoidable: this is not "usable space" unless the author rearranges things.

It is case 2 I am hoping to fix, so that those 10cm do not go to waste when the graphic can fit there.  Cases 1 and 3 already do the best thing it is possible to do in those scenarios.

Dave <barx>
Group Member
Thu 04 May 2017 06:15:47 PM UTC, comment #8: 


> Sorry if I was unclear.  I am referring to the case where an image fits at
> the bottom of a page, but PSPIC insists on moving it to the next page
> anyway, because +1v.  This move only results in an empty space that could
> have been filled with something useful.


Yes, so the maximum amount of usable space which is lost, is 1v. So for a large graphic the percentage lost is small.

> I'm no macro wizard, but surely there is a way for PSPIC to supply vertical
> space below the image if text continues there, while still allowing the
> image to sit at the bottom of a page.


I have not earned my wizarding wand either, but I do know that groff is a single pass system, so you don't know what is following. You do know the position on the page where the next output will occur but this does not help if PSPIC was called within a diversion which is subsequently then output at a later point.

We need a wizard!

Deri James <deri>
Group Member
Thu 04 May 2017 09:18:45 AM UTC, comment #7: 


> The problem with changing it is that it breaks backward
> compatibility, which is important for software which has
> been around for a long time. A document created 15 years
> ago should render the same now as it did then.


I do not believe that is the goal of backwards compatibility.  I believe the goal is that any document created 15, 20, 30 years ago should continue to render (1) in a manner consistent with historical *roff documentation, and (2) in a way that at least meets, if not exceeds, typographic quality of past releases.

Point (1) is inapplicable here, as the behavior in question was never documented.  Had PSPIC's "+1v" been documented, I'd agree that it shouldn't be changed.  But anyone relying on it was already relying on undocumented behavior.

Regarding point (2), groff is frequently changed in ways that make documents render differently in order to improve output.  For instance, about a month ago, commit 905c397815fee6356184f9afc637e94da4735cdf substantially edited tmac/hyphenex.us, which changes how a number of words might be hyphenated.  Resultant changes in rendering are probably minuscule, but an altered hyphenation in just the right place could change how many lines a paragraph takes up, and thus, where a page break occurs.  It's a risk associated with improving typographic quality.

The open question, then, is whether eliminating PSPIC's "+1v" improves the document.  On this topic:

> I don't quite see how the problem changes with the size
> of the image, the amount of "wasted" white space underneath
> a graphic is always just 1v, it does not change.


Sorry if I was unclear.  I am referring to the case where an image fits at the bottom of a page, but PSPIC insists on moving it to the next page anyway, because +1v.  This move only results in an empty space that could have been filled with something useful.

To me, this is a clear case where altering historical rendering results in improved typographic quality.  And this is the only case that would change: with any number of lines below the image on the page, the rendering would stay as it was.

> If you consider the case where a graphic does not extend
> too close to the bottom of the page, it is "usual" to have
> a line of white space between the bottom of the image
> and following text. So, if this behaviour was altered,
> any document which relied on this behaviour would look
> ugly since this space would disappear.


A good point.

I'm no macro wizard, but surely there is a way for PSPIC to supply vertical space below the image if text continues there, while still allowing the image to sit at the bottom of a page.

> Any change would also have to consider the impact if
> PSPIC is used within a diversion, i.e. not at the point
> it is actually being output to the page.


True.  I have not tested this.

Dave <barx>
Group Member
Wed 03 May 2017 08:35:31 PM UTC, comment #6: 

The problem with changing it is that it breaks backward compatibility, which is important for software which has been around for a long time. A document created 15 years ago should render the same now as it did then. This is an aspiration, it is not always true, but it is something we should aim for.

I don't quite see how the problem changes with the size of the image, the amount of "wasted" white space underneath a graphic is always just 1v, it does not change. The problem of huge amounts of white space at the bottom of a page because a particular graphic won't fit is always going to be there, pictures do not get wrapped around a page boundary. In fact, the larger the image the smaller the percentage of waste caused by 1v.

If you consider the case where a graphic does not extend too close to the bottom of the page, it is "usual" to have a line of white space between the bottom of the image and following text. So, if this behaviour was altered, any document which relied on this behaviour would look ugly since this space would disappear. Any change would also have to consider the impact if PSPIC is used within a diversion, i.e. not at the point it is actually being output to the page.

Deri James <deri>
Group Member
Wed 03 May 2017 07:14:39 PM UTC, comment #5: 

Thank you both for your work in analyzing this!

Because this behavior is undocumented, I submit that we can change it in a way that typographically improves the output.  Its current behavior is subpar whether there is a caption or not.

If the image has a caption, the user needs to make sure there's space for the caption on the same page anyway.  PSPIC's "+1v" won't do that; the macro cannot know how many lines a caption might run, or whether it will even be in the same point size as the previous text.

If the image has no caption, pushing it onto the next page -- leaving a large blank space at the bottom of the current one -- is a typographically insane solution.  (In the small image of my example, this is not as big a deal, but an image of any appreciable size leaves a lot of unnecessary blank space.)

In fact, when there's no caption, having one line of text after the image is typographically inferior to having no lines or two lines.  It is irrational for PSPIC to require one.

I'm glad there's a simple workaround, but PSPIC shouldn't require extra steps to do the logical and expected thing.

Dave <barx>
Group Member
Wed 03 May 2017 06:18:43 PM UTC, comment #4: 

It looks like the "+1v" was in the original version (2000) so I don't think we can arbitrarily change it. There may well be a typographical convention which advises that there should be at least one line of text following a graphic, certainly would be true if the graphic was intended to be followed by a caption, and since PSPIC does not internally deal with captions, I can see why this might be a "good idea".

It is generally a good idea to set .vs 0 before any drawing commands as well if you need absolute positional control.

Cheers

Deri

Deri James <deri>
Group Member
Wed 03 May 2017 01:23:52 PM UTC, comment #3: 

I think you're right, Deri.

See attachment.

The question now is: is this a bug or a caveat that should be documented somewhere?

(file #40571)

G. Branden Robinson <gbranden>
Group administrator
Mon 01 May 2017 04:51:59 PM UTC, comment #2: 

Is this because line 90 of pspic.tmac "needs" the height of the graphic PLUS 1v whilst the vertical movement after the graphic is output is only the height of the graphic, so it is needing more vertical space than it uses for the graphic. This ensures there is room for at least one line after the graphic.

I suppose this could be avoided by setting .vs 0 before the .PSPIC call (and .vs after). (NOT TESTED!!)

Deri James <deri>
Group Member
Mon 01 May 2017 01:58:18 PM UTC, comment #1: 

I can reproduce this but I am unable to tell why it's happening.

I'm attaching a diff of groff intermediate output (groff_out(5)) in case that helps someone with more expertise.

(file #40543)

G. Branden Robinson <gbranden>
Group administrator
Sun 09 Apr 2017 07:38:54 PM UTC, original submission:  

Consider a 2x2 EPS file.  A simple example containing only a dot--call it "dot.eps"--would be:

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 0 0 2 2
/Times-Roman findfont 8 scalefont setfont 0 0 moveto
(.) show

Take a groff file that puts three lines at the bottom of a page: a line of text, this tiny EPS image (via .PSPIC), and another line of text:

.sp 63
Line 1
.PSPIC -L dot.eps
Line 3

"Line 3" ends up at the very bottom of the page, and no second page is needed.

Now increase the .sp from 63 to 64.  What this should do is leave the EPS image at the bottom of the first page, and move "Line 3" to the top of the second page.

What it does instead is put both the EPS image and "Line 3" at the top of the second page, despite there being plenty of room for a 2x2 image below "Line 1" on the first page.

I included "Line 3" for illustration purposes, but this bug is triggered even if "Line 3" is absent, meaning that the ".sp 64" case generates an unwanted extra page of output, when all the output should fit on one page.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #40593:  savannah-50770-v2.tar.gz added by deri (5KiB - application/gzip - Example PDFs)
file #40571:  savannah-50770-repro.tar.gz added by gbranden (3KiB - application/octetstream)
file #40543:  bug_50770_groff_out.diff added by gbranden (627B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by deri (Posted a comment)
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-09-19 barx StatusNeed Info Confirmed
        Assigned tobarx None
    2024-08-09 gbranden StatusConfirmed Need Info
        Assigned toNone barx
    2021-05-14 barx CategoryNone Macro package - others/general
    2017-05-05 deri Attached File- Added savannah-50770-v2.tar.gz, #40593
    2017-05-03 gbranden Attached File- Added savannah-50770-repro.tar.gz, #40571
    2017-05-03 gbranden StatusNone Confirmed
    2017-05-01 gbranden Attached File- Added bug_50770_groff_out.diff, #40543

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code