\par creates space in the wrong location

[raphCode]

In this document:

\begin[papersize=a9]{document}
\set[parameter=document.parskip, value=30pt]
\par  % troublemaker
aaa
\vfill
bottom text
\par
\break
\end{document}

(papersize a9 is just to create small screenshots)

The first \par creates a space on the bottom of the page, lifting the "bottom text" from the bottom of the content frame:

Adding a \hbox at the beginning of the document or removing the first \par yields the correct result with the bottom text aligned to the bottom:

Is that the intended behavior?

[Omikhleia]

Running with -d all and comparing the ouput with the \par and without it...

So far so good, when pagebuilder:findBestBreak() works, the only difference is the 30pt top parskip.

Note: all vboxes are dumped in the debug, but afterwards the method skips top glues for the purpose of measuring the vertical content and finding an appropriate break. That's quite correct in my opinion (see further below). One may appreciate, though, the fanciness of that piece of art (absence of comments, going back and forth in indexes, complex restart logic which I hope is not used at all -- erm, seems commented out indeed elsewhere, pfeww).

But then...

"ouputting" is the last debug from pagebuilder:findBestBreak().
After, we are in typesetter.setVerticalGlue(), which is responsible for adjusting stretchable/shrinkable glues. And we see that the supposedly ignored top glue has been taken into account. And that is a bug, resulting in the other glues (here the infinite vfill) not to be stretched as much as expected.

From "OUTPUTTING", we now are in typesetter:outputLinesToPage() and the latter ignores top explicit/discardable glues with a spiffy / wacky comment "Annoyingly, explicit glue should disappear at the top of a page. if you don't want that, add an empty vbox or something." -- That's consistent with what findBestBreak did... Er. Or is it? The latter skipped glues regardless of them being explicit/discardable. Oh my. Anyway, that's not consistent with what setVerticalGlue() does...

Short recap conclusion:

• It's indeed a bug, more important than the edge-case issue that raised it (that \par inserted a parskip, but any vertical glue would have been subject to the same problem)
• The implementation shows lots of discrepancies... EDIT: And heavy code smell. I'm staying polite, due to the age of SILE. Nah, I'm just being ironic.
• I'm feeling sad nobody tried at least to do what I did = just run the MWE and compare debug outputs) EDIT: And that @raphCode had to wait 3 months for at least a feedback...

[raphCode]

Thanks for taking the time to analyze this! :)
I still don't understand SILE internals enough to fully comprehend your description so I can just say Kudos!

---

• I'm feeling sad [...] that @raphCode had to wait 3 months for at least a feedback...

I don't really mind waiting, I know people are busy and the bug is not a blocker for me.
I just want this project to succeed / become better so I filed a bug.

• The implementation shows lots of discrepancies... EDIT: And heavy code smell.

To me, the project looks like it evolved historically and that always comes with non-optimal code. That is often even required for some time to explore the desired direction and goals of the project / algorithms.
If it has been figured out how things should work, it paves the way for a beautiful rewrite someday.
I saw some nicer code in other places and noticed some refactors / rewrites in the development history, so I am confident everything will improve eventually :)