I see. Thanks for the explanation.
Glen
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > BTW, without divulging too much that may hurt your
> > interests, would you mind explaining your
> reluctance
> > to just modify FOP source (replace classes, etc.)
> > for what you are trying to market? Is it
[Glen]
Oh, when I meant "alter the system" I also meant
adding classes, using different classes, etc., i.e.,
some things need to be done beforehand to accomodate a
new element.
Come on! That leaves "alter the system" without any meaning. Recompiling
modified sources into a new fop.jar would IMO me
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> On 29.08.2004 20:57:54 Simon Pepping wrote:
> > On Sun, Aug 29, 2004 at 08:15:38PM +0200,
> J.Pietschmann wrote:
> > > Glen Mazza wrote:
> > > >You have a new FO, you're going to need to code
> for
> > > >them--including ordering and cardinality--
On 29.08.2004 20:57:54 Simon Pepping wrote:
> On Sun, Aug 29, 2004 at 08:15:38PM +0200, J.Pietschmann wrote:
> > Glen Mazza wrote:
> > >You have a new FO, you're going to need to code for
> > >them--including ordering and cardinality--in those
> > >parents that accept them,
> >
> > This does *not
On Sun, Aug 29, 2004 at 08:15:38PM +0200, J.Pietschmann wrote:
> Glen Mazza wrote:
> >You have a new FO, you're going to need to code for
> >them--including ordering and cardinality--in those
> >parents that accept them,
>
> This does *not* necessarily mean that *you* should arrange
> that the ext
Glen Mazza wrote:
There shouldn't be extensions hardcoded
I thought of that (i.e., just make us a nice reference
implementation of the XSL standard), but PDF bookmarks
are just too popular
[snip]
I didn't meant the bookmark extension should be discarded,
I meant the code should be pulled out of the
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > Provided the extension namespace isn't already
> > hardcoded into FOP (like the fox: one).
>
> There shouldn't be extensions hardcoded into the FOP
> core,
> at least in the long term.
>
I thought of that (i.e., just make us
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > Option #1:
> >
> > 1.) myextension.jar will need a FOElementMapping
> [1]
> > subclass that will reroute fo:Block from
> Block.java to
> > FinnBlock.java. Have FinnBlock.java override the
> > vCN() for the new validation rules.
>
> This would eventu
Glen Mazza wrote:
Provided the extension namespace isn't already
hardcoded into FOP (like the fox: one).
There shouldn't be extensions hardcoded into the FOP core,
at least in the long term.
Errr, elements can't "validate themselves", because
the validity of an element is defined only by the
parent
I don't want to change any FOP code! And if I have
to change any FOP
sources to add an extension, then FOP doesn't
support extension with the
meaning of extension as I understand it.
[Glen]
From what I understand a program may not change its
own source code while it is running so we may not have
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Finn Bock wrote:
> > An extension mechanism where I can put an
> unmodified fop.jar and
> > myextension.jar on the CLASSPATH and have it work
> is a defining issue to
> > me.
>
> That's how it should work. The code build into the
> FOP core
> sho
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> I don't want to change any FOP code! And if I have
> to change any FOP
> sources to add an extension, then FOP doesn't
> support extension with the
> meaning of extension as I understand it.
>
>From what I understand a program may not change its
own
Finn Bock wrote:
An extension mechanism where I can put an unmodified fop.jar and
myextension.jar on the CLASSPATH and have it work is a defining issue to
me.
That's how it should work. The code build into the FOP core
should only validate elements from the fo namespace and
attributes from no nam
Extension writers has to create a subclass of
AbstractLayoutManager (I
just use a LeafNodeLayoutManager) and an subclass of
Area. But that are
normal operations since there are subclasses of
those for each element
type. I must also add code to the renderer to handle
my area, but that
is becaus
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> Extension writers has to create a subclass of
> AbstractLayoutManager (I
> just use a LeafNodeLayoutManager) and an subclass of
> Area. But that are
> normal operations since there are subclasses of
> those for each element
> type. I must also add c
[Glen]
Extension elements are handled within
validateChildNode() just like regular formatting
objects, such as e.g. fox:bookmarks in fo:root [2].
We appear to have two categories of extension
elements:
1.) (svg and MathML for example): These are
dynamically loadable extension elements that are
Hello Finn,
[BTW, before I get to this topic, as you've probably
noticed by now I've finished removing the
AddLMVisitor. In the process, I also created about
eight new layout manager classes, pulling out the
layout business logic that used to be in AddLMVisitor.
As a result, the maker system you
Glen
I think that the new validateChildNode() methods are too strict in
response to extension elements. My guess is that the validation should
only occur when one fo namespace element is added to another fo element.
For instance, Block.validateChildNode() doesn't allow any of my
extension eleme
18 matches
Mail list logo
