<div dir="ltr">Hi,<div>I'm trying to implement chained text boxes in Draw, i.e. linking boxes logically so that text that cannot fit in one can overflow in its successor.</div><div><br></div><div>Last week I spent some time to progress on the following subgoals:</div>

<div>- take inspiration from how Writer does it (such a feature is already present for Writer frames);</div><div>- figure out in which part of the code in editeng should be modified to achieve the same result in Draw.</div>

<div><br></div><div>In general I'm looking at the code to find answers to the following questions:</div><div>(a) how can one observe an overflow of text in a frame/box? </div><div>(b) after the point where overflow occurs is found, how to 'assign' the remaining text to the successor?</div>

<div>(c) what kind of abstractions are used for text (paragraph potions, line portions) during layouting and how to use them?</div><div><br></div><div>Although I found some important references in the code, my findings are still incomplete and my few small experiments so far have failed.</div>

<div>Below I will try to elaborate more on some related code references I came to know about.</div><div><br></div><div><br></div><div>In Writer</div><div>-----------</div><div><br></div><div>First, the way Writer carries around information about predecessor/successor in chains is by means of a derived class of SfxPoolItem, <a href="http://docs.libreoffice.org/sw/html/classSwFmtChain.html">SwFmtChain</a>.</div>

<div>In formatting phase, however, this information seems to be accessed directly from frames themselves ( <a href="http://docs.libreoffice.org/sw/html/classSwFlyFrm.html">SwFlyFrm</a> ) by the methods GetNextLink/GetPrevLink.</div>

<div>Then I tried to figure _how_ this information was used from formatting routines. Breaking in GetNextLink, however, has a very high rate of hit and has not been helpful in any way (I couldn't get any intuition from the backtrace). Neither has been reading manually all the code this method is referenced by (from Writer docs).</div>

<div>So far I assuemd this was the only point of access to that information (successor), this hypothesis might be false or that code is too complicated for my eyes at this stage.</div><div><br></div><div>In Draw</div><div>

----------</div><div><br></div><div>Although knowing "how Writer does it" would probably be useful, what is necessary is understanding where to modify formatting code in Draw.</div><div>Two crucial methods seems to be:</div>

<div>1) ImpEditEngine::FormatDoc</div><div>2) ImpEditEngine::CreateLines (called by FormatDoc for each paragraph)</div><div><br></div><div>CreateLines's responsibilities seem to be to restructure the lines in a paragraph (if they changed) so that they fit in the X boundaries.</div>

<div><br></div><div>FormatDoc's responsibilities seem to include:</div><div>- calling CreateLines for each paragraph portion,</div><div>- update some view's information if the height of the paragraph changed.</div>

<div><br></div><div>It seems plausible that FormatDoc is the place where an overflow event is observed (directly or indirectly, by invoked methods) and text should be assigned to its next link in the chain if such an overflow occurs</div>

<div><br></div><div>This week</div><div>-------------</div><div><br></div><div>Current goals include understanding FormatDoc's code further trying to answer questions (a) and (b) above.</div><div><br></div><div>Cheers,</div>

<div>Matteo</div></div>