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