> 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 p
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
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
prioriti
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
> 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 i
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 U
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 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'
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
> shrink
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
10 matches
Mail list logo
