Re: Justification and line breaking

[Peter B. West]

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 make choices about breaking points using only the
information provided by the TextLayoutManagers, while it should have a
wider knowledge of all the text.
(I see bug 28706 as an example of this strangeness: the LLM wants the TLM
to say if there is other text after the returned BreakPoss, but the TLM
doesn't know of the other TLMs' text)
At the moment, lines are built one at a time, and in "normal" cases only
underfull lines are taken into account: as both bpDim and availIPD have
.min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen
one is simply the last "short" BP returned by a TLM.
Even if bpDim had .min != .max, the choice would be made between a few
alternatives for the current line, without considering what will happen
next; this could generate an output alternating tight and loose lines,
which is not very beautiful.
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 all, the output is very beautiful; there is not a big
  difference in width between spaces in consecutive lines, and the max
  space width is smaller than before
- the interaction between LLM and TLM is quite the same; the TLM returns a
  different kind of objects, much smaller
- the TLM code is simplified a bit, as it has no more to handle leading
  spaces, or calculate flags (which IMO are rather line-related than
  text-related)
- the LLM now can quite easily handle properties such as text-indent,
  text-align-last, word-spacing and letter-spacing
Could I open a bugzilla issue and attach a patch? It would be quite a raw
patch, as I took some short cuts to make it work and there could be some
useless variables, anyway it works and could be used to show the quality
of the output. I have tested it with text-only blocks, so I don't know
what could happen in more complex situations.
--
Peter B. West 

Re: Justification and line breaking

[Chris Bowditch]

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 should have a
wider knowledge of all the text.
(I see bug 28706 as an example of this strangeness: the LLM wants the TLM
to say if there is other text after the returned BreakPoss, but the TLM
doesn't know of the other TLMs' text)
bug 28706 is still a bit of mystery to me, well at least the disappearing 
text, as I dont have an example of it.

At the moment, lines are built one at a time, and in "normal" cases only
underfull lines are taken into account: as both bpDim and availIPD have
.min == .opt == .max, no BreakPoss is added to vecPossEnd and the chosen
one is simply the last "short" BP returned by a TLM.
Even if bpDim had .min != .max, the choice would be made between a few
alternatives for the current line, without considering what will happen
next; this could generate an output alternating tight and loose lines,
which is not very beautiful.
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 all, the output is very beautiful; there is not a big
  difference in width between spaces in consecutive lines, and the max
  space width is smaller than before
- the interaction between LLM and TLM is quite the same; the TLM returns a
  different kind of objects, much smaller
- the TLM code is simplified a bit, as it has no more to handle leading
  spaces, or calculate flags (which IMO are rather line-related than
  text-related)
- the LLM now can quite easily handle properties such as text-indent,
  text-align-last, word-spacing and letter-spacing
Could I open a bugzilla issue and attach a patch? It would be quite a raw
patch, as I took some short cuts to make it work and there could be some
useless variables, anyway it works and could be used to show the quality
of the output. I have tested it with text-only blocks, so I don't know
what could happen in more complex situations.
this sounds like a really good idea, and would be very pleased if you could 
open a new bug in bugzilla and attach your patch. It will probably need a 
lengthy review involving plenty of testing and cleaning up.

Chris

Re: Justification and line breaking

[Simon Pepping]

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 all, the output is very beautiful; there is not a big
>   difference in width between spaces in consecutive lines, and the max
>   space width is smaller than before
> - the interaction between LLM and TLM is quite the same; the TLM returns a
>   different kind of objects, much smaller
> - the TLM code is simplified a bit, as it has no more to handle leading
>   spaces, or calculate flags (which IMO are rather line-related than
>   text-related)
> - the LLM now can quite easily handle properties such as text-indent,
>   text-align-last, word-spacing and letter-spacing

Wow. No question that this is a desirable thing to have. I thought
that it would be several releases away before we could address this.
But if you have a viable solution, by all means show it to us.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Justification and line breaking

[Luca Furini]

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

Re: Justification and line breaking

[J.Pietschmann]

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.Pietschmann

Re: Justification and line breaking

[Chris Bowditch]

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 chunks of code. If the code is no longer needed please 
delete it. If we need to go back to the old code, we can always get the 
previous versions from CVS.

Second thing, are you just ignoring word spacing and letter spacing at the 
moment? I think one of the other FOP Dev's hit the problem of "how do we tell 
if property was specified or is it just the default" before? Hopefully they 
will speak up with a work around. If we do go without the letter spacing 
property, then they really ought to stay as NotYetImplemented in the 
FOPropertyMapping and just put come comments into the code to explain why it 
cant be implemented ATM.

I'll comment again once Ive done some testing. Thanks,
Chris

Re: Justification and line breaking

[Luca Furini]

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 old code,
> we can always get the previous versions from CVS.

Ok, sorry.

> Second thing, are you just ignoring word spacing and letter spacing at the
> moment? I think one of the other FOP Dev's hit the problem of "how do we
> tell if property was specified or is it just the default" before? Hopefully
> they will speak up with a work around. If we do go without the letter
> spacing property, then they really ought to stay as NotYetImplemented in the
> FOPropertyMapping and just put come comments into the code to explain why
> it cant be implemented ATM.

No, both properties are implemented (the letter spacing only partially).
When the word spacing is not .min == .max == 0 it is used to define the
inline progression dimension of a space; otherwise, a default value is used
instead.
Letter spacing is used too, but at the moment only its .opt value is used,
so letter spacing will be the same in every line of the paragraph. The
problem is that Knuth's algorithm doesn't explicitly take into account
letter space.

Luca

Re: Justification and line breaking

[Chris Bowditch]

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 getLogger in the 
LMs, which dont compile. I hit the problem of not being able to call getLogger 
in the LM code myself recently. So I added a getLogger method to AbstractLM.

Once compiled I tried testing with a complex document, but that fell over. 
Previously it was working, albeit without markers. I then tried one of your 
more simple test cases and that fell over too. Here is the stack trace, which 
is the same for both documents:

Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
ineLayoutManager.java:249)
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:351)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
Any thoughts would be appreciated.
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 have to 
re-apply the changes. Let me know if this causes any problems

Chris

Re: Justification and line breaking

[Chris Bowditch]

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 getLogger in the
LMs, which dont compile. I hit the problem of not being able to call getLogger
in the LM code myself recently. So I added a getLogger method to AbstractLM.
Once compiled I tried testing with a complex document, but that fell over.
Previously it was working, albeit without markers. I then tried one of your
more simple test cases and that fell over too. Here is the stack trace, which
is the same for both documents:
Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
ineLayoutManager.java:249)
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:351)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
Any thoughts would be appreciated.
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 have to
re-apply the changes. Let me know if this causes any problems
Chris

RE: Justification and line breaking

[Andreas L. Delmelle]

> -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 resolved. I dont
> want to have to
> re-apply the changes. Let me know if this causes any problems
>

Not me, for the moment... The table-related adjustment turns out to be a bit
more complicated than I initially thought. (have a few other questions
regarding this, but these are going into a separate thread)


Cheers,

Andreas

Re: Justification and line breaking

[Simon Pepping]

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 would have 
> expected a change to BLM in your patch file. Also I found a few calls to 
> getLogger in the LMs, which dont compile. I hit the problem of not being 
> able to call getLogger in the LM code myself recently. So I added a 
> getLogger method to AbstractLM.

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.
 
> Once compiled I tried testing with a complex document, but that fell over. 
> Previously it was working, albeit without markers. I then tried one of your 
> more simple test cases and that fell over too. Here is the stack trace, 
> which is the same for both documents:
> 
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
> ineLayoutManager.java:249)
> at 
> org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
> tManager.java:351)
> at 
> org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
> outManager.java:202)
> 
> Any thoughts would be appreciated.

No exceptions. I ran Luca's test fo files successfully.

Note that the test files erroneously specify the language as "eng";
this should be "en".

I am not surprised that your complex document did not run well. If I
understand the situation well, then the patch works for LineLM with
TextLM childLMs. It does not work with any other childLM. I expect the
other childLMs to use the null implementation of getNextKnuthElement()
and therefore to contribute no areas. This does not explain that it
causes an exception, though.
 
> 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 
> have to re-apply the changes. Let me know if this causes any problems

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 a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Justification and line breaking

[Glen Mazza]

--- 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 
> > have to re-apply the changes. Let me know if this
> causes any problems
> 

OK--I'll hold off myself.  But from my experience
working with Finn's several huge patches, applying
these things incrementally can work wonders.

> If I see it right, then Luca should work on his
> patch some
> more. 

Sounds like it, from Chris' explanation.

> Perhaps others could help with that work if he
> would want
> that. In such a situation it may be a good strategy
> to commit the
> patch to a branch of the HEAD of the trunk, so that
> it can be
> developed without problems with other work.
> 

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 wait a few more
days.

Glen

Re: Justification and line breaking

[Peter B. West]

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 a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.
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.

Peter
--
Peter B. West 

Re: Justification and line breaking

[Peter B. West]

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 wait a few more
days.
Glen, branches are only as permanent as you make them.  They're a tool, 
and with the CVS-aware IDEs out there, they are increasingly easy to 
use.  (Until we're Subverted, anyway.  Not a comment on the product 
itself, just the expected level of third-party support.)

Peter
--
Peter B. West 

Re: Justification and line breaking

[Chris Bowditch]

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 occur if 
text-indent is not specified on any block. I tried placing a IF statement 
around this line, but got a NPE elsewhere.

I dont understand how you can run Luca's files. The NPE seem to be limited to 
LLM and TLM, which I copied complete from Luca's patch. Did you manage to 
apply the patch file with LLM/TLM, or did you copy the complete files? There 
must be some differences in our code, or am I going mad?!?


I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?
I have to agree that the patch is far from ready. I in no way mean to cast a 
bad light on Luca's work. Luca must be congratulated for his efforts thus far, 
but we cannot accept a patch that will take the redesign effort backwards. 
With more testing and the bugs fixed, this patch will take the redesign 
forwards with a much cleaner approach to line breaking. I hope Luca will be 
happy to work on his patch some more locally.

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 a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.
I have to agree with Glen on this point, -1 for creating another branch. I 
have replied in more detail in another posting.

Chris

Re: Justification and line breaking

[Luca Furini]

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 ArrayList whose item are the different
linefeed-separated paragraphs) is initialized just before calling
startParagraph:

  ...
  // it's the first time this method is called
  knuthParagraphs = new ArrayList(); /* here it is */
  breakpoints = new ArrayList();

  // convert all the text in a sequence of paragraphs made
  // of KnuthBox, KnuthGlue and KnuthPenalty objects
  Paragraph knuthPar = new Paragraph();
  knuthPar.startParagraph();
  ...

While textIndent is initialized in the TLM constructor (but this was already
in the code, it's not a change of mine):

  ...
  bTextAlignmentLast = blockProps.textAlignLast;
  textIndent = blockProps.firstIndent; /* here it is */
  hyphProps = propMgr.getHyphenationProps();
  ...

I hope this can help you; thanks for testing my patch.

Regards
Luca

Re: Justification and line breaking

[Luca Furini]

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 these changes to the code I was
already working on.
To avoid this kind of problems, I will try to keep my code updated.

> I am not surprised that your complex document did not run well. If I
> understand the situation well, then the patch works for LineLM with
> TextLM childLMs. It does not work with any other childLM. I expect the
> other childLMs to use the null implementation of getNextKnuthElement()
> and therefore to contribute no areas.

You are completely right; by the way, what other child LMs could the LLM
have?

> I do not believe that the patch is mature for committing to the trunk
> code. See above. Luca, do you share my view?

Completely: I submitted the patch to get a first feedback, comments,
suggestions ...

I thank all that spent some time looking at it and testing it, and I
apologize if I have not been able to clearly explain what my aim was.

I'll work on this patch for some more time, and I'll let you know of the
progress.

Regards
Luca

Re: Justification and line breaking

[Chris Bowditch]

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 have their uses, but I feel the 
project is at the wrong stage in its development for another branch right now. 
Branches invariably mean splitting development focus. Right now I want to 
focus on fixing the High priority issues with layout so we can do a release. 
If we flail around for another year or so then FOP may be dead in the water as 
other projects overtake it.

Chris

Re: Justification and line breaking

[Chris Bowditch]

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 constructor (but this was already
in the code, it's not a change of mine):
I assume you mean the LLM constructor?
  ...
  bTextAlignmentLast = blockProps.textAlignLast;
  textIndent = blockProps.firstIndent; /* here it is */
  hyphProps = propMgr.getHyphenationProps();
  ...
and if blockProps.firstIndent returns null? Which it appears to be if the user 
doesnt specify on a block.

I hope this can help you; thanks for testing my patch.
After adding an IF test around the code that uses textIndent to avoid NPE, I 
then get the following error:

25-May-2004 09:11:43 org.apache.fop.layoutmgr.LineLayoutManager getNextBreakPoss
WARNING: No set of breaking points found with maxAdjustment = 1.0
Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:385)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
at org.apache.fop.layoutmgr.FlowLayoutManager.getNextBreakPoss(FlowLayou
tManager.java:81)
Thanks,
Chris

Re: Justification and line breaking

[Chris Bowditch]

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 patch is mature for committing to the trunk
code. See above. Luca, do you share my view?

Completely: I submitted the patch to get a first feedback, comments,
suggestions ...
I thank all that spent some time looking at it and testing it, and I
apologize if I have not been able to clearly explain what my aim was.
No need to apologize or thanks us, your efforts are most appreciated.
I'll work on this patch for some more time, and I'll let you know of the
progress.
Thank you, please let us know if you need any assistance or further feedback,
Chris

Re: Justification and line breaking

[Simon Pepping]

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 not specified 
> on the block.
> >  ...
> >  bTextAlignmentLast = blockProps.textAlignLast;
> >  textIndent = blockProps.firstIndent; /* here it is */
> >  hyphProps = propMgr.getHyphenationProps();
> >  ...

LineLayoutManager:
protected void initProperties(PropertyManager propMgr) {
BlockProps blockProps = propMgr.getBlockProps();
textIndent = blockProps.firstIndent;
}

blockProps is initialized in the constructor of LineLM.

PropertyManager:
public BlockProps getBlockProps() {
BlockProps props = new BlockProps();
props.firstIndent = this.propertyList.get(PR_TEXT_INDENT).getLength();
return props;
}

If this.propertyList is not null, then get(PR_TEXT_INDENT) always
returns a value; if it is not specified by the user, the default value
is returned. This is true for all properties.

LengthProperty:
public Length getLength() {
return this;
}

Property:
public Length getLength() {
return null;
}

getLength(), however, may return a null value. It only returns a
non-null value if the property returned by get(PR_TEXT_INDENT) is a
LengthProperty. This should be true; I do not know a reason why it is
not true in your code.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Justification and line breaking

[Simon Pepping]

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 and graphics can 
> not be children of the LLM.

I agree, all LMs for which generatesInlineAreas() returns true. That
is more or less the definition of LineLM, see its constructor. Note
that you also have to deal with descendants below children,
e.g. childLMs in an inlineLM. Other LMs may hide their content and
return a block to LineLM. For example, fo:inline-container (I guess
ICLayoutManager) may contain blocks, but hides them in a single block
from the LineLM (I am guessing a bit; have never dived so deep into
the details of these FOs; I compare them to TeX's vbox construct.)

I will see if I can get some more info on the possible descendants of
a LineLM.
 
> >I thank all that spent some time looking at it and testing it, and I
> >apologize if I have not been able to clearly explain what my aim was.
> 
> No need to apologize or thanks us, your efforts are most appreciated.

I agree.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Applying Large Patches (was Re: Justification and line breaking)

[Chris Bowditch]

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 of another file 
and errors with "File not found. Skip this file [n]: "

Has anyone else got any experience of working with such large and patches? Any 
advice on how to proceed would be appreciated.

Thanks,
Chris

Re: Applying Large Patches (was Re: Justification and line breaking)

[Jeremias Maerki]

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, you could sort out the rest manually.

Eclipse IMO has a very good patch facility. You'd probably get farther
that way.

On the other side, I've got no idea why the patch doesn't work 100%.
Luca seems to have used the latest sources when doing the patch.

On 21.05.2004 14:05:29 Chris Bowditch wrote:
> 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 of another file 
> and errors with "File not found. Skip this file [n]: "
> 
> Has anyone else got any experience of working with such large and patches? Any 
> advice on how to proceed would be appreciated.



Jeremias Maerki

Re: Applying Large Patches (was Re: Justification and line breaking)

[Chris Bowditch]

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
LineLayoutManager.java, too, you could sort out the rest manually.
Eclipse IMO has a very good patch facility. You'd probably get farther
that way.
On the other side, I've got no idea why the patch doesn't work 100%.
Luca seems to have used the latest sources when doing the patch.
Thanks for the quick reply Jeremias. 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?

Thanks,
Chris

Re: Applying Large Patches (was Re: Justification and line breaking)

[Luca Furini]

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 code I was working on was not the latest one, but I did not
modify files changed later (maybe the XMLrenderer, but it's a small change).

Luca