Re: Justification and line breaking

2004-05-25 Thread Chris Bowditch
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 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?!?

snip/
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

2004-05-25 Thread 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

2004-05-25 Thread 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

2004-05-25 Thread Chris Bowditch
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 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

2004-05-25 Thread 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.

snip/
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

2004-05-25 Thread 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



Convenience branches. Was: Justification and line breaking

2004-05-25 Thread Peter B. West
Chris Bowditch wrote:
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 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.
Let's sketch a procedure for things like this.  Someone proposes such a 
large patch again.  We look at and realize that it can have a 
significant impact, but is worthwhile considering.  The time frame for 
sorting it out might be anything from a week to a month or two.

Tag the tree.  Let's call it paragraph_patch.  Tell the person proposing 
the patch - let's say Luca for illustration - to build his patch again 
based on the paragraph_patch.  Luca checks out the tree using that tag. 
 When he has it in a state to be examined, he submits the patch, noting 
that his work is based on paragraph_patch.  Those interested in testing 
the patch create a branch, say paragraph_test, at the tag-point, 
paragraph_patch, checkout paragraph_test, and apply the patch.  Is there 
any problem in applying the patch?  No, because everyone is working with 
known and common versions of the files.  Is there any impact on ongoing 
commits to HEAD?  No.  The committers (and Luca) still have valid HEAD 
trees on their machines, still track and contribute to the ongoing HEAD 
development.

Let's say that Andreas commits some changes which affect Luca's work. 
Luca wants to merge them in.  He asks for a merge.  Impact on HEAD?  Ask 
Andreas if his changes have settled down.  Announce that the tree will 
be tagged at time X.  Tag the tree; paragraph_merge_pt_1.  That's it.

Meanwhile, Luca requests that the paragraph_test tree be tagged 
(before_merge_pt_1).   Disruption to HEAD - none.  He locally merges 
from paragraph_merge_pt_1 into paragraph_test, and starts to sort out 
the conflicts.  When he is done, he prepares a new patch against 
paragraph_test, which he submits.

Committers who are tracking his work apply the patch to their copies of 
the paragraph_test tree.  Disruption to HEAD - none.  Patch errors - 
none.  When the patch is ready to be applied to HEAD, the process of 
merging in from HEAD is repeated, relative to the last merge tag in 
HEAD.  Committers announce that a merge into HEAD is pending, ask that 
commits to HEAD be suspended until this is done, and tag the HEAD tree; 
before_paragraph_merge.  Luca merges locally into HEAD, and prepares a 
patch against HEAD, which he submits.  This is committed and the HEAD 
tree tagged after_paragraph_merge.  The paragraph_test branch is now 
defunct.

Note that this description covers the whole development cycle of a 
major, potentially disruptive patch, through to integration into HEAD.

Compare that to the dramas we have just been through (and are still 
going through - there seem to be two versions of HEAD out there on two 
committers' machines.)  The responsibility for developing the patch 
rests primarily on the author and secondarily on the committers who 
perform testing and feedback.  Had a procedure like this been in place, 
would the progress of Luca's patch have been more, less or equally 
disruptive?

Obviously such a procedure is only *necessary* in unusual cases, but it 
makes sense to know how it is done, and it even makes sense to practise 
doing it on short cycle changes, so that things flow smoothly when the 
big issues come along.

Just a suggestion.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html


Re: Justification and line breaking

2004-05-25 Thread 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

2004-05-25 Thread 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



Re: Justification and line breaking

2004-05-24 Thread 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

2004-05-24 Thread 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

2004-05-24 Thread Andreas L. Delmelle
 -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 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

2004-05-24 Thread 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

2004-05-24 Thread 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

2004-05-24 Thread 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 http://www.powerup.com.au/~pbwest/resume.html


Re: Justification and line breaking

2004-05-24 Thread 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 http://www.powerup.com.au/~pbwest/resume.html


Re: Justification and line breaking

2004-05-21 Thread 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




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

2004-05-21 Thread 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)

2004-05-21 Thread 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)

2004-05-21 Thread 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: Justification and line breaking

2004-05-21 Thread 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

2004-05-20 Thread 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

2004-05-20 Thread 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


Justification and line breaking

2004-05-19 Thread Luca Furini

   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.

Regards
Luca

[1] D. E. Knuth and M. F. Plass, Breaking paragraphs into lines; I found
this essay in D. E. Knuth, Digital typography, published by CSLI
Publications





Re: Justification and line breaking

2004-05-19 Thread 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 http://www.powerup.com.au/~pbwest/resume.html


Re: Justification and line breaking

2004-05-19 Thread 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

2004-05-19 Thread 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