Re: [PATCH] Support for percentages and table-units

[Finn Bock]

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


   
   

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

cvs commit: xml-fop build.xml

[pbwest]

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

cvs commit: xml-fop lic_to_2

[pbwest]

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
  -  \\.
  +  Foundation,\ please\ see\ \\.
 \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
  -  \\.
  +  Foundation,\ please\ see\ \\.
 \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/src/codegen xml-lang.xml xml-lang.xsl

[pbwest]

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

Java thory and proctice: Garbase collection and performance

[John Austin]

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 build-notes NOTICE.txt

[pbwest]

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]

cvs commit: xml-fop lic_to_2

[pbwest]

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
 \\.
  -  \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/bin lic_to_2

[pbwest]

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
 \\.
  -  \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]

Re: [PATCH] Support for percentages and table-units

[Glen Mazza]

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

RE: [PATCH] Support for percentages and table-units

[Andreas L. Delmelle]

> 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

[Andreas L. Delmelle]

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

[Simon Pepping]

On Tue, Feb 17, 2004 at 04:52:10PM -0800, Glen Mazza wrote:
> --- Finn Bock <[EMAIL PROTECTED]> wrote:
> >
> > The layout dimension that is stored in the FO tree
> > is constantly updated 
> > during discovery of BreakPoss'es and is never
> > reused, not even when a 
> > block is split over a break where new values are
> > assigned.
> > 
> 
> I don't know enough to comment too much on which
> implementation would be better here, but the spec does
> not appear to have much problem (see [1], also Finn's
> earlier reference to the spec's conceptual procedure
> [2]) with back-and-forth processes, updates, etc.
> between the FO Tree and Area Tree.  Indeed, it seems
> to indicate that this kind of interaction does need to
> occur for the process to work correctly.

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

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

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