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
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 whe
Chris Bowditch wrote:
Peter B. West wrote:
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 a
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 pa
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.
While textIndent is initialized in the TLM co
Peter B. West wrote:
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 branches, they
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 t
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 (
Simon Pepping wrote:
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 will oc
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 ca
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
--- 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 w
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
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Hi Chris,
> 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 r
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 would have expected a
change to BLM in your patch file. Also I found a few calls to
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 would have expected a
change to BLM in your patch file. Also I found a few calls
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 t
Chris Bowditch wrote:
> I think the easiest solution will be for
> Luca to supply his complete LineLayoutManager.java and
> TextLayoutManager.java (the two files that have more than
> 1000 lines changed) Would you mind attaching them to the patch Luca?
Ok, I'm going to do it.
By the way, the cod
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
LineL
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, too
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 o
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 chu
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.
J.Pietschman
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
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:
> - firs
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 s
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 m
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 make choices about breaking points using only the
information provided by the TextLayoutManagers, while it should h
28 matches
Mail list logo
