Andreas L. Delmelle wrote:
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
So we not can assume the xml->xsl->fo
processing was had via Xalan--and even if it were so, it also could have
been done via its translets (compiled XSLT) feature.
Aw, great! You just *had
Finn Bock wrote:
Somehow, in our current design, the information must be stored in an
object that exists:
IIRC that's what the layout context was meant for.
J.Pietschmann
> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
>
> If in the re-use the layout would not change, the area tree could be
> reused. OTOH, if the layout would change, e.g. because another
> renderer would use a font with a different font metric, the layout
> information
On Sun, Feb 15, 2004 at 10:43:12PM +0100, Finn Bock wrote:
> [Simon Pepping]
>
> I initially had a separate PropertyContext object where the length was
> stored. The FO element then had a reference to the PropertyContext and
> there was a PropertyContext for every FO. But since there was a
> on
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> So we not can assume the xml->xsl->fo
> processing was had via Xalan--and even if it were so, it also could have
> been done via its translets (compiled XSLT) feature.
>
Aw, great! You just *had* to come and throw that on
Andreas L. Delmelle wrote:
Nightmares... Anyone to come and chase them away?
Please...? ;)
One thing to keep in mind, although I'm unsure of its relevance to this
discussion, is we use Xalan only through JAXP--so if I'm not mistaken,
the user is welcome to replace that with another JAXP-com
On Mon, Feb 16, 2004 at 08:22:31PM +0100, Andreas L. Delmelle wrote:
> > -Original Message-
> > From: Finn Bock [mailto:[EMAIL PROTECTED]
> >
> > [Simon Pepping]
> >
>
> > > However, I am not happy with your
> > > solution. During the layout process, you feed the page dimensions back
> > >
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
> Or, to describe in XSLT terms, I think closest would be: all
> elements in the
> vendor's redirection extension's namespace having their target
> URI attribute end in '.fo'
Something just struck me; might be a lo
> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>
> Can you give an example of how would his look? Would it be an ant task?
> Would it be some type of java class? Thanks!
>
Well, Maestro, started to think about subclassing, but I'm not sure in what
form *exactly* yet, nei
Andreas L. Delmelle said:
>> -Original Message-
>> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
>> Andreas L. Delmelle wrote:
>>
>>
>>
>> > The related class in Xalan: org.apache.xalan.lib.Redirect
>> >
>> > It contains a HashMap, m_outputStreams, which is,
>> unfortunately, protected,
On Sun, Feb 15, 2004 at 10:43:12PM +0100, Finn Bock wrote:
> [Simon Pepping]
>
> >Finn,
> >
> >I think it
> >would be a better design if, in order to resolve the percent-based
> >properties, you would not climb the FO tree but the Area tree. That
> >avoids feeding back results from the Area tree i
> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> [Simon Pepping]
>
> > However, I am not happy with your
> > solution. During the layout process, you feed the page dimensions back
> > into the FO tree, in PageLayoutManager.createPageAreas.
>
> Yes, and in BlockLayoutMan
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
> Andreas L. Delmelle wrote:
>
>
>
> > The related class in Xalan: org.apache.xalan.lib.Redirect
> >
> > It contains a HashMap, m_outputStreams, which is,
> unfortunately, protected,
> > so can't be queried from outside
Andreas L. Delmelle wrote:
The related class in Xalan: org.apache.xalan.lib.Redirect
It contains a HashMap, m_outputStreams, which is, unfortunately, protected,
so can't be queried from outside the xalan.lib package...
Whats wrong with sub-classing, e.g. FopRedirect extends Redirect.
Bummer!
14 matches
Mail list logo