Re: Justification and line breaking
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
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
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
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
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
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
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
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
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
-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
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
--- 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
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
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
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)
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)
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)
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
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
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
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
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
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
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
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
