[luatex] Bug in tex.linebreak ?

[Frank Mittelbach]

Am 10.03.16 um 11:57 schrieb Hans Hagen:
> the normal line break function is called with a set if parameters that
> get either values from the given table or the values set at the tex end
> so if you set looseness in the table then that value is passed and if
> you don't set it the \looseness value is used
>
> now, the \looseness is normally reset when tex sees a new paragraph but
> here we don't are in that situation so if that one is used we need to
> reset it ourselves

but you only have to set the reporting element (the value of looseness 
used for actually doing the line breaking is the right one)

so I'm not sure if it is helpful to reset tex.looseness as that is 
already correct --- my guess is that you report on a local value that 
was never set so I thinkthe reporting part would need to do

   if tex.looseness == 0 then report looseness = 0
   else report actual <looseness achieved>

whereas i think you always report

  <actual looseness achieved>

only that is a variable that isn't set


>
> i'll add tex.resetparagraph that resets looseness, hangindent,
> hangafter, parshape and interlinepenalties in one go, something:
>
>          function tex.resetparagraph()
>              tex.looseness = 0
>              ...
>          end

however, having the above function available is probably useful anyhow 
(though you can do that manually if you do your own linebreaking etc
>
> [reported looseness]
>
> the reported looseness (and demerits) are currently variables that
> reflect the state set when actually a possible looseness come in play
> but i'll reset them always now (hopefully not introducing some side
> effects in current usage)

exactly that is what I think you need to do (should have read the whole 
email first) --- if the luatex internals follow the TeX algorithms then 
I don't think that could introduce issues

the alternative (though less good imo) is to just document that the 
value is rubbish if looseness=0 was used

> (the prev values are actually taken from the state lists so these are
> less local; that will be left untouched)
>
> [so]
>
> in a next release we will have (1) a resetter in order to simulate par
> behaviour, and (2) an reset of two variables also when not used
>
> hopefully that helps

sounds good. For now I can work around it as I can control what the 
intended looseness is so I can program around the 0 case ... makes for 
some ugly code that would otherwise nicer but :-)

thanks
frank