done.
On 18.05.2005 00:58:46 Glen Mazza wrote:
> I believe you had also commented out some Maker classes in
> layoutmgr.LayoutManagerMapping for unused table LMs. Can we get rid of
> those now as well?
>
> Thanks,
> Glen
>
>
> [EMAIL PROTECTED] wrote:
>
> >jeremias2005/05/17 02:10:40
Thanks for taking the time to do this analysis. I was wondering where
we were standing on performance.
I think it is clear from the 12sec->7.8 sec drop that keeping
logging/stdout output reduced helps performance. Keeping quiet seems to
be Xalan's approach as well.
I looked at our commerici
Luca Furini wrote:
Footnotes should be working now.
Excellent--Very impressive work!!!
Two annotations concerning the footnote separator:
- is it correct to assume that the footnote separator is the same on each
page containing footnotes, or it could have some page-dependant content?
At the mome
I believe you had also commented out some Maker classes in
layoutmgr.LayoutManagerMapping for unused table LMs. Can we get rid of
those now as well?
Thanks,
Glen
[EMAIL PROTECTED] wrote:
jeremias2005/05/17 02:10:40
Modified:src/java/org/apache/fop/layoutmgr/table
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
Hi Jeremias and others interested in table-borders,
(Sorry for the --again-- long post, but...)
The following comment in the code (TCLM) got me wondering...
> //Create empty grid units to hold resolved borders of
> -Original Message-
> From: Luca Furini [mailto:[EMAIL PROTECTED]
>
Hi Luca,
First of all: compliments on yet another Nice Job!
> At the moment the page breaking algorithm is quite "strict": it tries to
> insert every footnote in the same page where their citation is (the last
> footnot
Luca Furini wrote:
The recommendation seems to suggest that it could defer one or more
*whole* footnotes, if there is not enough space in the page where their
citations are, even if this is not very usual to happen in books;
Actually, this is *very* unusual, and can only happen if there is
only a s
Jeremias Maerki wrote:
For all those who'd say now that "the new FOP is too slow, I'm going
somewhere else" (or something like that),
Well, 20% more time isn't all that bad. And remember, there was
a great speed up (around 30%) between 0.20.4 and 0.20.5.
J.Pietschmann
On Mon, May 16, 2005 at 07:27:27PM +0200, Jeremias Maerki wrote:
> I've just run readme.fo (from the examples) through both 0.20.5 and CVS
> HEAD, 20 times in 1 thread, to satisfy my curiosity. I don't want to
> hide these numbers from you:
>
> 0.20.5 takes 6.3 seconds for that.
>
> CVS HEAD took
The code is still hot, although not as hot as when you tried first
time.
Simon
On Mon, May 16, 2005 at 09:13:51PM -0400, Glen Mazza wrote:
> trying again...
>
> Original-Nachricht
> Betreff: Layout simplifications
> Datum:Mon, 16 May 2005 18:14:52 -0400
> Von: Gle
On Tue, May 17, 2005 at 04:48:07PM +0200, Luca Furini wrote:
>
> Footnotes should be working now.
Great.
> At the moment the page breaking algorithm is quite "strict": it tries to
> insert every footnote in the same page where their citation is (the last
> footnote body could be split, and part
Team,
Currently the LM classes that use the Knuth breaking strategy employ the
breaking via a nested (inner) class --
PageSequenceLayoutManager.PageBreaker, for example. This is causing
some duplication in methods (getNextKnuthElements(), for example) and
variables in each of the Breaker class
Jeremias Maerki wrote:
> I don't know if it helps anyone but I've just found a solution to a
> problem that has popped up from time to time on my machine when building
> FOP.
Wow, thanks, you saved me from madness!
Yesterday I was trying to merge my modified code back with HEAD and I
spent all a
Footnotes should be working now.
At the moment the page breaking algorithm is quite "strict": it tries to
insert every footnote in the same page where their citation is (the last
footnote body could be split, and partially deferred to the next page).
The recommendation seems to suggest that it c
trying again...
Original-Nachricht
Betreff:Layout simplifications
Datum: Mon, 16 May 2005 18:14:52 -0400
Von:Glen Mazza <[EMAIL PROTECTED]>
An: fop-dev@xmlgraphics.apache.org
Team,
Currently the LM classes that use the Knuth breaking strategy employ the
breaking
15 matches
Mail list logo
