Re: Help with page breaking code

[David Kastrup]

Keith OHara <address@hidden> writes:

> David Kastrup <dak <at> gnu.org> writes:
>
>> #(set! empty-stencil (ly:make-stencil '() empty-interval empty-interval))
>> \markup \fill-line { }
>
>> Basically, the first \markup produces an empty stencil with extents
>> (+inf.0 . -inf.0) and the page breaking code goes bonkers on that.
>> 
>
> \paper {annotate-spacing = ##t}
> indicates proper estimates for any scores after the \fill-line, and
> indirectly shows zero space allowed for the \fill-line, so the
> height estimations seem reasonable.
>
> The problem appears only when \fill-line is the first markup, so maybe
> a bad initialization in one of
> page-breaking.cc  page-layout-problem.cc  page-spacing.cc
>
> At some point, you made a change so that \line {} would return a
> non-empty extent; possibly \fill-line needs that as well.

Actually, the current code makes \line { } empty to match \fill-line.
If you make \fill-line { } non-empty, lots of page headers take up space
even when empty.  Not an option.

> Of course I recommend first fixing the bugs you can with the existing
> definition of "empty" stencil extents.

> The redundant line in dots.cc,

I can factor and/or leave this out since the bad code had no effect
previously, and it has no effect in the current iteration, but it's
peanuts.

> the ref-point for \parenthesize, and having the spacing functions
> recognize \hspace and space appropriately, can be resolved before
> changing 'empty-stencil'.

Not really, because \hspace can (and should be able to) backspace, and
empty-stencil in its current definition is a backspacing stencil.

An any rate: Whatever code in the current code base requires
empty-stencil to not have empty-interval as extents will mess up page
size calculations: if it takes (+inf.0 . -inf.0) wrongly into account,
it will do so with (+1.0 . -1.0) as well since the latter is even less
conspicuous and thus will not get special treatment when it should.

We have reports about the general page breaking having become inferior
with 2.16 and/or 2.17.  Ignoring a bug in that area or even tampering
with new code until it for some unknown reason perhaps avoids it is not
a sane course.

-- 
David Kastrup