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

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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-14 barx CategoryNone Macro - 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.13-3230.
    Corresponding source code