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 Keiron Liddle <ke...@aftexsw.com> on 2000/07/11 13:15:35 UTC
fo:instream-foreign-object
Peter Murray-Rust wrote:
> >On a very related note I suspect that we are not currently embedding SVG
> >properly. I stand to be corrected. I looked at the example file
> >"extensive.fo", which wraps SVG directly in fo:block. This is not kosher.
> >:-) I'll have to review Keiron Liddle's latest examples. If we are somewhat
> >down the wrong track here I think this is relatively easy to change. I just
> >want to reiterate that the mechanism would definitely be
> >fo:instream-foreign-object.
> Thanks very much. I haven't used fo:instream-foreign-object but it sounds
> just what is required. There are many disciplines - like maths, chemistry,
> graphs, where the presentation and the content are closely connected.
> Although CML is designed to manage chemical content some ideas can only be
> conveyed presentationally (SVG/FO). It will be quite common to interrogate
> SVG or FO for embedded content and this is much more convenient than having
> separate files.
>
> Yet another reason why I like the FO approach...
>
Yes the svg document should be entirely within an fo:instream-foreign-object,
this has not been implemented yet, currently it is just on the todo list.
On a related note:
I have been thinking about a way to allow for other name spaces in the
fo:instream-foreign-object (for example CML) without actually going to all the
trouble of writing a new dom/rendering etc for it.
The idea is that if the parser encounters a particular namespace then it will
be able to construct the basic dom tree (without needing to know about the
elements and properties directly with our mapping mechanism) and then apply an
xslt transform to create an svg document. From there it will do the same svg
stuff and be able to render the CML document without needing preprocessing.
I think this could be very useful and save time and effort.
What do you all think?
Keiron.
Re: fo:instream-foreign-object
Posted by Peter Murray-Rust <Pe...@nottingham.ac.uk>.
At 10:58 15/07/00 +1000, Keiron Liddle wrote:
[ a very helpful reply about DOMs which reassured me that I was taking a
reasonable approach with CML-DOM [used as an example for other DOMs].
>Peter Murray-Rust wrote:
>
> > I would be very interested in feedback here and hope the following is
> > useful. [Although I use CML as an example it applies to any *ML which uses
> > its own DOM and also has graphical properties.]
> > I am currently implementing a CMLDOM myself (I'd be interested in feedback
> > - it's not trivial!). I have adopted the following generic approach, and
> > wonder how common it is for all DOMs (I have talked with authors of the IBM
> > MathML DOM, but not about SVGDOMs. Does FOP have a DOM implementation? [I
> > assume that large documents would have problems here.]
>
>In general FOP produces an intermediatary group of objects that can be
>rendered.
>The formatting objects are converted into thiese objects. It does not use
>a DOM
>and does not retain a lot of the original formatting information only what is
>necessary to render the objects (I believe).
Thanks - I suspected that since a DOM for many documents would give severe
memory problems.
> > In creating a DOM I have made the following decisions:
> > - Xerces is used as the primary DOM implementation. [The DOM
> > design can make it difficult to switch between implementations without
> > recompiling.]
>
>Sounds right to me. I could not do this for svg due to a method name
>clash, which
>is fixed for the next WD.
Thanks for confirming this. The problem I have with DOM1 is that methods
such as:
Element.setTagName()
Element.setOwnerDocument()
are not in the DOM, but they are extremely useful (if dangerous). Often an
element is generated which we wish to modify later or move around. Both
Xerces and SUN have these (or equivalents) as protected methods and clearly
they have found limitations.
> > Therefore I have complete CMLDOM which is subclassed from DocumentImpl and
> > ElementImpl. It means that it should be very easy to merge into other DOMs
> > which use the same approach. For example traversal could traverse over
> > several namespaces in the same document, and use the standard API in
> > org.w3.dom.*
>
>Yes, but the only traversals I can think of, in the FOP context, are namespace
>specific unless we can separate the rendering in a way that the dom
>traversal is
>independant.
I had hoped that we could.
FOP (or XSL-FO) would give us some generic (i.e. namespace-independent)
methods which were called on traversal. I would then write to these.
> >
> > The problem comes when I need further functionality which might be shared
> > with other namespaces. The methods might include:
> > - process() // this carries out class-specific processing on each
> > element after it has been read in from XML
> > - isValid() // class-specific validity (e.g. are the right numbers
> > of atoms connected)
> > - output(Writer) // output a given node
> > - display() // display a given node (to appropriate medium)
> > - edit() // brings up editing functionality (might overlap with
> > display()) - this could be part of the AWTRenderer perhaps.
> > - and so on.
> >
> > [There are of course CML-specific things like getMolecularWeight(). Each
> > element has an interface to define these.]
>
>I haven't really encountered this sort of thing yet.
I think that some of these are the generic methods that might be useful in
a FOP traversal
> >
> >
> > I have created the CMLDOM to be an editor as well as a renderer so it can
> > support the following functions:
> > - create a DOM from scratch and build it up
> > - read legacy and build CML DOM from that
> > - read XML/CML into the DOM
> > - allow editing of the DOM (delete, move, set Attribute, etc.)
> > - write XML/CML or legacy
> >
> > additionally it could output SVG with much greater functionality that XSLT
> > would provide.
> >
> > If I have understood you correctly there are two ends of the spectrum:
> > - read the complete XML input, identify the namespaces, hold them
> > as W3C DOMs and transform (in memory) with namespace-specific XSLT. This
> > only requires a generic XSLT processor such as Xalan (or possibly a subset
> > would do)
> > - read the XML input, convert to namespace-specific DOMS and
> > traverse these with appropriate API these to generate an SVG DOM which is
> > then transformed to FO. We could also make a case directly for
> > transformation into FO in some cases.
>
>Yes, they would probably be the extremes.
>Some things may be easily converted to svg using an XSLT.
Yes - I already do this where it is easy and only involves existing tokens
or elements.
>Some may require more processing (CML) and maybe conversion to SVG
>Some may have graphic and some other useful information, which could be
>put in the
>pdf
Yes
>Some may be purely some other information, which could be rendered
>(probably not
>put into FO)
>
> >
> >
> > Hope this is on the right lines.
> >
>
>Yes.
It is really useful to have this sort of confirmation!
P.
Peter Murray-Rust, Director Virtual School of Molecular Sciences
Pharmaceutical Sciences, University of Nottingham, NG7 2RD, UK
Tel: +44-(0)-115-951-5087 Fax: +44-(0)-115-951-5110
http://www.vsms.nottingham.ac.uk
Re: fo:instream-foreign-object
Posted by Keiron Liddle <ke...@aftexsw.com>.
Peter Murray-Rust wrote:
> I would be very interested in feedback here and hope the following is
> useful. [Although I use CML as an example it applies to any *ML which uses
> its own DOM and also has graphical properties.]
>
> Note that CML could be used with FO in the following ways:
> - transformed from CML to SVG using XSLT. This is what we do at
> present and we have a simple CML2SVG (and hence CML2FO) transformation. FO
> and SVG "don't need to know that this is chemistry - perhaps the limit is
> wrapping CML in <defs> or <fo:foreign-instream-object>. The main
> restriction is that only a subset of CML can be transformed - even with
> extension-functions. [Is this what you were asking about?]
> - a native CML-SVG engine or CML-FO engine. This would conform to
> the output API from an implementation and might treat <cml:molecule> as a
> primitive having the same status as <svg:rect> or <fo:table>. We normally
> render into a rectangular area and I suspect this goes for many other
> applications. In some cases (e.g. equations) there *might* be requirements
> for object-specific wrapping but this is fairly advanced! This requires the
> CML to be implemented as a DOM.
>
> >The idea is that if the parser encounters a particular namespace then it will
> >be able to construct the basic dom tree (without needing to know about the
> >elements and properties directly with our mapping mechanism) and then apply an
> >xslt transform to create an svg document. From there it will do the same svg
> >stuff and be able to render the CML document without needing preprocessing.
> >I think this could be very useful and save time and effort.
>
> I am currently implementing a CMLDOM myself (I'd be interested in feedback
> - it's not trivial!). I have adopted the following generic approach, and
> wonder how common it is for all DOMs (I have talked with authors of the IBM
> MathML DOM, but not about SVGDOMs. Does FOP have a DOM implementation? [I
> assume that large documents would have problems here.]
In general FOP produces an intermediatary group of objects that can be rendered.
The formatting objects are converted into thiese objects. It does not use a DOM
and does not retain a lot of the original formatting information only what is
necessary to render the objects (I believe).
> In creating a DOM I have made the following decisions:
> - Xerces is used as the primary DOM implementation. [The DOM
> design can make it difficult to switch between implementations without
> recompiling.]
Sounds right to me. I could not do this for svg due to a method name clash, which
is fixed for the next WD.
>
> - every element has its own class which is a subclass of
> ElementImpl. There is a hierarchy including abstract classes to capture as
> much communality as possible. I have subclassed rather than delegating
> because I find it easier to explain to potential users - I'd be grateful
> for comments on this
Yes this is my approach too. In general I err on the conservative side, so that I
have a class (which is not abstract) that captures many common methods and
subclasses may have methods that are not required.
> - every attribute is likely to need an Interface (since attributes
> can occur on several elements (like style in SVG).
Yes. Also makes it easier to added attribute info and get info for rendering.
> Therefore I have complete CMLDOM which is subclassed from DocumentImpl and
> ElementImpl. It means that it should be very easy to merge into other DOMs
> which use the same approach. For example traversal could traverse over
> several namespaces in the same document, and use the standard API in
> org.w3.dom.*
Yes, but the only traversals I can think of, in the FOP context, are namespace
specific unless we can separate the rendering in a way that the dom traversal is
independant.
>
> The problem comes when I need further functionality which might be shared
> with other namespaces. The methods might include:
> - process() // this carries out class-specific processing on each
> element after it has been read in from XML
> - isValid() // class-specific validity (e.g. are the right numbers
> of atoms connected)
> - output(Writer) // output a given node
> - display() // display a given node (to appropriate medium)
> - edit() // brings up editing functionality (might overlap with
> display()) - this could be part of the AWTRenderer perhaps.
> - and so on.
>
> [There are of course CML-specific things like getMolecularWeight(). Each
> element has an interface to define these.]
I haven't really encountered this sort of thing yet.
>
>
> I have created the CMLDOM to be an editor as well as a renderer so it can
> support the following functions:
> - create a DOM from scratch and build it up
> - read legacy and build CML DOM from that
> - read XML/CML into the DOM
> - allow editing of the DOM (delete, move, set Attribute, etc.)
> - write XML/CML or legacy
>
> additionally it could output SVG with much greater functionality that XSLT
> would provide.
>
> If I have understood you correctly there are two ends of the spectrum:
> - read the complete XML input, identify the namespaces, hold them
> as W3C DOMs and transform (in memory) with namespace-specific XSLT. This
> only requires a generic XSLT processor such as Xalan (or possibly a subset
> would do)
> - read the XML input, convert to namespace-specific DOMS and
> traverse these with appropriate API these to generate an SVG DOM which is
> then transformed to FO. We could also make a case directly for
> transformation into FO in some cases.
Yes, they would probably be the extremes.
Some things may be easily converted to svg using an XSLT.
Some may require more processing (CML) and maybe conversion to SVG
Some may have graphic and some other useful information, which could be put in the
pdf
Some may be purely some other information, which could be rendered (probably not
put into FO)
>
>
> Hope this is on the right lines.
>
Yes.
Re: fo:instream-foreign-object
Posted by Peter Murray-Rust <Pe...@nottingham.ac.uk>.
At 21:15 11/07/00 +1000, Keiron Liddle wrote:
>Yes the svg document should be entirely within an fo:instream-foreign-object,
>this has not been implemented yet, currently it is just on the todo list.
>
>On a related note:
>I have been thinking about a way to allow for other name spaces in the
>fo:instream-foreign-object (for example CML) without actually going to all the
>trouble of writing a new dom/rendering etc for it.
I would be very interested in feedback here and hope the following is
useful. [Although I use CML as an example it applies to any *ML which uses
its own DOM and also has graphical properties.]
Note that CML could be used with FO in the following ways:
- transformed from CML to SVG using XSLT. This is what we do at
present and we have a simple CML2SVG (and hence CML2FO) transformation. FO
and SVG "don't need to know that this is chemistry - perhaps the limit is
wrapping CML in <defs> or <fo:foreign-instream-object>. The main
restriction is that only a subset of CML can be transformed - even with
extension-functions. [Is this what you were asking about?]
- a native CML-SVG engine or CML-FO engine. This would conform to
the output API from an implementation and might treat <cml:molecule> as a
primitive having the same status as <svg:rect> or <fo:table>. We normally
render into a rectangular area and I suspect this goes for many other
applications. In some cases (e.g. equations) there *might* be requirements
for object-specific wrapping but this is fairly advanced! This requires the
CML to be implemented as a DOM.
>The idea is that if the parser encounters a particular namespace then it will
>be able to construct the basic dom tree (without needing to know about the
>elements and properties directly with our mapping mechanism) and then apply an
>xslt transform to create an svg document. From there it will do the same svg
>stuff and be able to render the CML document without needing preprocessing.
>I think this could be very useful and save time and effort.
I am currently implementing a CMLDOM myself (I'd be interested in feedback
- it's not trivial!). I have adopted the following generic approach, and
wonder how common it is for all DOMs (I have talked with authors of the IBM
MathML DOM, but not about SVGDOMs. Does FOP have a DOM implementation? [I
assume that large documents would have problems here.]
In creating a DOM I have made the following decisions:
- Xerces is used as the primary DOM implementation. [The DOM
design can make it difficult to switch between implementations without
recompiling.]
- every element has its own class which is a subclass of
ElementImpl. There is a hierarchy including abstract classes to capture as
much communality as possible. I have subclassed rather than delegating
because I find it easier to explain to potential users - I'd be grateful
for comments on this
- every attribute is likely to need an Interface (since attributes
can occur on several elements (like style in SVG).
Therefore I have complete CMLDOM which is subclassed from DocumentImpl and
ElementImpl. It means that it should be very easy to merge into other DOMs
which use the same approach. For example traversal could traverse over
several namespaces in the same document, and use the standard API in
org.w3.dom.*
The problem comes when I need further functionality which might be shared
with other namespaces. The methods might include:
- process() // this carries out class-specific processing on each
element after it has been read in from XML
- isValid() // class-specific validity (e.g. are the right numbers
of atoms connected)
- output(Writer) // output a given node
- display() // display a given node (to appropriate medium)
- edit() // brings up editing functionality (might overlap with
display()) - this could be part of the AWTRenderer perhaps.
- and so on.
[There are of course CML-specific things like getMolecularWeight(). Each
element has an interface to define these.]
I have created the CMLDOM to be an editor as well as a renderer so it can
support the following functions:
- create a DOM from scratch and build it up
- read legacy and build CML DOM from that
- read XML/CML into the DOM
- allow editing of the DOM (delete, move, set Attribute, etc.)
- write XML/CML or legacy
additionally it could output SVG with much greater functionality that XSLT
would provide.
If I have understood you correctly there are two ends of the spectrum:
- read the complete XML input, identify the namespaces, hold them
as W3C DOMs and transform (in memory) with namespace-specific XSLT. This
only requires a generic XSLT processor such as Xalan (or possibly a subset
would do)
- read the XML input, convert to namespace-specific DOMS and
traverse these with appropriate API these to generate an SVG DOM which is
then transformed to FO. We could also make a case directly for
transformation into FO in some cases.
>What do you all think?
Hope this is on the right lines.
P.
Peter Murray-Rust, Director Virtual School of Molecular Sciences
Pharmaceutical Sciences, University of Nottingham, NG7 2RD, UK
Tel: +44-(0)-115-951-5087 Fax: +44-(0)-115-951-5110
http://www.vsms.nottingham.ac.uk
Re: fo:instream-foreign-object
Posted by Keiron Liddle <ke...@aftexsw.com>.
Arved Sandstrom wrote:
> At 09:15 PM 7/11/00 +1000, Keiron Liddle wrote:
> >On a related note:
> >I have been thinking about a way to allow for other name spaces in the
> >fo:instream-foreign-object (for example CML) without actually going to all
> the
> >trouble of writing a new dom/rendering etc for it.
> >The idea is that if the parser encounters a particular namespace then it will
> >be able to construct the basic dom tree (without needing to know about the
> >elements and properties directly with our mapping mechanism) and then
> apply an
> >xslt transform to create an svg document. From there it will do the same svg
> >stuff and be able to render the CML document without needing preprocessing.
> >I think this could be very useful and save time and effort.
> >
> >What do you all think?
> >
> >Keiron.
> >
> I would like to see an approach that, at a higher level, allows for content
> processors to be registered with FOP through the namespace mechanism. We'd
> start handling this in FOTreeBuilder - this is particularly appropriate now
> that FOP is SAX2 aware, which means that namespace information is more
> conveniently presented.
>
> In this context, I think that what you are describing is a useful _default_
> for such content processors. We can anticipate that most foreign namespaces
> will result in graphic content; using SVG as an intermediary is a good
> fallback.
>
> We should also move to a picture where FOP is not, in and of itself, aware
> of SVG. SVG processing would occur in the same manner as that I have
> pictured for other content in fo:instream-foreign-object. SVG would enjoy a
> "friend" status as being the "reference implementation" for content
> processors, and the content processors for other XSL namespaces would
> frequently call upon the SVG content processor.
>
> We need to be aware that the spec says that fo:instream-foreign-object is
> for "generic" objects, not just for graphics. The core FOP processor cannot,
> and should not, know that there are such beasts as SVG or MathML, nor should
> it be aware of the formats that it is rendering to.
>
> I think we have an interface/API problem. I can think of at least 5 entry
> points for external "stuff" -
>
> (1) front-end: how does FOP get called?
>
> (2) calling self: have we thought about this?
>
> (3) fo:instream-foreign-graphic: registering content processors with FOP,
> and receiving output in the layout package - stuff known to FOP;
>
> (4) fo:external-graphic: renderers must be available to handle foreign
> content.
>
> (5) Renderers: what API will they use? Are we currently exposing our layout
> objects appropriately? Can we support voice? Etc.
>
> Just some thoughts. This is internal architecture stuff, though. We can talk
> about that later. If you get your idea happening we'll be OK for a while.
I agree with all of this (although I'm not entirely clear about front-end and
calling self and registering handlers).
There is a lot that needs to be done, so I will try to separate out the code
piece by piece.
- separate properties (done but too slow)
- separate rendering
- separate content processing (external images, foreign-graphic etc.)
- generic namespace processor -> convert to svg with xslt
This will take some time so we'll just have to see things go.
Re: fo:instream-foreign-object
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 09:15 PM 7/11/00 +1000, Keiron Liddle wrote:
>On a related note:
>I have been thinking about a way to allow for other name spaces in the
>fo:instream-foreign-object (for example CML) without actually going to all
the
>trouble of writing a new dom/rendering etc for it.
>The idea is that if the parser encounters a particular namespace then it will
>be able to construct the basic dom tree (without needing to know about the
>elements and properties directly with our mapping mechanism) and then
apply an
>xslt transform to create an svg document. From there it will do the same svg
>stuff and be able to render the CML document without needing preprocessing.
>I think this could be very useful and save time and effort.
>
>What do you all think?
>
>Keiron.
>
I would like to see an approach that, at a higher level, allows for content
processors to be registered with FOP through the namespace mechanism. We'd
start handling this in FOTreeBuilder - this is particularly appropriate now
that FOP is SAX2 aware, which means that namespace information is more
conveniently presented.
In this context, I think that what you are describing is a useful _default_
for such content processors. We can anticipate that most foreign namespaces
will result in graphic content; using SVG as an intermediary is a good
fallback.
We should also move to a picture where FOP is not, in and of itself, aware
of SVG. SVG processing would occur in the same manner as that I have
pictured for other content in fo:instream-foreign-object. SVG would enjoy a
"friend" status as being the "reference implementation" for content
processors, and the content processors for other XSL namespaces would
frequently call upon the SVG content processor.
We need to be aware that the spec says that fo:instream-foreign-object is
for "generic" objects, not just for graphics. The core FOP processor cannot,
and should not, know that there are such beasts as SVG or MathML, nor should
it be aware of the formats that it is rendering to.
I think we have an interface/API problem. I can think of at least 5 entry
points for external "stuff" -
(1) front-end: how does FOP get called?
(2) calling self: have we thought about this?
(3) fo:instream-foreign-graphic: registering content processors with FOP,
and receiving output in the layout package - stuff known to FOP;
(4) fo:external-graphic: renderers must be available to handle foreign
content.
(5) Renderers: what API will they use? Are we currently exposing our layout
objects appropriately? Can we support voice? Etc.
Just some thoughts. This is internal architecture stuff, though. We can talk
about that later. If you get your idea happening we'll be OK for a while.
Arved
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"