Glen Mazza wrote:
Oh, I'm sorry, it involves
re-thinking the building of the FO tree, using stream parsing.
Peter, are you saying that a pull parser is more computationally powerful
than a SAX Parser--or is it just much more convenient? I don't think pull
parsers can do more than SAX Parsers for
- Original Message -
From: "Peter B. West" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 08, 2004 8:20 PM
Subject: Re: Another problem with Marker.rebind()
> Oh, I'm sorry, it involves
> re-thinking the building of the FO tree,
Victor Mote wrote:
Simon Pepping wrote:
Both markers are printed in blue. Perhaps it would be a
solution to clone the subtree below the marker to
retrieve-marker, and rebind that copy. That would be another
example of layout dependent data in the FO tree. If every
There is a certain wry enter
Simon Pepping wrote:
> Both markers are printed in blue. Perhaps it would be a
> solution to clone the subtree below the marker to
> retrieve-marker, and rebind that copy. That would be another
> example of layout dependent data in the FO tree. If every
Just by way of clarification, this is n
I noticed another problem with Marker.rebind(): When the same marker
is retrieved more than once, the first rebind is overwritten with the
second. See this example:
red: ,
blue: .
Both markers are printed in blue. Perhaps it would be a solution to
clone
[Simon]
I have just committed a patch which fixes bug 32253. One problem
remains: the text in the marker does not always have the right
properties, e.g. the right size. This is probably due to the fact that
Marker.rebind() does not rebind the whole subtree below a marker.
Your right! It seems that
Hi,
I have just committed a patch which fixes bug 32253. One problem
remains: the text in the marker does not always have the right
properties, e.g. the right size. This is probably due to the fact that
Marker.rebind() does not rebind the whole subtree below a marker.
Regards, Simon
--
Simon
