Yes, I tried the trunk and it works for me now, too.
Original-Nachricht
Datum: Mon, 16 Oct 2006 08:03:56 +0200
Von: Peter [EMAIL PROTECTED]
An: fop-users@xmlgraphics.apache.org
Betreff: RE: OutOfMemoryError with Hello World and multicolumn
Still works for me (FOP Trunk, Windows
Manuel Mall wrote:
Sorry, but your example does not make sense to me. You provide HTML not
XSL:FO. Can you provide the exact fo file you feed into fop so we can
better understand your issue?
My apologies. I thought it'd be clearer that way. Here's a snippet:
fo:block line-height=313%
I guess it was the bugfix for long block texts that got fixed after
0.92beta that made this go away. However, the exception should have been
a ArrayIndexOutOfBoundsException. Shrug.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39414
On 16.10.2006 09:46:06 Johannes Künsebeck wrote:
Yes, I
Have you searched into the mailing list archives for oc4j? We've had
quite a few issues with Oracle's JAXP support. It's important that you
replace the JAXP implementation (parser + xslt) correctly using the
endorsed standards override mechanism:
On Monday 16 October 2006 21:15, Abel Braaksma wrote:
Manuel Mall wrote:
Sorry, but your example does not make sense to me. You provide HTML
not XSL:FO. Can you provide the exact fo file you feed into fop so
we can better understand your issue?
My apologies. I thought it'd be clearer that
Manuel Mall wrote:
If I remove the line-height=313% from the fo:block it seems to do
exactly what you want, that is each line get the minimum necessary
height to render it.
This is precisely what I want to happen. Hmm, I'll make a full test,
leaving out as much as possible, and if it
Richard,
this has neither to do with Barcode4J nor with FOP. If you look at the
stacktrace Barcode4J and FOP are nowhere in sight. Furthermore, support
for Barcode4J is at http://sourceforge.net/mail/?group_id=96670. I just
happen to be here, too. :-)
To me, this looks like a simple class loader
Hi Richard,
That sounds like an incompatibility between xalan bsf jars, and occurs
if you use some script in your XSLT.
I've yet got this.
With Xalan 2.7.0, you should use bsf 2.3.0 (and js 1.5r3, if needed).
HTH,
Pascal
-Original Message-
From: Richard King [mailto:[EMAIL
Thanks Jeremias,
Have already tried that but will experiment a little more.
Cheers,
Richard
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: 16 October 2006 15:48
To: fop-users@xmlgraphics.apache.org
Subject: Re: Barcodes in fop 0.92 - BSF
Richard,
this has
Thanks Pascal,
I'll try that also, appreciate the help.
P.S. I do have script in my xslt but only have a problem when trying to
generate and display a barcode.
I'll play around and see what happens. :)
Cheers,
Richard
-Original Message-
From: Pascal Sancho [mailto:[EMAIL PROTECTED]
On 16.10.2006 14:26:51 Onur Senturk wrote:
hi, i'm trying to use fop with oc4j but i think the xml parsers are
conflicting. when i try to use xerces, the application doesn't start. When i
use the xml parser of the oc4j, i cannot make fop work.
what should i do? does anyone have an idea? thanks.
Downloaded BSF 2.3.0 and all is now fine. Thank you very much, Jerimias and
Pascal, for all your help.
Cheers,
Richard
-Original Message-
From: Pascal Sancho [mailto:[EMAIL PROTECTED]
Sent: 16 October 2006 15:49
To: fop-users@xmlgraphics.apache.org
Subject: RE: Barcodes in fop 0.92 -
Hi all,
Has anyone benchmarked the performance of FOP 0.92 when embedding fonts
versus not embedding fonts? I just started doing this with the DejaVu
fonts in order to get some more Unicode glyphs and it seems a lot slower.
I could quantify this further if you think that's necessary.
I need to
Abel Braaksma wrote:
Manuel Mall wrote:
If I remove the line-height=313% from the fo:block it seems to do
exactly what you want, that is each line get the minimum necessary
height to render it.
This is precisely what I want to happen. Hmm, I'll make a full test,
leaving out as much as
On Tuesday 17 October 2006 08:32, Abel Braaksma wrote:
Abel Braaksma wrote:
Manuel Mall wrote:
If I remove the line-height=313% from the fo:block it seems to
do exactly what you want, that is each line get the minimum
necessary height to render it.
This is precisely what I want to
Title: RE: Is embedding fonts significantly slower?
Yes, I also tried it with Unicode fonts, and it takes a lot longer to generate the file. It seems like embedding fonts in general is a slow process.
melih
-Original Message-
From: news [mailto:[EMAIL PROTECTED]] On Behalf Of
16 matches
Mail list logo
