You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Karen Lease <kl...@club-internet.fr> on 2001/07/25 23:18:50 UTC
Inheritance for fo:marker
Hi again Arved,
What may make this fairly easy is the fact that the PropertyList object
has its own parent reference, to its parent PropertyList. This is set in
the constructor for the PropertyList. Except when changing namespaces,
it's set to the property list of the FO parent object. Property
retrieval is dynamic and will climb the inheritance tree based on the
parentProperty value. Unlike the FO tree, the parent PropertyList
doesn't reference its children; there are only upwards pointers. So I
think if we just add a method to "reparent" the property list that might
do the trick.
Things to watch out for:
use of methods like "from-parent()" in the property values, since these
are currently interpreted during PropertyList construction and not
during layout. Of course we might just say it's common sense not to use
those... at least for now.
The other thing we'd have to do is flush the PropertyManager cache for
things like font-state. The PropertyList itself (or rather the Property
objects it holds) don't generally cache the results of requests (for
example, storing an inherited value directly), but the PropertyManager
does. Also the use of percentage values in properties causes them to be
interpreted during layout, and those "resolved" values are then stored
in the actual Property objects.
That's about where I'm at right now. I'm going on vacation so I probably
won't be as active for the next few weeks, though I will probably
continue to mull over various things. On the other hand, tomorrow I have
a lot of travel time, so maybe I'll be able to poke at this Property
stuff and give you actual code instead of just advice!
Best regards,
Karen
Arved Sandstrom wrote:
>
> If you run some examples, you'll see that where fo:marker/fo:retrieve-marker
> currently is incorrect is that the properties on fo:marker are inherited from
> the original parent, not from the parent in the fo:static-content once the
> marker has been retrieved. In effect, markers are re-useable (I already have
> to reset them before each layout), and they have to be able to dynamically
> re-parent, sort of having a static parent for the purposes of retrieval, and
> a dynamic or _effective_ parent for the purposes of layout.
>
> It is easy enough to figure out what the effective parent for layout is; my
> question is, since you are the properties guru, what is the most effective
> mechanism for re-initiating inheritance using this effective parent? This
> would have to be done every time a marker is used. I could work it out
> eventually, but I'm lazy. :-)
>
> Thanks. Arved.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Inheritance for fo:marker
Posted by "Peter B. West" <pb...@powerup.com.au>.
Arved Sandstrom wrote:
> At 01:46 AM 7/28/01 +1000, Peter B. West wrote:
>
>>Arved & Karen,
>>
>>On the surface of it, this re-parenting issue looks like a tree
>>operation. The point of definition of the marker remains in its context
>>at the point of definition. When a retrieve-marker is found, the marker
>>sub-tree is attached as a child of the retrieve-marker. As long as
>>there is a check for cycles, there s no reason that a sub-tree cannot be
>>attached at multiple points in the tree. There are probably a few
>>complications in terms of removal, but I have yet to work through all of
>>these issues anyway.
>>
>
> In fact, you're right, this would be much better. Rather than change the
> parent of the original, just create a temporary copy that gets
attached as a
> child of the fo:retrieve-marker. Because the original should stay
where it
> is for future marker operations. In any case the code does not permit
the
> original to be laid-out, so there is no problem leaving the fo:marker
there.
It shouldn't even have to be a temporary copy. Because "[t]he
fo:retrieve-marker does not directly generate any area. It is
(conceptually) replaced by the children of the fo:marker that it
retrieves" and because fo:retrieve-marker may have no other children,
the appropriate fo:marker subtree can be added as a child of
fo:retrieve-marker and left there. Formatting of fo:retrieve-marker
could then proceed as for any other subtree. Well, it sounds good in
theory.
Peter
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Validation
Posted by "Peter B. West" <pb...@powerup.com.au>.
I noticed some comments on validation a few days ago. To DTD or not to
DTD and the like, including Karen's comment that she wanted to move a
lot of the "semantic" validation into addChild.
I had been wondering why we weren't using a DTD to provide the first
level of syntatic validation in the parser. When I was thinking about
the streaming of large documents, I felt that streaming tends to promote
the parsing to the top of the processing hierachy. I made some comments
along these lines a few days ago.
It seems to me that, if the syntactic validation is to come into the
code, it makes some sense to use the structure that is imposed by the
syntactic structure of the XML to in turn structure not just the
parsing, but, as much as possible, the processing. I found, and this
may be the newcomer effect, that in order to find my way around in the
code, I needed to read the spec. That told me what to look for next. I
would, rather, like to be able to read the code instead of reading the
spec. I exaggerate, but do you see my point?
Looking back over this, I see that it is largely a rehash of what I said
before, so I'll leave it at that.
Peter
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Inheritance for fo:marker
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 01:46 AM 7/28/01 +1000, Peter B. West wrote:
>Arved & Karen,
>
>On the surface of it, this re-parenting issue looks like a tree
>operation. The point of definition of the marker remains in its context
>at the point of definition. When a retrieve-marker is found, the marker
>sub-tree is attached as a child of the retrieve-marker. As long as
>there is a check for cycles, there s no reason that a sub-tree cannot be
>attached at multiple points in the tree. There are probably a few
>complications in terms of removal, but I have yet to work through all of
>these issues anyway.
In fact, you're right, this would be much better. Rather than change the
parent of the original, just create a temporary copy that gets attached as a
child of the fo:retrieve-marker. Because the original should stay where it
is for future marker operations. In any case the code does not permit the
original to be laid-out, so there is no problem leaving the fo:marker there.
Regards,
Arved
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Inheritance for fo:marker
Posted by "Peter B. West" <pb...@powerup.com.au>.
Arved & Karen,
On the surface of it, this re-parenting issue looks like a tree
operation. The point of definition of the marker remains in its context
at the point of definition. When a retrieve-marker is found, the marker
sub-tree is attached as a child of the retrieve-marker. As long as
there is a check for cycles, there s no reason that a sub-tree cannot be
attached at multiple points in the tree. There are probably a few
complications in terms of removal, but I have yet to work through all of
these issues anyway.
Peter
Arved Sandstrom wrote:
> Hi, Karen
>
> OK, if you're going on vacation please don't spend too much time on this. :-)
> Apart from maybe during travel. I can take a look at what is going on too,
> based on your pointers so far. You make it sound fairly simple.
>
> Regards,
> Arved
>
> On Wednesday 25 July 2001 21:18, Karen Lease wrote:
>
>>Hi again Arved,
>>
>>What may make this fairly easy is the fact that the PropertyList object
>>has its own parent reference, to its parent PropertyList. This is set in
>>the constructor for the PropertyList. Except when changing namespaces,
>>it's set to the property list of the FO parent object. Property
>>retrieval is dynamic and will climb the inheritance tree based on the
>>parentProperty value. Unlike the FO tree, the parent PropertyList
>>doesn't reference its children; there are only upwards pointers. So I
>>think if we just add a method to "reparent" the property list that might
>>do the trick.
>>
>>Things to watch out for:
>>use of methods like "from-parent()" in the property values, since these
>>are currently interpreted during PropertyList construction and not
>>during layout. Of course we might just say it's common sense not to use
>>those... at least for now.
>>
>>The other thing we'd have to do is flush the PropertyManager cache for
>>things like font-state. The PropertyList itself (or rather the Property
>>objects it holds) don't generally cache the results of requests (for
>>example, storing an inherited value directly), but the PropertyManager
>>does. Also the use of percentage values in properties causes them to be
>>interpreted during layout, and those "resolved" values are then stored
>>in the actual Property objects.
>>
>>That's about where I'm at right now. I'm going on vacation so I probably
>>won't be as active for the next few weeks, though I will probably
>>continue to mull over various things. On the other hand, tomorrow I have
>>a lot of travel time, so maybe I'll be able to poke at this Property
>>stuff and give you actual code instead of just advice!
>>
>>Best regards,
>>Karen
>>
>>Arved Sandstrom wrote:
>>
>>>If you run some examples, you'll see that where
>>>fo:marker/fo:retrieve-marker currently is incorrect is that the
>>>properties on fo:marker are inherited from the original parent, not from
>>>the parent in the fo:static-content once the marker has been retrieved.
>>>In effect, markers are re-useable (I already have to reset them before
>>>each layout), and they have to be able to dynamically re-parent, sort of
>>>having a static parent for the purposes of retrieval, and a dynamic or
>>>_effective_ parent for the purposes of layout.
>>>
>>>It is easy enough to figure out what the effective parent for layout is;
>>>my question is, since you are the properties guru, what is the most
>>>effective mechanism for re-initiating inheritance using this effective
>>>parent? This would have to be done every time a marker is used. I could
>>>work it out eventually, but I'm lazy. :-)
>>>
>>>Thanks. Arved.
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>>For additional commands, email: fop-dev-help@xml.apache.org
>>
>
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Inheritance for fo:marker
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Hi, Karen
OK, if you're going on vacation please don't spend too much time on this. :-)
Apart from maybe during travel. I can take a look at what is going on too,
based on your pointers so far. You make it sound fairly simple.
Regards,
Arved
On Wednesday 25 July 2001 21:18, Karen Lease wrote:
> Hi again Arved,
>
> What may make this fairly easy is the fact that the PropertyList object
> has its own parent reference, to its parent PropertyList. This is set in
> the constructor for the PropertyList. Except when changing namespaces,
> it's set to the property list of the FO parent object. Property
> retrieval is dynamic and will climb the inheritance tree based on the
> parentProperty value. Unlike the FO tree, the parent PropertyList
> doesn't reference its children; there are only upwards pointers. So I
> think if we just add a method to "reparent" the property list that might
> do the trick.
>
> Things to watch out for:
> use of methods like "from-parent()" in the property values, since these
> are currently interpreted during PropertyList construction and not
> during layout. Of course we might just say it's common sense not to use
> those... at least for now.
>
> The other thing we'd have to do is flush the PropertyManager cache for
> things like font-state. The PropertyList itself (or rather the Property
> objects it holds) don't generally cache the results of requests (for
> example, storing an inherited value directly), but the PropertyManager
> does. Also the use of percentage values in properties causes them to be
> interpreted during layout, and those "resolved" values are then stored
> in the actual Property objects.
>
> That's about where I'm at right now. I'm going on vacation so I probably
> won't be as active for the next few weeks, though I will probably
> continue to mull over various things. On the other hand, tomorrow I have
> a lot of travel time, so maybe I'll be able to poke at this Property
> stuff and give you actual code instead of just advice!
>
> Best regards,
> Karen
>
> Arved Sandstrom wrote:
> > If you run some examples, you'll see that where
> > fo:marker/fo:retrieve-marker currently is incorrect is that the
> > properties on fo:marker are inherited from the original parent, not from
> > the parent in the fo:static-content once the marker has been retrieved.
> > In effect, markers are re-useable (I already have to reset them before
> > each layout), and they have to be able to dynamically re-parent, sort of
> > having a static parent for the purposes of retrieval, and a dynamic or
> > _effective_ parent for the purposes of layout.
> >
> > It is easy enough to figure out what the effective parent for layout is;
> > my question is, since you are the properties guru, what is the most
> > effective mechanism for re-initiating inheritance using this effective
> > parent? This would have to be done every time a marker is used. I could
> > work it out eventually, but I'm lazy. :-)
> >
> > Thanks. Arved.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
--
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Halifax, Nova Scotia
Wireless * B2B * J2EE * XML
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org