bug-groff
[Top][All Lists]
Advanced

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

[bug #50770] .PSPIC macro at bottom of page causes unwarranted page brea


From: Dave
Subject: [bug #50770] .PSPIC macro at bottom of page causes unwarranted page break
Date: Thu, 4 May 2017 05:18:45 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0

Follow-up Comment #7, bug #50770 (project groff):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?50770>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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