Medhi and Glenn thanks for your quick replies and especially for immediately
taking care of this. I investigated it a little further by creating a proof of
concept font caching implementation so that we can measure the benefits. After
this, it does not seem to me like too much work - it could be
Thank you for your quick replies.
There is a filed bug :
https://issues.apache.org/bugzilla/show_bug.cgi?id=53148
The problem is resolved.
Στις 24 Απριλίου 2012 10:06 π.μ., ο χρήστης mehdi houshmand <
med1...@gmail.com> έγραψε:
> Hi,
>
> I'll address your concerns inline:
>
> 2012/4/24 Αναστάσ
Hi,
I'll address your concerns inline:
2012/4/24 Αναστάσιος Χαρούλης
> Hello,
>
> We are using Apache FOP 1.0 to create Postscript documents from xml files.
> After upgrading the Java Virtual Machine from 1.6 update 18 to 1.6 update 19,
> we noticed important performance degradation. The FOP
please file one ore more bugs at [1], product "Fop", and please ensure the
following are attached to each bug:
- a "maximally minimal" input FO files that demonstrates problem
- an output file (PDF, AFP, etc.,) relevant to running your input file
- console log output
- version informat
@xmlgraphics.apache.org
Subject: RE: Fop performance
Hi There,
I had much the same problem myself. I needed to create PDFs quickly for
the web but also Postscript for high-volume laser printers. It was
taking seven seconds to run Saxon, run FOP and get the PDF/PS. This was
way too slow for my application
On 29.06.2007 11:57:37 Jason Timmins wrote:
> I'd like to use the native Java version of FOP but how can I make it run
> really quickly for lots of small PDFs?
You can deploy FOP as a WebService or as a servlet in an application
server.
I once did a proof-of-concept implementation where I depl
Hi There,
I had much the same problem myself. I needed to create PDFs quickly for the
web but also Postscript for high-volume laser printers. It was taking seven
seconds to run Saxon, run FOP and get the PDF/PS. This was way too slow for
my application.
To be fair, FOP is pretty quick, the
I've seen a similar behaviour back in my FOP 0.20.5 times. But in the
end I concatenated the documents on the PostScript level, not on the FO
level.
However, if your stack trace is any indicator, the problem is inside
Xalan-J (no FOP classes involved in the stack trace). Maybe it has to
build up a
Yeah, this is definitely 0.20.5 specific.
On Nov 11, 2005, at 21:11, Michael Dabney wrote:
Hi Michael,
> I have done just that: http://wiki.apache.org/xmlgraphics-fop/HowTo/
> PHPJavaBridge
>
> I linked to it on the front page as well.
Thanks a lot for taking the time to do this!
May need som
On Nov 11, 2005, at 21:11, Michael Dabney wrote:
Hi Michael,
I have done just that: http://wiki.apache.org/xmlgraphics-fop/HowTo/
PHPJavaBridge
I linked to it on the front page as well.
Thanks a lot for taking the time to do this!
May need some minor tweaks to make it relevant for FOP Trun
I have done just that:
http://wiki.apache.org/xmlgraphics-fop/HowTo/PHPJavaBridge
I linked to it on the front page as well.
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Fri 11/11/2005 5:04 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: FOP Performance
remias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 11, 2005 11:26 AM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: FOP Performance
>
> Batik takes a long time to warm up due to its size (class loading). If
> you use the servlet approach, i.e. having FOP up, r
users@xmlgraphics.apache.org
Subject: Re: FOP Performance
Batik takes a long time to warm up due to its size (class loading). If
you use the servlet approach, i.e. having FOP up, running and ready the
whole time, it will speed up the process a lot. If you find another way
to hold FOP and the VM it runs in m
Batik takes a long time to warm up due to its size (class loading). If
you use the servlet approach, i.e. having FOP up, running and ready the
whole time, it will speed up the process a lot. If you find another way
to hold FOP and the VM it runs in memory over multiple rendering
runs(some PHP exten
Hi again!
The Performance problem figured out to be a problem in using SVG images
as Backgorund images for the xsl-region-before/after/start/end.
Any ideas on how to fix this problem without changing to another picture
format. (jpg and gif do look bad imho)
Thanks and best regards,
Christian
-
> Yes we use PHP? Why?
FWIW, we also have an intranet PDF solution with embedded FOP, but we
are using an architecture based on how FopServlet does it. We are
consistently getting render times around 8s for a 4-5 page PDF using
InputStreams (in contrast to Files, as FopServlet does it).
I am not
On Nov 10, 2005, at 14:22, Christian Loock wrote:
Hi,
I've set up an application using FOP 0.20.5 to generate dynamic PDF
Contents...
Using it on our development Server works very finde and fast but the
same app on an other Server seems to be much slower...
Well, for starters: development se
Hi Christian
What scripting language are you using? Not PHP by any chance?
Thanks.
Jimmy.
Christian Loock wrote:
Hi Everybody,
I've set up an application using FOP 0.20.5 to generate dynamic PDF
Contents...
Using it on our development Server works very finde and fast but the
same app on an
Hi,
is there a different Hardware? Or is the java version (memorysettings)
different?
Thanks
Dirk
Christian Loock wrote:
Hi Everybody,
I've set up an application using FOP 0.20.5 to generate dynamic PDF
Contents...
Using it on our development Server works very finde and fast but the
same
19 matches
Mail list logo
