On Tue, Aug 22, 2006 at 11:35:12PM +0200, Andreas L Delmelle wrote:
> 
> Hi all,
> 
> 
> I've been doing some thinking myself about the separation between  
> element-list creation and actual line-breaking, and went wandering  
> through the related sources. Just checking here if my initial  
> estimates are correct.

Which problem are you trying to solve? Paragraph layout where the line
width changes in the paragraph?
 
> At first glance, a possible separation seems already prepared in some  
> way:
> LineLM.createLineBreaks() is already a separate method, so could in  
> theory be called independently from LineLM.collectInlineKnuthElements 
> () --maybe depending on a boolean switch passed into  
> LineLM.getNextKnuthElements() (as a first step?)

That separation is certainly there. It is a basis of the Knuth
algorithm. The Knuth elements are an abstract representation of the
text, containing precisely the information that the linebreaking
algorithm requires. That representation must be known when the
algorithm starts, and forms its input.
 
> The only gotcha seems to be the TODO on lines 580-582 in  
> LineLayoutManager, where the 'available IPD' is passed into  
> collectInlineKnuthElements().

Indeed, this invalidates the independence of the two phases, and
cannot be fundamental.
 
... snip...

> The start(from) and end(to) element for the sublists could be  
> estimated, based on the content-width, line-height and the context's  
> ipd/bpd-constraints:
> if minimum-line-height X allows L lines to be stacked in BP direction
> => room for a maximum of (L * available-IPD) in unbroken content-width
> 
> If the actual last element that fits in the context turns out not to  
> be the last element of the sublist, a pointer should be kept to the  
> first element in the remainder of the processed list for which  
> baseList.indexOf() does not return -1, in order to obtain the start  
> element for the next call.
> 
> As such, before making each 'processElementList(from, to, ...)'  
> request, the higher level LM gets a chance to update the layout- 
> context if there is a change in available IPD --for instance due to a  
> (deferred) side-float, or a change in page-master and/or reference- 
> orientation.
> 
> The breaker, on the other hand, could suspend or interrupt the  
> process, for instance upon encountering a start-float, so that the  
> next iteration starts with the float's element list (= finish current  
> line, return control to the higher level LM, treat the float, if  
> necessary update layout-context's ipd, and resume the breaking in the  
> updated context)
> If the float fits on the page, then this should offer a reasonable  
> guarantee that it will end up starting on the line following the one  
> that contains its anchor.

This may be possible, but it does not seem to be in the spirit of the
algorithm. The algorithm calculates the best layout up to the current
linebreak. You can always interrupt the calculation and resume later,
provided you keep the list of active nodes. If you want N lines, then
you do not determine in advance the end element. You proceed until you
have all active nodes that end line N, and then determine the best of
them. But it is even better to continue to the end of the paragraph,
taking the modified line width into account. That gives you the best
total-fit for the whole paragraph. In that total-fit, the layout for
the first N lines may be suboptimal, but then it is offset by a better
result for the remaining lines.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu

Reply via email to