Re: obsolete code in PSLM
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Glen, > > over all, your proposed changes are ok (the two > earlier posts, but see > comment for this one further down). But first, I > want to make sure you > remember that branch plan [1] I published earlier. > It says that until > 2005-04-20 the branch is somewhat experimental and > might yet fail. You > seem to have big confidence that it'll work out. > After my findings > during the last two weeks I must say that I'm not > 100% confident anymore > even though I can now see the light at the other end > of the tunnel. > Table layout is very critical here. So if I were you > I'd wait a little > until I did that. > Will do. > The layout dimension mechanism is used for resolving > percentage based > property values. Remember [2]? This mechanism > shouldn't simply be > removed but replaced by something like I outlined in > that post. I can look at this--I think you want BPD() and IPD() to be better set, so we can reduce our dependence on the layout dimension mechanism. Also, in the interim we can also look at setting the correct values with this mechanism as you also mentioned. [BTW, we have flowBPD and flowIPD instance variables in PSLM that I would love to get rid of in favor of reading the precise .getIPD() and .getBPD() value from the Area object in question. Obtaining directly from the Area object would create much more readable and less error-prone code. Problem is, right now, AFAICT the meaning of flowBPD and flowIPD keeps changing in PSLM--I'm not sure which Area object it is referring to--span/BodyRegion/NormalFlow, etc., etc. If anyone can shed light on this, it would be most appreciated.] Thanks, Glen > [2] > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200501.mbox/[EMAIL PROTECTED] >
Re: obsolete code in PSLM
Glen, over all, your proposed changes are ok (the two earlier posts, but see comment for this one further down). But first, I want to make sure you remember that branch plan [1] I published earlier. It says that until 2005-04-20 the branch is somewhat experimental and might yet fail. You seem to have big confidence that it'll work out. After my findings during the last two weeks I must say that I'm not 100% confident anymore even though I can now see the light at the other end of the tunnel. Table layout is very critical here. So if I were you I'd wait a little until I did that. The layout dimension mechanism is used for resolving percentage based property values. Remember [2]? This mechanism shouldn't simply be removed but replaced by something like I outlined in that post. ATM I'm simply ignoring this part in the page breaking rewrite because it's a detail that can be sorted out later. But these calls to setLayoutDimension() remind me about the necessity to revisit this later. Why don't you take a shot at that? That would be real cool. Check out LengthBase and PercentBase in [3]. [1] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200503.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200501.mbox/[EMAIL PROTECTED] [3] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/datatypes/ On 05.04.2005 04:41:51 Glen Mazza wrote: > Jeremias, > > There's a few "setLayoutDimension()" calls in PSLM > that AFAICT is old code that isn't doing anything for > us. (I've searched the source code for > "getLayoutDimension()" calls in which these parameters > are being accessed--found nothing.) I would like very > much to get rid of them--do you see any problem if I > do so? The two sets are lines 257-258 and 413-417 of > [1]. > > Thanks, > Glen > > [1] > http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java?annotate=1.50.2.12 Jeremias Maerki
