Re: [PATCH] Support for percentages and table-units
On Tue, Feb 17, 2004 at 09:31:52PM +0100, Finn Bock wrote: [J.Pietschmann] The layout context has the actual IPD MinOptMax. There is no inherent reason it should have a link to a parent context or the property subsystem, it's only necessary to have a method to resolve a property expression given a set of MinOptMax for the various traits which can be used as references for percentages. Like textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext); Right, but it doesn't have all the base lengths. For some base lengths it is one of the parent layout contexts that has the trait, like ipd of the containing reference area. How could we get hold of that trait if the LayoutContexts isn't linked together? Whatever object that is passed to the resolve() method must also AFAICT also have a reference to the FO so that the resolve() can find the right LayoutContext in the LayoutContext tree to use as base. Perhaps I'm missing something fundamental in your suggestion, but I just can see how there is enough information in a single LayoutContext to resolve relative lengths that is inherited from a parent fo:element. In the LayoutContext design, one does not climb a tree to find the relevant information; instead, the information is propagated downward for ready reference. Each getNextBreakPoss call gets a LayoutContext from its caller, and constructs one for its own calls to getNextBreakPoss. It should make sure that the latter LayoutContext contains all the relevant information, such as the width of the containing block and of the containing reference area. Either it copies it from the LayoutContext it received from its caller, or it inserts new values, as appropriate. In principle it should contain the dimensions that correspond to the percent based length types listed in LengthBase. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
RE: [PATCH] Support for percentages and table-units
-Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] In my view FOP consists of a number of subsystems that are ordered from upstream to downstream. The FO tree is the most upstream system, the area tree (or objects that are constructed by a renderer) is the most downstream system. Indeed, but... Information should flow downstream, not upstream. (Hmm. Isn't there an Aussie in this house who disagrees? Callbacks, Peter? ;) Nah, bad example...) I gave the example of resolving a percentage p of an indefinite page-height or -width... Say you have to do this for a page that turns out to be .. quite long (--say, an ancient scroll or something.. ). For this you'd need the total width of every object laid out on the page (nothing rendered yet), then a very simple: reswidth = totwidth * (1 + p/100 ) / ( 1 - p/100 ) Don't know about you, but even *with* the possibility of the next renderer not using the same configuration as the first, I wouldn't want to just throw away a possibility of re-using the layout info and only having to reuse the calculated values (--or, in the worst case, maybe results from a calculation based upon higher-level relationships between the different configurations used) Basic point: the preferred direction of the information flow depends (almost entirely) upon the relationship between the up- and downstream events that is being You are IMO very correct by stating that 'if the Layout info can be reused, so can the AT and the renderer', however, if I interpret correctly, the latter two are designed to dispose of their created objects ASAP. The downstream objects hold a reference to the upstream ones, not the other way around --unless you have a way out of there, as long as a certain page-sequence is referenced, the entire Layout/AT/Renderer structure would exist in memory, which can get .. quite large even for moderately sized documents. Would it really be worth a shot to change the design there, and flip a switch? Throw the FOTree away and just fill up the AT and re-use that? Cheers, Andreas
RE: [PATCH] Support for percentages and table-units
snip / is being interrogated/perceived/discussed... Sorry, it's late here... You are IMO very correct by stating that 'if the Layout info can be reused, so can the AT and the renderer', however, if I interpret correctly, the latter two are designed to dispose of their created objects ASAP. The downstream objects hold a reference to the upstream ones, not the other way around --unless you have a way out of there, as long as a certain page-sequence is referenced, the entire Layout/AT/Renderer structure would exist in memory, which can get .. quite large even for moderately sized documents. Would it really be worth a shot to change the design there, and flip a switch? Throw the FOTree away and just fill up the AT and re-use that? Cheers, Andreas
Re: [PATCH] Support for percentages and table-units
--- Simon Pepping [EMAIL PROTECTED] wrote: In my view FOP consists of a number of subsystems that are ordered from upstream to downstream. The FO tree is the most upstream system, the area tree (or objects that are constructed by a renderer) is the most downstream system. Information should flow downstream, not upstream. Regards, Simon Pepping In general, yes, but not as 100%. We had this debate for months, with Victor holding fast to your view on the issue. We've done more spec research since then (I encourage you to read the parts of the spec I indicated in my posting) which support the view of Alt-Design (and probably still HEAD), that FOT AT interact with each other and can't be separated, and for performance reasons, shouldn't be either. Glen
cvs commit: xml-fop/bin lic_to_2
pbwest 2004/02/18 17:48:41 Modified:bin Tag: FOP_0-20-0_Alt-Design lic_to_2 Log: Tidied up the start and end conditions for the changes. Revision ChangesPath No revision No revision 1.1.2.2 +2 -3 xml-fop/bin/Attic/lic_to_2 Index: lic_to_2 === RCS file: /home/cvs/xml-fop/bin/Attic/lic_to_2,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- lic_to_2 29 Jan 2004 22:40:13 - 1.1.2.1 +++ lic_to_2 19 Feb 2004 01:48:41 - 1.1.2.2 @@ -23,8 +23,7 @@ # Slurp the input file $_ = ; -s|\n# Start with a newline - [^\n]*=+\s+ # Non-newlines followed by multiple '=' +s|[^\n]*=+\s+ # Non-newlines followed by multiple '=' # ...followed by whitespace (incl. newline) [^\n]*# Non-newlines (incl spaces) The\ Apache\ Software\ License,\ Version\ 1\.1 @@ -34,7 +33,7 @@ James\ Tauber .*# Anything \http://www.apache.org/\\. - \s+ # Any whitespace + \s*\n # Any whitespace ending in a newline |$lic2begin$1$lic2rem|xs; print; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop lic_to_2
pbwest 2004/02/18 17:49:30 Modified:.Tag: FOP_0-20-0_Alt-Design lic_to_2 Log: Tidied up the start and end conditions for the changes. Revision ChangesPath No revision No revision 1.1.2.2 +2 -3 xml-fop/Attic/lic_to_2 Index: lic_to_2 === RCS file: /home/cvs/xml-fop/Attic/lic_to_2,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- lic_to_2 29 Jan 2004 05:23:28 - 1.1.2.1 +++ lic_to_2 19 Feb 2004 01:49:30 - 1.1.2.2 @@ -23,8 +23,7 @@ # Slurp the input file $_ = ; -s|\n# Start with a newline - [^\n]*=+\s+ # Non-newlines followed by multiple '=' +s|[^\n]*=+\s+ # Non-newlines followed by multiple '=' # ...followed by whitespace (incl. newline) [^\n]*# Non-newlines (incl spaces) The\ Apache\ Software\ License,\ Version\ 1\.1 @@ -34,7 +33,7 @@ James\ Tauber .*# Anything \http://www.apache.org/\\. - \s+ # Any whitespace + \s*\n # Any whitespace ending in a newline |$lic2begin$1$lic2rem|xs; print; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop build-notes NOTICE.txt
pbwest 2004/02/18 18:17:11 Removed: .Tag: FOP_0-20-0_Alt-Design build-notes NOTICE.txt Log: Not required - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Java thory and proctice: Garbase collection and performance
I noticed this artcle on Developer Works: Java theory and practice: Garbage collection and performance http://www-106.ibm.com/developerworks/library/j-jtp01274.html Something to read on Thursday. -- John Austin [EMAIL PROTECTED]
cvs commit: xml-fop/src/codegen xml-lang.xml xml-lang.xsl
pbwest 2004/02/18 19:57:52 Modified:src/codegen Tag: FOP_0-20-0_Alt-Design xml-lang.xml xml-lang.xsl Log: Updated Licence to 2.0 Revision ChangesPath No revision No revision 1.1.2.3 +13 -47xml-fop/src/codegen/Attic/xml-lang.xml Index: xml-lang.xml === RCS file: /home/cvs/xml-fop/src/codegen/Attic/xml-lang.xml,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- xml-lang.xml 8 Jul 2003 11:47:47 - 1.1.2.2 +++ xml-lang.xml 19 Feb 2004 03:57:51 - 1.1.2.3 @@ -1,54 +1,20 @@ ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE xml-lang !-- - -The Apache Software License, Version 1.1 - - - Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. - - Redistribution and use in source and binary forms, with or without modifica- - tion, are permitted provided that the following conditions are met: - - 1. Redistributions of source code must retain the above copyright notice, -this list of conditions and the following disclaimer. - - 2. Redistributions in binary form must reproduce the above copyright notice, -this list of conditions and the following disclaimer in the documentation -and/or other materials provided with the distribution. - - 3. The end-user documentation included with the redistribution, if any, must -include the following acknowledgment: This product includes software -developed by the Apache Software Foundation (http://www.apache.org/). -Alternately, this acknowledgment may appear in the software itself, if -and wherever such third-party acknowledgments normally appear. - - 4. The names FOP and Apache Software Foundation must not be used to -endorse or promote products derived from this software without prior -written permission. For written permission, please contact -[EMAIL PROTECTED] - - 5. Products derived from this software may not be called Apache, nor may -Apache appear in their name, without prior written permission of the -Apache Software Foundation. - - THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - - This software consists of voluntary contributions made by many individuals - on behalf of the Apache Software Foundation and was originally created by - James Tauber [EMAIL PROTECTED]. For more information on the Apache - Software Foundation, please see http://www.apache.org/. + Copyright 1999-2003 The Apache Software Foundation. + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. -- xml-lang countrycodes 1.1.2.5 +16 -49xml-fop/src/codegen/Attic/xml-lang.xsl Index: xml-lang.xsl === RCS file: /home/cvs/xml-fop/src/codegen/Attic/xml-lang.xsl,v retrieving revision 1.1.2.4 retrieving revision 1.1.2.5 diff -u -r1.1.2.4 -r1.1.2.5 --- xml-lang.xsl 5 Jan 2004 02:34:22 - 1.1.2.4 +++ xml-lang.xsl 19 Feb 2004 03:57:51 - 1.1.2.5 @@ -4,53 +4,20 @@ !-- $Id$ -- xsl:variable name=licence![CDATA[/* * $Id]]![CDATA[$ - * - *The Apache Software License, Version 1.1 - *
cvs commit: xml-fop lic_to_2
pbwest 2004/02/18 19:59:10 Modified:bin Tag: FOP_0-20-0_Alt-Design lic_to_2 .Tag: FOP_0-20-0_Alt-Design lic_to_2 Log: Fix the backtrack churning on long files Revision ChangesPath No revision No revision 1.1.2.3 +2 -4 xml-fop/bin/Attic/lic_to_2 Index: lic_to_2 === RCS file: /home/cvs/xml-fop/bin/Attic/lic_to_2,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- lic_to_2 19 Feb 2004 01:48:41 - 1.1.2.2 +++ lic_to_2 19 Feb 2004 03:59:10 - 1.1.2.3 @@ -27,12 +27,10 @@ # ...followed by whitespace (incl. newline) [^\n]*# Non-newlines (incl spaces) The\ Apache\ Software\ License,\ Version\ 1\.1 - .*# Anything + [^C]* # Anything not a capital C Copyright\ \(C\)\ (\d+(-\d+)?)\ The\ Apache\ Software\ Foundation .*# Anything - James\ Tauber - .*# Anything - \http://www.apache.org/\\. + Foundation,\ please\ see\ \http://www.apache.org/\\. \s*\n # Any whitespace ending in a newline |$lic2begin$1$lic2rem|xs; No revision No revision 1.1.2.3 +2 -4 xml-fop/Attic/lic_to_2 Index: lic_to_2 === RCS file: /home/cvs/xml-fop/Attic/lic_to_2,v retrieving revision 1.1.2.2 retrieving revision 1.1.2.3 diff -u -r1.1.2.2 -r1.1.2.3 --- lic_to_2 19 Feb 2004 01:49:30 - 1.1.2.2 +++ lic_to_2 19 Feb 2004 03:59:10 - 1.1.2.3 @@ -27,12 +27,10 @@ # ...followed by whitespace (incl. newline) [^\n]*# Non-newlines (incl spaces) The\ Apache\ Software\ License,\ Version\ 1\.1 - .*# Anything + [^C]* # Anything not a capital C Copyright\ \(C\)\ (\d+(-\d+)?)\ The\ Apache\ Software\ Foundation .*# Anything - James\ Tauber - .*# Anything - \http://www.apache.org/\\. + Foundation,\ please\ see\ \http://www.apache.org/\\. \s*\n # Any whitespace ending in a newline |$lic2begin$1$lic2rem|xs; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop build.xml
pbwest 2004/02/18 20:00:13 Modified:.Tag: FOP_0-20-0_Alt-Design build.xml Log: Updated Licence to 2.0 Revision ChangesPath No revision No revision 1.37.2.11 +13 -48xml-fop/build.xml Index: build.xml === RCS file: /home/cvs/xml-fop/build.xml,v retrieving revision 1.37.2.10 retrieving revision 1.37.2.11 diff -u -r1.37.2.10 -r1.37.2.11 --- build.xml 30 Jan 2004 05:56:32 - 1.37.2.10 +++ build.xml 19 Feb 2004 04:00:12 - 1.37.2.11 @@ -1,54 +1,19 @@ ?xml version=1.0? -!-- === - -The Apache Software License, Version 1.1 - - - Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. - - Redistribution and use in source and binary forms, with or without modifica- - tion, are permitted provided that the following conditions are met: - - 1. Redistributions of source code must retain the above copyright notice, -this list of conditions and the following disclaimer. - - 2. Redistributions in binary form must reproduce the above copyright notice, -this list of conditions and the following disclaimer in the documentation -and/or other materials provided with the distribution. - - 3. The end-user documentation included with the redistribution, if any, must -include the following acknowledgment: This product includes software -developed by the Apache Software Foundation (http://www.apache.org/). -Alternately, this acknowledgment may appear in the software itself, if -and wherever such third-party acknowledgments normally appear. - - 4. The names FOP and Apache Software Foundation must not be used to -endorse or promote products derived from this software without prior -written permission. For written permission, please contact -[EMAIL PROTECTED] - - 5. Products derived from this software may not be called Apache, nor may -Apache appear in their name, without prior written permission of the -Apache Software Foundation. - - THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - - This software consists of voluntary contributions made by many individuals - on behalf of the Apache Software Foundation and was originally created by - James Tauber [EMAIL PROTECTED]. For more information on the Apache - Software Foundation, please see http://www.apache.org/. +!-- + Copyright 1999-2003 The Apache Software Foundation. + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. * == * | FOP build system | * == * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Support for percentages and table-units
[J.Pietschmann] The layout context has the actual IPD MinOptMax. There is no inherent reason it should have a link to a parent context or the property subsystem, it's only necessary to have a method to resolve a property expression given a set of MinOptMax for the various traits which can be used as references for percentages. Like textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext); Right, but it doesn't have all the base lengths. For some base lengths it is one of the parent layout contexts that has the trait, like ipd of the containing reference area. How could we get hold of that trait if the LayoutContexts isn't linked together? Whatever object that is passed to the resolve() method must also AFAICT also have a reference to the FO so that the resolve() can find the right LayoutContext in the LayoutContext tree to use as base. Perhaps I'm missing something fundamental in your suggestion, but I just can see how there is enough information in a single LayoutContext to resolve relative lengths that is inherited from a parent fo:element. [Simon Pepping] In the LayoutContext design, one does not climb a tree to find the relevant information; instead, the information is propagated downward for ready reference. Each getNextBreakPoss call gets a LayoutContext from its caller, and constructs one for its own calls to getNextBreakPoss. It should make sure that the latter LayoutContext contains all the relevant information, such as the width of the containing block and of the containing reference area. Either it copies it from the LayoutContext it received from its caller, or it inserts new values, as appropriate. In principle it should contain the dimensions that correspond to the percent based length types listed in LengthBase. If an expression reference another expression in a parent fo, the parent fo expression must be evaluated against the LayoutContext that was in effect for the parent fo and *not* against the child fo LayoutContext. fo:block id=a border-start-width=10% fo:block id=b border-start-width=inherit /fo:block /fo:block It must be the LayoutContex for 'a' that is used when we evaluate the 10% even when we call: propertyList.get(PR_BORDER_START_WIDTH).getValue(lc) with the layout context for 'b'. I don't really care how that is done, but I would link the LayoutContexts to their parent. Or rather, I would use the LM as the objects for storing the actual dimension since they are already linked together with their parent. But for now I think we should just use the FO tree and later change the signature of getValue() to take some kind of context parameter when a real need arise. regards, finn
