You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Raphael Parree <rp...@gmail.com> on 2010/02/09 10:40:57 UTC
XMLFilterImpl producing SVG instream-foreign-object
Hi,
I wrote an XMLFilterImpl which produces a instream-foreign-object. In
another filter i was able to call the super methods to push the result in
the FO tree: In this case i can use that because the SVG needs to be parsed
String svgText = umlDiagramProducer.produceSVGText(s);
super.startElement(FONS, "instream-foreign-object",
"fo:instream-foreign-object", attributes);
//what am i going to put here???
super.endElement(FONS, "instream-foreign-object",
"fo:instream-foreign-object");
I tried super.parse(new InputSource(new StringReader(svgText)));
and a new SAXParser passing the parent contenthandler, but all results in
exceptions.
Thanks!
--
Raphael Parree
Re: XMLFilterImpl producing SVG instream-foreign-object
Posted by Raphael Parree <rp...@gmail.com>.
Andreas,
Thanks for confirming!
Yes indeed i found out i had to bypass the startDocument method - still
smells a bit, but then again fish is tasty
What i am making is a possibility to include PlantUML (
http://plantuml.sourceforge.net/) UML diagrams in the FOP rendering
<uml-diagram format="svg" ...>
@startuml
Alice -> Bob: Authentication Request
Bob --> Alice: Authentication Response
Alice -> Bob: Another authentication Request
Alice <-- Bob: another authentication Response
@enduml
</uml-diagram>
I get the basic UML diagram, just need to work a bit on the size (hopefully
next weekend ). What would be a way to make it a more structural solution
(like barcode etc) so perhaps other people can use it as well?
tx.,
On Tue, Mar 16, 2010 at 7:44 PM, Andreas Delmelle <
andreas.delmelle@telenet.be> wrote:
> On 15 Mar 2010, at 07:35, Raphael Parree wrote:
>
> Hi Raphael
>
> > I have meanwhiel found a way of making it work - i am sure there must be
> a better way; what i'm doing below smells pretty bad...
> > I SAX parse the SVG and propagate its SAX events to the XmlFilter's
> parent content handler:
>
> The key reason, I think, the chosen approach is working (where your
> original cited approach wasn't), is simply because it does not propagate the
> startDocument() and endDocument() events to the parent.
>
> (Interesting to note that FOP needs to do the exact opposite at parse-time:
> the embedded SVG comes in as just another startElement(), and the child
> events are then routed to a delegate ContentHandler, precisely because
> raising startDocument() more than once on the same ContentHandler would lead
> to an exception.)
>
> Maybe it would be slightly better to define an explicit DefaultHandler
> subclass, as opposed to using anonymous overrides, but the net effect would
> be the same.
>
> IMO, it would look nicer, and would definitely be preferable over your
> current solution if you need the same approach in multiple places, but the
> bottom line is that your solution is correct.
> It smells a bit fishy maybe, but using an intermediate DefaultHandler that
> swallows startDocument() and endDocument() definitely seems like the most
> straightforward way to tackle this issue.
>
>
> HTH!
>
> Regards,
>
>
> Andreas Delmelle
> ---
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
--
Raphael Parree
CTO
SOA Evangelist
phone +33 673 75 34 62
Disclaimer...
"The information contained in this message may be confidential and is
intended to be exclusively for the addressee. Sender's written permission is
needed prior to forwarding or otherwise using the content of the message,
whether completely or partially. Should you receive this message
unintentionally, please do not use the contents herein and notify the sender
immediately by return e-mail. Please rely on your own virus checking, no
responsibility is taken by the sender for any damage rising out of any bug
or virus infection."
Re: XMLFilterImpl producing SVG instream-foreign-object
Posted by Andreas Delmelle <an...@telenet.be>.
On 15 Mar 2010, at 07:35, Raphael Parree wrote:
Hi Raphael
> I have meanwhiel found a way of making it work - i am sure there must be a better way; what i'm doing below smells pretty bad...
> I SAX parse the SVG and propagate its SAX events to the XmlFilter's parent content handler:
The key reason, I think, the chosen approach is working (where your original cited approach wasn't), is simply because it does not propagate the startDocument() and endDocument() events to the parent.
(Interesting to note that FOP needs to do the exact opposite at parse-time: the embedded SVG comes in as just another startElement(), and the child events are then routed to a delegate ContentHandler, precisely because raising startDocument() more than once on the same ContentHandler would lead to an exception.)
Maybe it would be slightly better to define an explicit DefaultHandler subclass, as opposed to using anonymous overrides, but the net effect would be the same.
IMO, it would look nicer, and would definitely be preferable over your current solution if you need the same approach in multiple places, but the bottom line is that your solution is correct.
It smells a bit fishy maybe, but using an intermediate DefaultHandler that swallows startDocument() and endDocument() definitely seems like the most straightforward way to tackle this issue.
HTH!
Regards,
Andreas Delmelle
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: XMLFilterImpl producing SVG instream-foreign-object
Posted by Raphael Parree <rp...@gmail.com>.
Hi,
I have meanwhiel found a way of making it work - i am sure there must be a
better way; what i'm doing below smells pretty bad...
I SAX parse the SVG and propagate its SAX events to the XmlFilter's parent
content handler:
===================================
XMLReader xmlReader = XMLReaderFactory.createXMLReader();
*final ContentHandler ch = super.getContentHandler();*
xmlReader.setContentHandler(new DefaultHandler() {
@Override
public void startElement(String uri, String localName, String qName,
Attributes a) {
*ch*.startElement(uri, localName, qName, a);
}
@Override
public void endElement(String uri, String localName, String qName) throws
SAXException {
*ch*.endElement(uri, localName, qName);
}
@Override
public void characters(char[] chars, int start, int length) throws
SAXException {
*ch*.characters(chars, start, length);
}
});
xmlReader.parse(new InputSource(new StringReader(svgText)));
===================================
On Thu, Feb 18, 2010 at 1:30 PM, Raphael Parree <rp...@gmail.com> wrote:
> I am still struggling with this one...anybody might have a answer or
> direction?
>
> On Tue, Feb 9, 2010 at 10:40 AM, Raphael Parree <rp...@gmail.com> wrote:
>
>> Hi,
>>
>> I wrote an XMLFilterImpl which produces a instream-foreign-object. In
>> another filter i was able to call the super methods to push the result in
>> the FO tree: In this case i can not use that because the XML of the SVG
>> needs to be parsed
>>
>> String svgText = umlDiagramProducer.produceSVGText(s);
>>
>> super.startElement(FONS, "instream-foreign-object",
>> "fo:instream-foreign-object", attributes);
>> //what am i going to put here???
>> super.endElement(FONS, "instream-foreign-object",
>> "fo:instream-foreign-object");
>>
>>
>> I tried super.parse(new InputSource(new StringReader(svgText)));
>> and a new SAXParser passing the parent contenthandler, but all results in
>> exceptions.
>>
>> Thanks!
>> --
>> Raphael Parree
>>
>>
>
>
> --
> Raphael Parree
> CTO
> SOA Evangelist
>
> phone +33 673 75 34 62
> Disclaimer...
> "The information contained in this message may be confidential and is
> intended to be exclusively for the addressee. Sender's written permission is
> needed prior to forwarding or otherwise using the content of the message,
> whether completely or partially. Should you receive this message
> unintentionally, please do not use the contents herein and notify the sender
> immediately by return e-mail. Please rely on your own virus checking, no
> responsibility is taken by the sender for any damage rising out of any bug
> or virus infection."
>
>
--
Raphael Parree
CTO
SOA Evangelist
phone +33 673 75 34 62
Disclaimer...
"The information contained in this message may be confidential and is
intended to be exclusively for the addressee. Sender's written permission is
needed prior to forwarding or otherwise using the content of the message,
whether completely or partially. Should you receive this message
unintentionally, please do not use the contents herein and notify the sender
immediately by return e-mail. Please rely on your own virus checking, no
responsibility is taken by the sender for any damage rising out of any bug
or virus infection."
Re: XMLFilterImpl producing SVG instream-foreign-object
Posted by Raphael Parree <rp...@gmail.com>.
I am still struggling with this one...anybody might have a answer or
direction?
On Tue, Feb 9, 2010 at 10:40 AM, Raphael Parree <rp...@gmail.com> wrote:
> Hi,
>
> I wrote an XMLFilterImpl which produces a instream-foreign-object. In
> another filter i was able to call the super methods to push the result in
> the FO tree: In this case i can not use that because the XML of the SVG
> needs to be parsed
>
> String svgText = umlDiagramProducer.produceSVGText(s);
>
> super.startElement(FONS, "instream-foreign-object",
> "fo:instream-foreign-object", attributes);
> //what am i going to put here???
> super.endElement(FONS, "instream-foreign-object",
> "fo:instream-foreign-object");
>
>
> I tried super.parse(new InputSource(new StringReader(svgText)));
> and a new SAXParser passing the parent contenthandler, but all results in
> exceptions.
>
> Thanks!
> --
> Raphael Parree
>
>
--
Raphael Parree
CTO
SOA Evangelist
phone +33 673 75 34 62
Disclaimer...
"The information contained in this message may be confidential and is
intended to be exclusively for the addressee. Sender's written permission is
needed prior to forwarding or otherwise using the content of the message,
whether completely or partially. Should you receive this message
unintentionally, please do not use the contents herein and notify the sender
immediately by return e-mail. Please rely on your own virus checking, no
responsibility is taken by the sender for any damage rising out of any bug
or virus infection."