On Mon, 5 Sep 2005 09:51 pm, Jeremias Maerki wrote: > I think you're reaching a point where you should understand exactly > how the Knuth model works.
It had to happen eventually :-). > I haven't looked at how conditionality is > implemented very closely. Without diving deeper into this myself I'm > unable to help right now other than to point you to > BlockStackingLayoutManager again which contains at least part of the > code that deals with space conditionality. If the comments are right > in BlockStackingLayoutManager conditionality has not even been > implemented for blocks in the b-p-d. > > If you really want to go down that road I suggest you get Donald > Knuth's "Digital Typography" or another book that contains the essay > "Breaking Paragraphs into Lines". There may also be a little > information about handling conditionality in the mailing list > archives. Sorry that I can't help more, but we're getting into > complicated terrain here. > That's fine - I am just trying to extract as much information as possible the "easy way" first. Also, even if conditionality is not implemented may be some of the original designers of the implementation would like to share their thoughts on this topic? I'll see if I can get my hand on the book in the university library here (btw - I am in Perth - Western Australia). In the meantime I'll stick with the "discard" model which happens to be the default anyway. Manuel > On 05.09.2005 14:52:23 Manuel Mall wrote: > > On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote: > > > Jeremias, > > > > > > thanks for your patience in answering my questions. > > > > > > On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote: > > > > On 04.09.2005 16:34:35 Manuel Mall wrote: > > > > <snip/> > > > > > > > Another question for the "Knuth" experts. It appears the > > > > > inline LMs don't make provisions in the IPD for > > > > > borders/padding on inlines. I assume border/padding is > > > > > logically like a (with the width of the border + > > > > > padding) in front of the first and after the last character > > > > > of the inline assuming > > > > > .conditionality=discard, that is we don't want to have let's > > > > > say a left border alone on the end of a line with the text > > > > > starting on the next. For .conditionality=retain this width > > > > > needs to be reserved as well at the beginning and end of each > > > > > intermediate line. Any suggestions how this can/should be > > > > > integrated into the linebreaking algorithm? > > > > > > > > Exactly like spaces, borders and padding in b-p-d for > > > > block-level objects: additional auxiliary boxes and penalties. > > > > See BlockStackingLayoutManager.addKnuthElementsFor*(). Line > > > > breaking is the same as page breaking, only in a different > > > > direction. > > > > > > Thanks for the pointer. I'll have a look at that. > > > > That seem to have done the trick. I have copied the Border/Padding > > before/after logic from BlockStackingLayoutManager and made it into > > a Border/Padding start/end for the Inline LM. There were some side > > effects in that the Line LM expectd only KnuthInlineBoxes and now > > we have some KnuthBoxes as well but I think I solved that ok. > > > > Next problem: border conditionality - how do I model that with the > > Knuth approach? At the time I add the Border/Padding start/end > > boxes we don't have line breaks so they really only cover the > > .conditionality=discard case. How do I tell the algorithm to leave > > enough space at the end of each line (and the beginning of the next > > line) for the borders (in the case of .conditionality=retain)? > > > > > > <snip/> > > > > > > > > > > > > Jeremias Maerki > > > > > > Manuel > > > > Manuel > > Jeremias Maerki
