Re: [Bug 27773] - [PATCH] Hyphenation

2004-04-16 Thread Luca Furini
I think it would be better to report this item in a patch of its own. It really is a new issue. Ok, sorry. I'm going to do as you suggest. Luca

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

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

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

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

Re: InlineLMs

2004-06-03 Thread Luca Furini
Simon, thanks for all the information. At the moment, I am working on LeafNodeLM (now fo:leader works) and InlineStackingLM. I think I'll be able to post a second patch next week. Regards Luca

Re: [Bug 29124] - New line breaking algorithm

2004-08-12 Thread Luca Furini
Simon Pepping wrote: - word spacing and letter spacing are now fully implemented, they can both have MinOptMax values; but I am still thinking about how to differentiate a user-defined zero value from a default zero value ... You cannot. A default value is a user-defined value supplied

Re: DO NOT REPLY [Bug 29124] - New line breaking algorithm

2004-08-24 Thread Luca Furini
Simon Pepping wrote: Nested inline and other LMs: The output contains errors, see the comments in the text. The errors occur when hyphenation is set to true. Fixed: there were errors in the method addALetterSpaceTo of LeafNodeLM and InlineStackingLM. I also found a bug in the

Re: Handling of text-align=justify when nesting blocks

2004-09-03 Thread Luca Furini
Arnd Bei├čner wrote: In the example, line 2 is neither the last nor the only line of a block, and it's also not a line ending in U+000A, so it should be justified. Section 7.15.10 of the recommendation states that the property text-align-last Specifies the alignment of the last line-area child

Re: DO NOT REPLY [Bug29124] - New line breaking algorithm

2004-09-03 Thread Luca Furini
Simon Pepping wrote: You mention that you have not implemented the Knuth algorithm for ContentLM. Would it be difficult to do that? No, I have almost done. I think I will be able to attach a patch including this fix this afternoon. Regards Luca

Re: DO NOT REPLY [Bug 29124] - New line breaking algorithm

2004-09-13 Thread Luca Furini
Simon Pepping wrote: Still to be done: - Resolve the regressions mentioned above. As concerns leader with use content, patch created and successfully tested. The ContentLM calls getNextKnuthElements on his child InlineStackingLM, uses the returned elements to calculate the pattern width and

Re: DO NOT REPLY [Bug 31206] - [PATCH] Improvements over the new line breaking algorithm

2004-10-15 Thread Luca Furini
Simon Pepping wrote: 1. InlineStackingLM implements InlineLM. LineLM extends InlineStackingLM and thus implements InlineLM. IMHO it should not. Implementing InlineLM should be equivalent to generatesInlineAreas returning true. You are right, it's quite strange, but the LineLM still uses a

Re: [VOTE:RESULT] Luca Furini for Committer

2004-10-08 Thread Luca Furini
Jeremias Maerki wrote: Luca, is your CLA on its way? I sent it by fax a few minutes ago (sorry for the delay). Do I have to send it by mail too? Regards Luca

Re: commenting the Knuth code/centering issue

2004-11-04 Thread Luca Furini
Glen Mazza wrote: The title centers correctly in 0.20.5, but is left-justified in 1.0. [...] Luca, are you looking at this issue of text alignment in general? Yes, this happens when the text is short and the algorithm is not able to find a set of breaking points: the fallback method can't

Re: commenting the Knuth code/centering issue

2004-11-06 Thread Luca Furini
Jeremias Maerki wrote: No, I don't think Luca has write access, yet. I know by now that the CLA is recorded but the account hasn't been created, yet, although I've already sent a reminder. I have just received the e-mail confirming the creation of my account. I am now reading the

Re: commenting the Knuth code/centering issue

2004-11-06 Thread Luca Furini
Glen Mazza wrote: [BTW, I'm considering getting that Digital Typography book by Knuth you had mentioned earlier. Do you recommend it? (I was thinking that given all the time I spend on FOP I should start looking a little more at the scientific aspects of this work.)] I think it's very

Re: commenting the Knuth code/centering issue

2004-11-11 Thread Luca Furini
I have tried to add some comments to the Knuth[Element, Box, Glue, Penalty] classes. As I am not sure they are clear enough (I'm not even sure they are written in a proper English! :-) ) I'd like to hear your opinions before committing them. Regards, Luca Index: KnuthBox.java

Re: [Bug 32253] - Marker bugs

2004-11-19 Thread Luca Furini
Simon Pepping wrote: Indeed. Something like ICLM is needed, which creates an inline area containing the block areas. A block inside another block fo:blockNormal text fo:blockinner block/fo:block normal text./fo:block creates 3 different paragraphs: - Normal text - inner block - normal text.

Re: Knuth linebreaking questions

2004-11-30 Thread Luca Furini
Finn Bock wrote: 1) What is the purpose of 2 glues for a normal space in END and START alignment: new KnuthGlue(0, 3 * wordSpaceIPD.opt, 0, , false)); new KnuthPenalty(0, 0, false, , true)); new KnuthGlue(wordSpaceIPD.opt, - 3 * wordSpaceIPD.opt, 0, , true)); The purpose is to give each

Re: Good news: Jeremias has been elected as an ASF member!

2004-12-02 Thread Luca Furini
I have the great pleasure to announce that Jeremias Maerki has been elected as an ASF member at the last member's meeting during ApacheCon. Congratulations! Luca

Re: Knuth linebreaking questions

2004-12-02 Thread Luca Furini
Finn Bock wrote: (starting from the second question) And why not adjust the spacing within the user specified min/max for START and END alignment? Should the user desire adjusted spaces, wouldn't it be better for him to specify justified alignment? :-) Seriously, the recommendation (at 7.16.2

Re: Knuth linebreaking questions

2004-12-06 Thread Luca Furini
Finn Bock wrote: I tend to read that to mean that word spacing may be pushed beyond the specified range by justification. And I would think that unjustified alignment still has the option of using the word-spacing range but ofcourse has to stay within the range. I'm not convinced ... The

Re: More questions on line breaking

2004-12-06 Thread Luca Furini
Finn Bock wrote: Ok, so it isn't really needed when the algorithm is implemented in java. Just by having the previous node linked from within bestActiveNode is enough to keep the inactive nodes alive. So inactiveList can be removed. You are right, I'm going to remove it. Thanks! Regards,

Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgrKnuthElement.java KnuthBox.java KnuthGlue.java KnuthPenalty.java

2004-12-07 Thread Luca Furini
Glen Mazza wrote: Luca, I think we should be using getWidth() instead of getW(), correct? Yes, it would be much clearer! I'm going to rename: getW() - getWidth() getY() - getStretch() getZ() - getShrink() getP() - getPenaltyValue() The last name is quite long: I first thought of

Re: Refactoring of knuth line breaking code.

2004-12-13 Thread Luca Furini
Finn Bock wrote: I've been playing around with the knuth line breaking code and made a slight refactoring of it. [...] These improvements could also be applied to the existing code, so I think the more interesting point is the quality of the refactoring job. I think this is a very good

Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml

2005-02-02 Thread Luca Furini
Jeremias Maerki wrote: If someone has an idea about the ArrayOutOfBoundsException, all the better. I'm currently trying to debug that thing. It's because of this line in LineLM.addAreas(): iCurrParIndex = 0; If a block has properly handled preserved linefeeds, it will generate more than

Re: Page breaking [was: Markers added to the wrong page]

2005-02-08 Thread Luca Furini
Finn Bock wrote: I would pass the element on the immidiate parent, which recursively passes them on the top-level LM in the direction. For inline, the toplevel would be LineLM and for blocks it would be the PageLM. Ok, I misunderstood what you wrote, now I think we were saying the same thing

Error in computation of inline progression dimension ?

2005-02-15 Thread Luca Furini
I noticed a strange behaviour concerning margins that could be related to the inheritance of start-indend and end-indent, which was discussed a few weeks ago. It seems that in some situations the margins are subtracted twice from the available inline progression dimension. In the little fo file

Re: Error in computation of inline progression dimension ?

2005-02-16 Thread Luca Furini
Jeremias Maerki wrote: [Glen Mazza] So Luca is correct that both fo:simple-page-masters should generate the same overall margins of 50 pt. each, no? No. :-) Ok, now I am convinced you are right. Thanks for all your explanations, I always found this part of the recommendation quite obscure!

Re: [XML Graphics - FOP Wiki] Updated: PageLayout

2005-02-28 Thread Luca Furini
Simon Pepping wrote: +=== Space specifiers === + +When the space specifiers resolve to zero around a page break, we are +in the same situation as that of a word space in line breaking. It is +represented by the sequence `box - glue - box`. I add just a few thoughts about this subject. If there

Re: [XML Graphics - FOP Wiki] Updated: PageLayout

2005-03-04 Thread Luca Furini
Jeremias Maerki wrote: However, Luca's example does not fully resolve in my brain. The penalty, for example, must not be infinite or it will not be eligible for break possibility. A legal break is defined by Knuth as a number b such that either (i) xb is a penalty item with pb infinity, or

Re: Skype-conference on page-breaking?

2005-03-04 Thread Luca Furini
Jeremias Maerki wrote: Anyway, I'd like to ask if we could hold to a brainstorming conference call on page breaking either Sunday evening or next Monday or Tuesday somewhere between 8:00 and 24:00 CET. Of course, on my wish list there are Simon, Finn and Luca. I'm happy to call either of you on

Re: Skype-conference on page-breaking?

2005-03-08 Thread Luca Furini
Jeremias Maerki wrote: Luca, do you think your total-fit approach may be written in a way to handle changing available IPDs and that look-ahead can be disabled to improve processing speed at the cost of optimal break decisions? I think that a first fit algorithm could be implemented in two