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 Brian Trezise <Br...@IntelliData.net> on 2008/08/13 18:49:04 UTC
Odd artifact in pdf from external svg image
I just ran across a strange rendering artifact (see attached screenshot) in
my pdf that seems to be coming from the attached svg somehow, but I'm not
sure of the cause. The xsl-fo didn't really give me much in the way of
clues, but I attached it (test.xml) in case somebody thinks it can be more
useful than I found it.
About the svg: created in InkScape, and when viewed in
inkscape/firefox/etc, the artifact is not present. Is this a rendering bug?
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
RE: Odd artifact in pdf from external svg image
Posted by Brian Trezise <Br...@IntelliData.net>.
That got it. Thanks :)
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Wednesday, August 13, 2008 11:22 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Odd artifact in pdf from external svg image
There seems to be a rectangle (id="rect5546") which is painted in black
due to a style element on an ancestor element. Does not look like a
rendering bug to me.
BTW, don't trust Firefox to display every SVG correctly. It's not as
feature-complete as Batik. As to why Inkscape doesn't paint the black
rectangle I can only guess it has to do with the draft status of the SVG
1.2 spec.
On 13.08.2008 18:49:04 Brian Trezise wrote:
> I just ran across a strange rendering artifact (see attached screenshot)
in
> my pdf that seems to be coming from the attached svg somehow, but I'm not
> sure of the cause. The xsl-fo didn't really give me much in the way of
> clues, but I attached it (test.xml) in case somebody thinks it can be more
> useful than I found it.
>
> About the svg: created in InkScape, and when viewed in
> inkscape/firefox/etc, the artifact is not present. Is this a rendering
bug?
>
> ___________________________________________________
> Brian Trezise
> Staff Software Engineer
> IntelliData, Inc
> 22288 E Princeton Dr
> aurora, colorado 80018
> T: 720.524.4864
> brian.trezise@intellidata.net
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Use only a limited number of items in an xsl:for-each
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Brian Trezise wrote:
> I'm using the following to select a subset of items from my xml document to
> be rendered to the pdf; however when I run fop on the xslt/xml, nothing is
> rendered at all:
>
> <xsl:for-each
> select="//*[local-name()='intellispec/aliases/alias'][position()< 3]">
> <xsl:value-of select="."/>
> </xsl:for-each>
>
>> From what I can tell this is valid xslt code,
Well, 'intellispec/aliases/alias' is not a valid element name, which
means nothing will be selected.
>is there another way I need to
> write this to be compatible with FOP 0.95?
You have an XSLT question. This is best asked on the XSL list:
http://www.mulberrytech.com/xsl/xsl-list/
In order to get help, you also need to describe what you want to
do.
> If I
> just do select="intellispec/aliases/alias" in the above for-each all three
> aliases print out as expected.
That's the way it should be done. Why do you think you need the much
more complicated (and brittle) form further above?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Use only a limited number of items in an xsl:for-each
Posted by "Griffin,Sean" <SG...@CERNER.COM>.
Brian,
select="intellispec/aliases/alias" is different than select="//*[local-name()='intellispec/aliases/alias'], if not functionally, at least in the area of performance. Just try select="intellispec/aliases/alias[position() < 3]" and see if that works any better.
BTW, this has nothing to do with FOP and is completely up to the XSLT processor you're using.
-Sean
-----Original Message-----
From: Brian Trezise [mailto:Brian.Trezise@IntelliData.net]
Sent: Monday, August 18, 2008 3:41 PM
To: fop-users@xmlgraphics.apache.org
Subject: Use only a limited number of items in an xsl:for-each
I'm using the following to select a subset of items from my xml document to be rendered to the pdf; however when I run fop on the xslt/xml, nothing is rendered at all:
<xsl:for-each
select="//*[local-name()='intellispec/aliases/alias'][position() < 3]">
<xsl:value-of select="."/>
</xsl:for-each>
>From what I can tell this is valid xslt code, is there another way I need to write this to be compatible with FOP 0.95? Or does FOP not support this functionality and I need to limit the number of aliases elsewhere in my software?
sample xml code:
<intellispec>
<aliases>
<alias>C0805C101J8GAC7800</alias>
<alias>IPUHPIOUSOPIHJPOIA</alias>
<alias>ASIJPCNEPOIWJPOIYO</alias>
</aliases>
</intellispec>
I've attached a sample pdf that is generated by my xslt; up top where it says "aka" two of the three aliases should follow on the same line. If I just do select="intellispec/aliases/alias" in the above for-each all three aliases print out as expected.
Thanks,
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
----------------------------------------------------------------------
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Feature Request
Posted by Brian Trezise <Br...@IntelliData.net>.
Thanks, that worked like a charm :)
~Brian
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Thursday, August 21, 2008 1:56 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Feature Request
JDOM 1.1 does already contain a JDOMSource:
http://www.jdom.org/docs/apidocs/org/jdom/transform/JDOMSource.html
So no need to extend FOP.
On 20.08.2008 23:25:15 J.Pietschmann wrote:
> Brian Trezise wrote:
> > This isn't critical but it would be nice to be able to directly use an
> > org.jdom.Document object as a source document for xml data
>
> You could build yourself a JDomSource, which creates a SAXSource
> wrapping a custom XMLReader implementation, then walks the JDom
> tree and emits SAX events to the ContentHandler set to your
> XMLReader implementation.
> I think I've seen JDOMSource code already, google for it and/or
> check the usual suspects (in particular the JBoss source).
>
> J.Pietschmann
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Feature Request
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
JDOM 1.1 does already contain a JDOMSource:
http://www.jdom.org/docs/apidocs/org/jdom/transform/JDOMSource.html
So no need to extend FOP.
On 20.08.2008 23:25:15 J.Pietschmann wrote:
> Brian Trezise wrote:
> > This isn't critical but it would be nice to be able to directly use an
> > org.jdom.Document object as a source document for xml data
>
> You could build yourself a JDomSource, which creates a SAXSource
> wrapping a custom XMLReader implementation, then walks the JDom
> tree and emits SAX events to the ContentHandler set to your
> XMLReader implementation.
> I think I've seen JDOMSource code already, google for it and/or
> check the usual suspects (in particular the JBoss source).
>
> J.Pietschmann
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Logging question
Posted by Brian Trezise <Br...@IntelliData.net>.
Ok. So investigating this I figured out that the logging automatically uses
log4j when it's available... But my default logging level was set to debug,
hence the millions of lines of log output. Lol. Long day researching what
turned out to be a far simpler problem than I imagined...
In any case, thanks for the help
~Brian
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
-----Original Message-----
From: Brian Trezise [mailto:Brian.Trezise@IntelliData.net]
Sent: Thursday, August 21, 2008 9:36 AM
To: fop-users@xmlgraphics.apache.org
Subject: RE: Logging question
Ok... We use Log4j logging on all of our systems, and I'm familiar with
configuring it within my applications; however I'm not sure how to tell FOP
to use it. Do I need to write a custom listener or something to that
effect?
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Thursday, August 21, 2008 2:04 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Logging question
I'm afraid, Joerg is on the wrong track here. "No route found!" is a
log message from the Dijkstra shortest-path algorithm implementation in
Apache XML Graphics Commons. It has nothing to do with DTD access on the
internet.
This whole thing is really about properly configuring the logging
environment:
http://xmlgraphics.apache.org/fop/0.95/embedding.html#basic-logging
So, how you configure it largely depends on the logging subsystem that
is used by Apache Commons Logging. It's a good idea to familiarize
yourself with:
http://commons.apache.org/logging/commons-logging-1.0.4/docs/guide.html
The easiest is probably to use java.util.logging. I've written a Wiki
page some time ago demonstrating the basics:
http://wiki.apache.org/xmlgraphics-fop/HowTo/SetupJDK14Logging
On 21.08.2008 00:15:57 J.Pietschmann wrote:
> Brian Trezise wrote:
> > Using FOP 0.95, I'm generating a single-page PDF document in a web
server,
> > and it's taking nigh on 20 seconds to generate. When I prototyped this
it
> > was running< 1 second. The only difference is that when I prototyped I
> > generated the Source object from a File, and on the webserver I'm
pulling it
> > from a runtime-generated org.jdom.Document that I converted to a
> > ByteArrayInputStream.
> >
> > I have a suspicion that a part of the problem is that for some reason
using
> > the ByteArrayStream as an input I'm getting thousands of lines in my log
> > file.
> Very unlikely.
>
> The problem is probably here:
> > 20 Aug 2008 15:46:58,937 - No route found!
>
> I suspect you include a DTD in your SVGs, FOP tries to
> load the DTD from the w3c web server, but a firewall or
> something blocks this, and FOP waits for the network stack
> timeout.
> You can check this if you can log in onto the server and
> try a ping or traceroute to www.w3.org.
>
> You can try the following solutions:
> - Write or get an EntityResolver which provides an empty DTD,
> or the SVG DTD from local storage (if you rely on the declaration
> of the xmlns:svg in the DTD), and set this on the XML parser you
> use for the SVGs. The details are somewhat gory but you should
> find them in the mail archives.
> - Remove the DOCTYPE from your SVGs (don't do this if you rely on
> the declaration of the xmlns:svg in the DTD)
> - Ask the network staff to unblock access to www.w3.org (not
> recommended)
>
> J.Pietschmann
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Logging question
Posted by Brian Trezise <Br...@IntelliData.net>.
Ok... We use Log4j logging on all of our systems, and I'm familiar with
configuring it within my applications; however I'm not sure how to tell FOP
to use it. Do I need to write a custom listener or something to that
effect?
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Thursday, August 21, 2008 2:04 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Logging question
I'm afraid, Joerg is on the wrong track here. "No route found!" is a
log message from the Dijkstra shortest-path algorithm implementation in
Apache XML Graphics Commons. It has nothing to do with DTD access on the
internet.
This whole thing is really about properly configuring the logging
environment:
http://xmlgraphics.apache.org/fop/0.95/embedding.html#basic-logging
So, how you configure it largely depends on the logging subsystem that
is used by Apache Commons Logging. It's a good idea to familiarize
yourself with:
http://commons.apache.org/logging/commons-logging-1.0.4/docs/guide.html
The easiest is probably to use java.util.logging. I've written a Wiki
page some time ago demonstrating the basics:
http://wiki.apache.org/xmlgraphics-fop/HowTo/SetupJDK14Logging
On 21.08.2008 00:15:57 J.Pietschmann wrote:
> Brian Trezise wrote:
> > Using FOP 0.95, I'm generating a single-page PDF document in a web
server,
> > and it's taking nigh on 20 seconds to generate. When I prototyped this
it
> > was running< 1 second. The only difference is that when I prototyped I
> > generated the Source object from a File, and on the webserver I'm
pulling it
> > from a runtime-generated org.jdom.Document that I converted to a
> > ByteArrayInputStream.
> >
> > I have a suspicion that a part of the problem is that for some reason
using
> > the ByteArrayStream as an input I'm getting thousands of lines in my log
> > file.
> Very unlikely.
>
> The problem is probably here:
> > 20 Aug 2008 15:46:58,937 - No route found!
>
> I suspect you include a DTD in your SVGs, FOP tries to
> load the DTD from the w3c web server, but a firewall or
> something blocks this, and FOP waits for the network stack
> timeout.
> You can check this if you can log in onto the server and
> try a ping or traceroute to www.w3.org.
>
> You can try the following solutions:
> - Write or get an EntityResolver which provides an empty DTD,
> or the SVG DTD from local storage (if you rely on the declaration
> of the xmlns:svg in the DTD), and set this on the XML parser you
> use for the SVGs. The details are somewhat gory but you should
> find them in the mail archives.
> - Remove the DOCTYPE from your SVGs (don't do this if you rely on
> the declaration of the xmlns:svg in the DTD)
> - Ask the network staff to unblock access to www.w3.org (not
> recommended)
>
> J.Pietschmann
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Logging question
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I'm afraid, Joerg is on the wrong track here. "No route found!" is a
log message from the Dijkstra shortest-path algorithm implementation in
Apache XML Graphics Commons. It has nothing to do with DTD access on the
internet.
This whole thing is really about properly configuring the logging
environment:
http://xmlgraphics.apache.org/fop/0.95/embedding.html#basic-logging
So, how you configure it largely depends on the logging subsystem that
is used by Apache Commons Logging. It's a good idea to familiarize
yourself with:
http://commons.apache.org/logging/commons-logging-1.0.4/docs/guide.html
The easiest is probably to use java.util.logging. I've written a Wiki
page some time ago demonstrating the basics:
http://wiki.apache.org/xmlgraphics-fop/HowTo/SetupJDK14Logging
On 21.08.2008 00:15:57 J.Pietschmann wrote:
> Brian Trezise wrote:
> > Using FOP 0.95, I'm generating a single-page PDF document in a web server,
> > and it's taking nigh on 20 seconds to generate. When I prototyped this it
> > was running< 1 second. The only difference is that when I prototyped I
> > generated the Source object from a File, and on the webserver I'm pulling it
> > from a runtime-generated org.jdom.Document that I converted to a
> > ByteArrayInputStream.
> >
> > I have a suspicion that a part of the problem is that for some reason using
> > the ByteArrayStream as an input I'm getting thousands of lines in my log
> > file.
> Very unlikely.
>
> The problem is probably here:
> > 20 Aug 2008 15:46:58,937 - No route found!
>
> I suspect you include a DTD in your SVGs, FOP tries to
> load the DTD from the w3c web server, but a firewall or
> something blocks this, and FOP waits for the network stack
> timeout.
> You can check this if you can log in onto the server and
> try a ping or traceroute to www.w3.org.
>
> You can try the following solutions:
> - Write or get an EntityResolver which provides an empty DTD,
> or the SVG DTD from local storage (if you rely on the declaration
> of the xmlns:svg in the DTD), and set this on the XML parser you
> use for the SVGs. The details are somewhat gory but you should
> find them in the mail archives.
> - Remove the DOCTYPE from your SVGs (don't do this if you rely on
> the declaration of the xmlns:svg in the DTD)
> - Ask the network staff to unblock access to www.w3.org (not
> recommended)
>
> J.Pietschmann
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Logging question
Posted by Brian Trezise <Br...@IntelliData.net>.
Pinging www.w3.org [128.30.52.53] with 32 bytes of data:
Reply from 128.30.52.53: bytes=32 time=68ms TTL=45
Reply from 128.30.52.53: bytes=32 time=70ms TTL=45
Reply from 128.30.52.53: bytes=32 time=68ms TTL=45
Reply from 128.30.52.53: bytes=32 time=67ms TTL=45
Ping statistics for 128.30.52.53:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 67ms, Maximum = 70ms, Average = 68ms
I work from a home office so network blocking is not a problem. Though when
we deploy this to our clients that is good to be aware of. Any other
suggestions? I attached my fop interface class to my previous email if that
helps
~Brian
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
-----Original Message-----
From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
Sent: Wednesday, August 20, 2008 4:16 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Logging question
Brian Trezise wrote:
> Using FOP 0.95, I'm generating a single-page PDF document in a web server,
> and it's taking nigh on 20 seconds to generate. When I prototyped this it
> was running< 1 second. The only difference is that when I prototyped I
> generated the Source object from a File, and on the webserver I'm pulling
it
> from a runtime-generated org.jdom.Document that I converted to a
> ByteArrayInputStream.
>
> I have a suspicion that a part of the problem is that for some reason
using
> the ByteArrayStream as an input I'm getting thousands of lines in my log
> file.
Very unlikely.
The problem is probably here:
> 20 Aug 2008 15:46:58,937 - No route found!
I suspect you include a DTD in your SVGs, FOP tries to
load the DTD from the w3c web server, but a firewall or
something blocks this, and FOP waits for the network stack
timeout.
You can check this if you can log in onto the server and
try a ping or traceroute to www.w3.org.
You can try the following solutions:
- Write or get an EntityResolver which provides an empty DTD,
or the SVG DTD from local storage (if you rely on the declaration
of the xmlns:svg in the DTD), and set this on the XML parser you
use for the SVGs. The details are somewhat gory but you should
find them in the mail archives.
- Remove the DOCTYPE from your SVGs (don't do this if you rely on
the declaration of the xmlns:svg in the DTD)
- Ask the network staff to unblock access to www.w3.org (not
recommended)
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Logging question
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Brian Trezise wrote:
> Using FOP 0.95, I'm generating a single-page PDF document in a web server,
> and it's taking nigh on 20 seconds to generate. When I prototyped this it
> was running< 1 second. The only difference is that when I prototyped I
> generated the Source object from a File, and on the webserver I'm pulling it
> from a runtime-generated org.jdom.Document that I converted to a
> ByteArrayInputStream.
>
> I have a suspicion that a part of the problem is that for some reason using
> the ByteArrayStream as an input I'm getting thousands of lines in my log
> file.
Very unlikely.
The problem is probably here:
> 20 Aug 2008 15:46:58,937 - No route found!
I suspect you include a DTD in your SVGs, FOP tries to
load the DTD from the w3c web server, but a firewall or
something blocks this, and FOP waits for the network stack
timeout.
You can check this if you can log in onto the server and
try a ping or traceroute to www.w3.org.
You can try the following solutions:
- Write or get an EntityResolver which provides an empty DTD,
or the SVG DTD from local storage (if you rely on the declaration
of the xmlns:svg in the DTD), and set this on the XML parser you
use for the SVGs. The details are somewhat gory but you should
find them in the mail archives.
- Remove the DOCTYPE from your SVGs (don't do this if you rely on
the declaration of the xmlns:svg in the DTD)
- Ask the network staff to unblock access to www.w3.org (not
recommended)
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Logging question
Posted by Brian Trezise <Br...@IntelliData.net>.
Using FOP 0.95, I'm generating a single-page PDF document in a web server,
and it's taking nigh on 20 seconds to generate. When I prototyped this it
was running < 1 second. The only difference is that when I prototyped I
generated the Source object from a File, and on the webserver I'm pulling it
from a runtime-generated org.jdom.Document that I converted to a
ByteArrayInputStream.
I have a suspicion that a part of the problem is that for some reason using
the ByteArrayStream as an input I'm getting thousands of lines in my log
file. No errors or anything, just stuff like the following:
20 Aug 2008 15:46:58,875 - Using PDFImageHandler:
org.apache.fop.render.pdf.PDFImageHandlerXML
20 Aug 2008 15:46:58,875 - userconfig is null
20 Aug 2008 15:46:58,875 - Generating SVG at 72.0dpi.
20 Aug 2008 15:46:58,875 - Generating SVG at 72.0dpi.
20 Aug 2008 15:46:58,875 - Generating SVG at 72.0dpi.
20 Aug 2008 15:46:58,937 - No ImageLoaderFactory found that can load this
format directly. Trying ImageConverters instead...
20 Aug 2008 15:46:58,937 - Lowest penalty: 2147483647
20 Aug 2008 15:46:58,937 - No route found!
20 Aug 2008 15:46:58,937 - No ImageLoaderFactory found that can load this
format directly. Trying ImageConverters instead...
20 Aug 2008 15:46:58,937 - Lowest penalty: 2147483647
20 Aug 2008 15:46:58,937 - No route found!
20 Aug 2008 15:46:58,937 - No ImageLoaderFactory found that can load this
format directly. Trying ImageConverters instead...
20 Aug 2008 15:46:58,937 - Lowest penalty: 10
20 Aug 2008 15:46:58,937 - Pipeline: Loader:
org.apache.fop.image.loader.batik.ImageLoaderSVG@e634bf Converters:
I have run the xml generator separately, saved the output as a .xml file,
and run it through as a StreamSource(File) and I get no log messages at all.
Is there a reason using a StreamSource(ByteArrayInputStream) as my source
would cause all the extra logging? And how can I control it/disable it?
Thanks,
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
Re: Feature Request
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Brian Trezise wrote:
> This isn't critical but it would be nice to be able to directly use an
> org.jdom.Document object as a source document for xml data
You could build yourself a JDomSource, which creates a SAXSource
wrapping a custom XMLReader implementation, then walks the JDom
tree and emits SAX events to the ContentHandler set to your
XMLReader implementation.
I think I've seen JDOMSource code already, google for it and/or
check the usual suspects (in particular the JBoss source).
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Feature Request
Posted by Brian Trezise <Br...@IntelliData.net>.
This isn't critical but it would be nice to be able to directly use an
org.jdom.Document object as a source document for xml data (Not for the XSL
transformation but for the actual xml). I'm generating XML at runtime and
feeding it to fop by means of an XMLOutputter, and then converting the
outputstream to an inputstream, then passing it to a StreamSource object.
The code isn't overly complicated but it would be cleaner if I could feed my
Document object directly to FOP.
(Incidentally if this feature already exists please let me know how to make
use of it) :)
Thanks,
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Use only a limited number of items in an xsl:for-each
Posted by Brian Trezise <Br...@IntelliData.net>.
I'm using the following to select a subset of items from my xml document to
be rendered to the pdf; however when I run fop on the xslt/xml, nothing is
rendered at all:
<xsl:for-each
select="//*[local-name()='intellispec/aliases/alias'][position() < 3]">
<xsl:value-of select="."/>
</xsl:for-each>
>From what I can tell this is valid xslt code, is there another way I need to
write this to be compatible with FOP 0.95? Or does FOP not support this
functionality and I need to limit the number of aliases elsewhere in my
software?
sample xml code:
<intellispec>
<aliases>
<alias>C0805C101J8GAC7800</alias>
<alias>IPUHPIOUSOPIHJPOIA</alias>
<alias>ASIJPCNEPOIWJPOIYO</alias>
</aliases>
</intellispec>
I've attached a sample pdf that is generated by my xslt; up top where it
says "aka" two of the three aliases should follow on the same line. If I
just do select="intellispec/aliases/alias" in the above for-each all three
aliases print out as expected.
Thanks,
___________________________________________________
Brian Trezise
Staff Software Engineer
IntelliData, Inc
22288 E Princeton Dr
aurora, colorado 80018
T: 720.524.4864
brian.trezise@intellidata.net
Re: Odd artifact in pdf from external svg image
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
There seems to be a rectangle (id="rect5546") which is painted in black
due to a style element on an ancestor element. Does not look like a
rendering bug to me.
BTW, don't trust Firefox to display every SVG correctly. It's not as
feature-complete as Batik. As to why Inkscape doesn't paint the black
rectangle I can only guess it has to do with the draft status of the SVG
1.2 spec.
On 13.08.2008 18:49:04 Brian Trezise wrote:
> I just ran across a strange rendering artifact (see attached screenshot) in
> my pdf that seems to be coming from the attached svg somehow, but I'm not
> sure of the cause. The xsl-fo didn't really give me much in the way of
> clues, but I attached it (test.xml) in case somebody thinks it can be more
> useful than I found it.
>
> About the svg: created in InkScape, and when viewed in
> inkscape/firefox/etc, the artifact is not present. Is this a rendering bug?
>
> ___________________________________________________
> Brian Trezise
> Staff Software Engineer
> IntelliData, Inc
> 22288 E Princeton Dr
> aurora, colorado 80018
> T: 720.524.4864
> brian.trezise@intellidata.net
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org