RE: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
> Andrejus, I think it's best if you read all the threads here on fop-dev > on auto table layout during August if have not already done so. They > contain a lot of information about the next steps for the auto table > layout and what has been discussed so far. Ok, thank you for pointing to right place as well as for additional comments on LMs. Will try my best during upcoming week. Andrejus
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Well, given that I wrote most of the new table layout code I'd be the one who knows exactly how it works (or at least I'm supposed to know). Anyway, at the moment I don't know what exactly I can contribute to get Andrejus better on his way. For getting the auto table layout feature right, you don't need to know too much about the inner workings of the table layout managers. Also, don't concern yourself to much with the area tree while trying to understand table layout. The area tree is only the last step. The thing to focus on are the element lists created by LineLayoutManager. If you look at the current auto table patch you'll see which classes are really affected in the "table" package: TableLM and TableCellLM. No need to dive into TableContentLM or TableStepper which are complex beasts. Andrejus, I think it's best if you read all the threads here on fop-dev on auto table layout during August if have not already done so. They contain a lot of information about the next steps for the auto table layout and what has been discussed so far. http://www.nabble.com/-GSoC--Auto-table-layout-questions-tf1933306.html http://www.nabble.com/Q%3A-Line-layout--%3E-separating-element-list-creation---line-breaking-tf2148860.html On 05.10.2006 14:54:50 Simon Pepping wrote: > On Wed, Oct 04, 2006 at 11:18:22PM +0300, Andrejus Chaliapinas wrote: > > But that still doesn't answer the question - if there are some Knuth > > elements constructed - what is the best way to debug current Area Tree, > > which contains them? And if there any mechanism to protect particular Area > > Tree leafes (or graphs/branches) from additional restructure. Sorry if it's > > out of context, i.e. we should never bother with such kind of protection > > cause Knuth elements are pushed there during their processing. > > If you want to study the area tree that is created, use the area tree > output, command line option -at outfile: representation of area tree > as XML (outfile req'd). > > Protecting the area tree or parts thereof is not relevant. The area > tree is only constructed once. > > First the FO tree is constructed. Then the tree of LayoutManagers is > constructed. These construct the Knuth elements. Then the Line or Page > Breaker does its work. Then the LMs resume and construct the areas, > according to the line and page breaking results and according to the > content of their FOs, for which the Knuth elements contain > pointers. The PageSequenceLM directs the page layout process, the > LineLMs direct the paragraph layout process. The latter also happens > in the table cells. I believe the TableLM directs the whole layout > process of a table. This is where you want to enable auto table > layout. But I am not aware of all details of table layout. I hope > other FOP developers are able to help you. > > Regards, Simon > > -- > Simon Pepping > home page: http://www.leverkruid.eu Jeremias Maerki
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
I doubt anyone currently has much time to write such documentation. Yes, the design document on the web is outdated and the Wiki does not contain an overview of the whole layout engine. That's not so good but reflects how many resources we have for this project. It requires that we set our priorities on the absolutely necessary. Sorry. Simon once wrote some extensive documentation about the layout engine, but that applied to the design before the switch to the Knuth element model. On 05.10.2006 14:29:28 Andrejus Chaliapinas wrote: > > J.Pietschmann wrote: > > > Simon Pepping wrote: > > >> No UML diagrams for FOP available. Would be nice though. > > > > > > As soon as I get some spare time, I'll try > > > http://sourceforge.net/projects/umldot > > > I suspect the diagrams to be somewhat unwieldy. > > > > > > J.Pietschmann > > > > > I think that is not good choice for genetaring UML diags, while > > http://sourceforge.net/projects/umldot is in version 0.1.0 and no > > screeenshot. On sourceforge are plenty of abondoned or too new projects > > to be usable. > > Have you tried to use EclipseUML > (http://eclipse-plugins.2y.net/eclipse/plugin_details.jsp?id=151)? > > But again - if someone could write some detailed doc on those LMs > interactions (I don't see that now in design documents) - I could try and > generate then those myself. > > Andrejus Jeremias Maerki
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
On Wed, Oct 04, 2006 at 11:18:22PM +0300, Andrejus Chaliapinas wrote: > But that still doesn't answer the question - if there are some Knuth > elements constructed - what is the best way to debug current Area Tree, > which contains them? And if there any mechanism to protect particular Area > Tree leafes (or graphs/branches) from additional restructure. Sorry if it's > out of context, i.e. we should never bother with such kind of protection > cause Knuth elements are pushed there during their processing. If you want to study the area tree that is created, use the area tree output, command line option -at outfile: representation of area tree as XML (outfile req'd). Protecting the area tree or parts thereof is not relevant. The area tree is only constructed once. First the FO tree is constructed. Then the tree of LayoutManagers is constructed. These construct the Knuth elements. Then the Line or Page Breaker does its work. Then the LMs resume and construct the areas, according to the line and page breaking results and according to the content of their FOs, for which the Knuth elements contain pointers. The PageSequenceLM directs the page layout process, the LineLMs direct the paragraph layout process. The latter also happens in the table cells. I believe the TableLM directs the whole layout process of a table. This is where you want to enable auto table layout. But I am not aware of all details of table layout. I hope other FOP developers are able to help you. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
RE: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
> J.Pietschmann wrote: > > Simon Pepping wrote: > >> No UML diagrams for FOP available. Would be nice though. > > > > As soon as I get some spare time, I'll try > > http://sourceforge.net/projects/umldot > > I suspect the diagrams to be somewhat unwieldy. > > > > J.Pietschmann > > > I think that is not good choice for genetaring UML diags, while > http://sourceforge.net/projects/umldot is in version 0.1.0 and no > screeenshot. On sourceforge are plenty of abondoned or too new projects > to be usable. Have you tried to use EclipseUML (http://eclipse-plugins.2y.net/eclipse/plugin_details.jsp?id=151)? But again - if someone could write some detailed doc on those LMs interactions (I don't see that now in design documents) - I could try and generate then those myself. Andrejus
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
J.Pietschmann wrote: Simon Pepping wrote: No UML diagrams for FOP available. Would be nice though. As soon as I get some spare time, I'll try http://sourceforge.net/projects/umldot I suspect the diagrams to be somewhat unwieldy. J.Pietschmann I think that is not good choice for genetaring UML diags, while http://sourceforge.net/projects/umldot is in version 0.1.0 and no screeenshot. On sourceforge are plenty of abondoned or too new projects to be usable. But it is a good idea to generate it (and UML is lovely). Look here, maybe Alma is good choice. Also eclipse TPTP can produce graphical representation of workflow - sequence diagram, but as I know it hasn't got any good export format. Tomas
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
Simon Pepping wrote: No UML diagrams for FOP available. Would be nice though. As soon as I get some spare time, I'll try http://sourceforge.net/projects/umldot I suspect the diagrams to be somewhat unwieldy. J.Pietschmann
RE: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
> I do not really know why Patrick created a second TableContentLM. His > procedure constructs the Knuth elements twice. I suppose that he > feared that this would have side effects, and that he tried to avoid > those by doing the first evaluation in another TableContentLM. > But that still doesn't answer the question - if there are some Knuth elements constructed - what is the best way to debug current Area Tree, which contains them? And if there any mechanism to protect particular Area Tree leafes (or graphs/branches) from additional restructure. Sorry if it's out of context, i.e. we should never bother with such kind of protection cause Knuth elements are pushed there during their processing. > No UML diagrams for FOP available. Would be nice though. Well, maybe one day if I'll become familiar enough with whole project I'll produce one. Probably first it would be just good to have such sequence described by words, but in FOP Design: Layout document it talks only about separate LMs, so whole picture is missing. Andrejus
Re: Do we have Area Tree construction also via getNextKnuthElements methods or mostly via addAreas?
On Wed, Oct 04, 2006 at 01:59:07PM +0300, Andrejus Chaliapinas wrote: > Hi, > > I'm trying to understand why in Patrick's code, when he deals with Table > auto layout feature, after TableContentLayoutManager over current > TableLayoutManager is prepared and processed with required columns > shrinking/extra space distribution - there is another > TableContentLayoutManager creation (yes, this was already commeted by > Jeremias as no go approach)? Is it because something in Area Tree (some part > of its graph) needs to be reevaluated once more (due to changed column > width/columnMins/anything else)? > > If I comment second construction - then auto table layout testcase (yes > Manuel, that's why I was focused on them) fails due to incorrect IPDA value > for the first block presence in resulted area tree xml file. I do not really know why Patrick created a second TableContentLM. His procedure constructs the Knuth elements twice. I suppose that he feared that this would have side effects, and that he tried to avoid those by doing the first evaluation in another TableContentLM. > Any help would be appreciated. I think it would be great if we could have > UML sequence diagram for those LM invocations/dependencies during some > general table processing. No UML diagrams for FOP available. Would be nice though. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
