Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
Chris Bowditch wrote: Just want to add that I realise changing TextLM.addAreas isnt the only other change required to get jusitification working. The Renderers will need changing too, but I'm against the renderers computing their own splits, just give them each word as its own area if justification is on. This caused some problems in the maintenance branch code, although the mistakes made there can be avoided. The biggest problem is that lots of WordArea objects are created which hang around some time and which also inherit a *lot* of unnecessary (for them) fields from Area. I think some refactoring of the Area hierarchy could be in order. The current state in the maintenance branch is roughly like this: Box (not many attributes) + Space | + DisplaySpace | + InlineSpace (well, shoud be here, but actuall isn't) + Area (position, border, padding, children, heigth, width etc.) + BlockArea (content heigthwidth etc.) |+ LineArea |+ etc. | + InlineArea + WordArea (ugh, maybe this was TextArea instead) | + etc. + some non-word inline areas Many inline areas can't have border, padding, background and perhaps some other traits, and all the space is wasted in objects which are instantiated *very often*. This added up to significant ressource problems. I'm still not quite sure what's the best approach to fix this. In C++, it certainly would be multiple inheritance. In Java, we could try using interfaces and some delegation: interface Area interface BlockArea extends Area interface InlineArea extends Area interface BorderPaddingBackgroundArea extends Area interface NonBorderPaddingBackgroundArea extends Area interface Space extends Area class AbstractArea implements Area class AbstractBlockArea implements BlockArea extends AbstractArea class AbstractInlineArea implements InlineArea extends AbstractArea class LineArea implements NonBorderPaddingBackgroundArea extends AbstractBlockArea class WordArea implements NonBorderPaddingBackgroundArea extends AbstractInlineArea class PageNumberReferenceArea extends WordArea ... and so on ... (Well, because AbstractBlockArea is supposedly abstract, what class represents ordinary block areas? We need a good name here :-) Note that the real block area class may have traits which are not applicable to for example the line area class or the table row area class.) The code for accessing the border, padding and background traits will be duplicated in all classes implementing the BPBA interface, but given that the traits are combined in a single class, this shouln't be much of a problem, should it? Some inline areas may not have children, this could lead another set of interfaces. A potentially second problem are the space non-areas. In the maintenance branch code, display (block) space and inline space just have a height (bpd) or a width (ipd), respectively. I'm not sure whether this is sufficient, but perhaps it is. Regards J.Pietschmann
Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
Simon Pepping wrote: I believe the reason why justification still doesnt work after correcting the issues you've found is because TextLM.addAreas doesnt create separate areas for each word - it creates one big area in some cases for whole line, so there is no opportunity to add space adjust for justification. The layout managers only do the calculations. The renderers need to do the real work, i.e. apply the calculation to the line to be rendered. The LM can help by splitting up the line in a number of text areas, or the renderer can scan the unsplit text areas and apply stretching to the white space in it. There was a discussion about this topic on this list some time ago. Yes, I was the one who started the previous discussion. Joerg was pushing for the Renderers to do the splitting too. But I disagree with this approach because the LMs have already worked out the BPs, why make the Renderers do it again. This is very inefficient approach dont you think? I believe changing the TextLM.addAreas to generate an area for each BP if justification is on is the most efficient way of implementing justification. Chris
Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
Chris Bowditch wrote: Simon Pepping wrote: I believe the reason why justification still doesnt work after correcting the issues you've found is because TextLM.addAreas doesnt create separate areas for each word - it creates one big area in some cases for whole line, so there is no opportunity to add space adjust for justification. The layout managers only do the calculations. The renderers need to do the real work, i.e. apply the calculation to the line to be rendered. The LM can help by splitting up the line in a number of text areas, or the renderer can scan the unsplit text areas and apply stretching to the white space in it. There was a discussion about this topic on this list some time ago. Yes, I was the one who started the previous discussion. Joerg was pushing for the Renderers to do the splitting too. But I disagree with this approach because the LMs have already worked out the BPs, why make the Renderers do it again. This is very inefficient approach dont you think? I believe changing the TextLM.addAreas to generate an area for each BP if justification is on is the most efficient way of implementing justification. Just want to add that I realise changing TextLM.addAreas isnt the only other change required to get jusitification working. The Renderers will need changing too, but I'm against the renderers computing their own splits, just give them each word as its own area if justification is on. Chris
DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28130 Errors in the calculation of adjustment factors --- Additional Comments From [EMAIL PROTECTED] 2004-04-02 09:58 --- Excellent work. Text justification is one of FOP development priorities. Priorities for layout work are defined here: http://xml.apache.org/fop/design/layout.html#status-todo I went through a similar thought process to you when I analysed the code in Text and Line LMs. I'm taking a closer look at your patch now. I believe the reason why justification still doesnt work after correcting the issues you've found is because TextLM.addAreas doesnt create separate areas for each word - it creates one big area in some cases for whole line, so there is no opportunity to add space adjust for justification. Your patch looks like it is the first piece of the puzzle to get Justification working
Re: DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
On Fri, Apr 02, 2004 at 09:58:43AM -, [EMAIL PROTECTED] wrote: I went through a similar thought process to you when I analysed the code in Text and Line LMs. I'm taking a closer look at your patch now. I believe the reason why justification still doesnt work after correcting the issues you've found is because TextLM.addAreas doesnt create separate areas for each word - it creates one big area in some cases for whole line, so there is no opportunity to add space adjust for justification. The layout managers only do the calculations. The renderers need to do the real work, i.e. apply the calculation to the line to be rendered. The LM can help by splitting up the line in a number of text areas, or the renderer can scan the unsplit text areas and apply stretching to the white space in it. There was a discussion about this topic on this list some time ago. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28130 Errors in the calculation of adjustment factors --- Additional Comments From [EMAIL PROTECTED] 2004-04-01 15:57 --- Created an attachment (id=11083) only a block of justified text to see the calculated adjustments
DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28130 Errors in the calculation of adjustment factors --- Additional Comments From [EMAIL PROTECTED] 2004-04-01 15:58 --- Created an attachment (id=11084) a few println in the old code to show the calculated adjustments
DO NOT REPLY [Bug 28130] - Errors in the calculation of adjustment factors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28130. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28130 Errors in the calculation of adjustment factors --- Additional Comments From [EMAIL PROTECTED] 2004-04-01 15:59 --- Created an attachment (id=11085) proposed changes to the formulas and some println
