On 2023-Jan-20, Karl O. Pinc wrote:
> On Fri, 20 Jan 2023 12:42:31 +0100
> Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > Hmm, I didn't know that. I guess I can put it back. My own instinct
> > is to put the most important stuff first, not last, but if research
> > says to do otherwise, fine, let's do that.
>
> A quick google on the subject tells me that I can't figure out a good
> quick google. I believe it's from the book at bottom. Memorability
> goes "end", "beginning", "middle". IIRC.
Ah well. I just put it back the way you had it.
> > I hope somebody with more docbook-fu can comment: maybe
> > there's a way to fix it more generally somehow?
>
> What would the general solution be?
I don't know, I was thinking that perhaps at the start of the appendix
we could have some kind of marker that says "in this chapter, the
<sect1>s all get a page break", then a marker to stop that at the end of
the appendix. Or a tweak to the stylesheet, "when inside an appendix,
all <sect1>s get a pagebreak", in a way that doesn't affect the other
chapters.
The <?hard-pagebreak?> solution looks really ugly to me (in the source
code I mean), but I suppose if we discover no other way to do it, we
could do it like that.
> There could be a forced page break at the beginning of _every_ sect1.
> That seems a bit much, but maybe not. The only other thing I can
> think of that's "general" would be to force a page break for sect1-s
> that are in an appendix. Is any of this wanted? (Or technically
> "better"?)
I wouldn't want to changing the behavior of all the <sect1>s in the
whole documentation. Though if you want to try and garner support to do
that, I won't oppose it, particularly since it only matters for PDF.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
more or less, right?
<crab> i.e., "deadly poison"