Simon Pepping wrote:
snip/
No exceptions. I ran Luca's test fo files successfully.
Strange how you and I always get such different results. It doesnt run with
any file despite changing the language to en. I always get NPE on LLM:249.
Looking at the code it would appear to be a mistake as NPE
Chris Bowditch wrote:
Here is the stack trace, which is the same for both documents:
[...]
Any thoughts would be appreciated.
JThe method startParagraphs dereferences only knuthParagraphs and
textIndent, so maybe there is a missing line concerning their initialization.
KnuthParagraphs (the
Simon Pepping wrote:
I changed the constructor call as well. I changed the logger calls
from getLogger() to log. log is a member of
AbstractLayoutManager. These are changes applied by Glen, and
apparently Luca made his diff before they were applied.
Yes; more exactly, I forgot to apply
Peter B. West wrote:
snip/
Simon, yes! That's what branching is there for. People seem to be
afraid of it, but it is an enormously useful tool for just such
situations. I think it's always a good idea to tag the tree immediately
before a branch.
Hi Peter,
its not that I am afraid of
Luca Furini wrote:
JThe method startParagraphs dereferences only knuthParagraphs and
textIndent, so maybe there is a missing line concerning their initialization.
I have proved that textIndent is definitely null when it is not specified on
the block.
snip/
While textIndent is initialized in the
Luca Furini wrote:
You are completely right; by the way, what other child LMs could the LLM
have?
I'm just guessing, but I think anything that can appear inline, i.e.
hyperlinks, leaders, etc. Block level stuff like Tables and graphics can not
be children of the LLM.
I do not believe that the
On Tue, May 25, 2004 at 09:51:28AM +0100, Chris Bowditch wrote:
Luca Furini wrote:
JThe method startParagraphs dereferences only knuthParagraphs and
textIndent, so maybe there is a missing line concerning their
initialization.
I have proved that textIndent is definitely null when it is
On Tue, May 25, 2004 at 09:56:25AM +0100, Chris Bowditch wrote:
Luca Furini wrote:
You are completely right; by the way, what other child LMs could the LLM
have?
I'm just guessing, but I think anything that can appear inline, i.e.
hyperlinks, leaders, etc. Block level stuff like Tables
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Hi Chris,
snip /
Is anyone else on the team planning on making large commits over the next
couple of days? I would be grateful if you could hold off for a
couple of days
whilst the problems with this large patch are
Chris,
On Mon, May 24, 2004 at 01:57:34PM +0100, Chris Bowditch wrote:
Hi Luca,
I have managed to apply your patch. Testing has not gone well. Firstly, I
had trouble compiling, due to BLM using the old constructor for LLM with
FObj as the first argument. This is easily corrected, but I
--- Simon Pepping [EMAIL PROTECTED] wrote:
Chris wrote:
Is anyone else on the team planning on making
large commits over the next
couple of days? I would be grateful if you could
hold off for a couple of
days whilst the problems with this large patch are
resolved. I dont want to
Simon Pepping wrote:
...
I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?
If I see it right, then Luca should work on his patch some
more. Perhaps others could help with that work if he would want
that. In such a situation it may be
Glen Mazza wrote:
--- Simon Pepping [EMAIL PROTECTED] wrote:
Errr--I wouldn't want additional branches in CVS just
for the sake of a patch--they tend to become
permanent. Luca working on his local machine, or
using something on SourceForge may be a better idea.
It's just Monday right now--we can
Hi Luca,
May I start by thanking you for your hard work in submitting the patch for
Knuth's Line breaking algorithm.
I'm just starting to look at your patch now. First thing that strikes me, and
this was pointed out to me before I became a committer. Please try to avoid
commenting out large
FOP Devs,
I'm trying to apply Luca's patch and running into problems. The hunks in the
first 9/10 files get applied okay, but when the patch program gets to
LineLayoutManager, it only reconises 6 hunks, the seventh is very big and for
some reason the patch program thinks it has found the start
Chris,
I've just upgraded my sources and tried to apply the same patch within
Eclipse to see what happens. I get two parts of the patch that Eclipse
claims to be unable to apply correctly. But this only makes up a few
lines in all. Maybe if Luca would send you the whole
LineLayoutManager.java,
Jeremias Maerki wrote:
Chris,
I've just upgraded my sources and tried to apply the same patch within
Eclipse to see what happens. I get two parts of the patch that Eclipse
claims to be unable to apply correctly. But this only makes up a few
lines in all. Maybe if Luca would send you the whole
Chris Bowditch wrote:
I'm just starting to look at your patch now. First thing that strikes
me, and this was pointed out to me before I became a committer. Please
try to avoid commenting out large chunks of code. If the code is no
longer needed please delete it. If we need to go back to the
Peter wrote:
Do you know of a web-accessible version of the paper, or summary of the
algorithm?
Unfortunately I don't.
In the bugzilla issue I'm going to try and summarize it.
Regards
Luca
Peter B. West wrote:
Do you know of a web-accessible version of the paper, or summary of the
algorithm?
Try the TeX book, available as TeX-source from your nearest
CTAN server. The description is, umm, somewhat obscure, you
should get the commented TeX source (the .web files) as well.
Luca,
Do you know of a web-accessible version of the paper, or summary of the
algorithm?
Peter
Luca Furini wrote:
Hi all
I am still thinking about justification and the more general problem of
line-breaking, and I have come to think that it's quite strange that the
LineLayoutManager should
Luca Furini wrote:
I am still thinking about justification and the more general problem of
line-breaking, and I have come to think that it's quite strange that the
LineLayoutManager should make choices about breaking points using only the
information provided by the TextLayoutManagers, while it
On Wed, May 19, 2004 at 12:08:50PM +0200, Luca Furini wrote:
Hi all
So, I have tried to implement Knuth's line-breaking algorithm [1], which
calculates breaking points after having gathered information about a whole
paragraph.
Here are a few advantages of this algorithm:
- first of
23 matches
Mail list logo