You probably have a broken version of batik, it didn't handle relative
url's properly.
Current cvs has this fixed, you need both new fopand batik
On Thu, 18 Oct 2001 10:02:09 Beer, Christian wrote:
Hi Folks!
I wanted to embed images using:
fo:instream-foreign-object
svg:svg width=25mm
I run
complex table stuff on Linux with FOP pretty consistently, and have not
experienced the slow-downs you mention. Are you running under Linux with a
decent amount of memory?
jw
-Original
Message-
From: Alenka Skrbinek
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, October
I'm understanding your problem a little better now. This probably won't
solve all your problems, but be sure you have a margin-bottom attribute on
your region-body tag. If you make the margin-bottom the same as the extent
on your region-after it should keep it from printing over your page
Could somebody please point out what is the benefit of
using fo:instream-foreign-object...svg:image ...
instead of fo:external-graphic ... ?
Thanks,
YS
-Original Message-
From: Beer, Christian [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 18, 2001 4:02 AM
To: Fop-liste
We generate our PDFs on the fly dynamically. These PDFs include dynamically
generated graphs. It is vary convenient to embed the graphs (as SVG images)
inline rather then creating .svg files and then deleting them after
generating the PDFs.
Jim
-Original Message-
From: Shkuro, Yuri
Jim,
Your example is clear to me, but it's different from
Christian's case - he does embed external files, that's
why I was curious why do it via svg. Maybe his files
are svg, that would explain it. I though he meant GIFs
or something.
Yuri.
-Original Message-
From: Jim Urban
Hi people,
recently, some code was donated to the Apache Cocoon project in order to
connect it with JFor (www.jfor.org) which is a FO-RTF processor.
It appeared evident to me (and to others, as I discovered later) that
jfor and FOP are doing different things but could be an advantage for
both
Hi*,
how can I get an overflow=hidden or something similar in a fo:table-row?
I'm using the old Version 0.16.
Thanks,
Karin Thaens
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4269.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Just in case anyone is interested, see this benchmarking from an earlier
post. I still haven't figured out what causes the serious degradation on
Unix with two or more concurrent reports. But I did find out it only
occurs when running FOP on a servlet inside Weblogic! Two separate Java
processes
I had
better performance using IBM's jre/java as opposed to Sun's version - on
Linux.
Venu
Reddy
-Original Message-From: Alenka Skrbinek
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, October 17, 2001
10:29 PMTo: [EMAIL PROTECTED]Subject:
Performance
I have
With a little guidance, I will attempt some decoupling, especially from
Batik.
Any pointers? I've looked, and it seems fairly embroiled to me.
Alistair
-Original Message-
From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 18, 2001 5:30 PM
To: '[EMAIL PROTECTED]'
At 02:58 PM 10/18/01 +0200, Stefano Mazzocchi wrote:
would you like to accept jfor code and give Bertand Delacretaz committer
status in order to perform the merging on the FOP code following the
technical directions that the FOP dev community will find more
appropriate?
Despite my recent lack of
-Original Message-
From: Jim Wright [mailto:[EMAIL PROTECTED]]
Sent: donderdag 18 oktober 2001 21:06
To: [EMAIL PROTECTED]
Subject: RE: [vote] Merging JFor with FOP
I don't officially count as these things go, but merging jfor and
fop would
solve several issues I currently
+1
it would make JFOR and FOP richer
John Kattestaart (Freeler) wrote:
-Original Message-
From: Jim Wright [mailto:[EMAIL PROTECTED]]
Sent: donderdag 18 oktober 2001 21:06
To: [EMAIL PROTECTED]
Subject: RE: [vote] Merging JFor with FOP
I don't officially count as these
I think anything we can do to encourage the use of XSL-FO is a good
thing, especially now that XSL is finally a W3C Recommendation.
+1
Regards,
Karen Lease
Stefano Mazzocchi wrote:
Hi people,
recently, some code was donated to the Apache Cocoon project in order to
connect it with JFor
Hi Chris,
Yes, definitely try a more recent version. The latest is actually
0.20.2. That should have support for setting height on either row or
cell and maybe some sizing problems have been fixed. To prevent rows
being broken, use keep-together=always on the table-row object. That's
the only
I am not a comiter, but I had to deal with FOP once (versions 0.19
and 0.20) and it is very probable that I have to deal with JFor, and I
think this thing that is being proposed is a good one
+1
--
Emmanuel Cuevas
Senior Developer
[EMAIL PROTECTED]
Stefano Mazzocchi wrote:
>
> Hi
Well, no, actually the XSL Recommendantion says that padding doesn't
apply to table-row (See 6.7.9 and the Note about Common Border,
Padding and Background properties.
Using padding on table-cell is the correct solution.
Regards,
Karen
Keen Tim wrote:
I'm attempting to use padding-top and
That sounds kind of familiar.
A while back, FOP was failing with GUMP builds which use the CVS version
of xalan because of relative URLs in the document() function, for
example in genconst.xsl. At the time I made some changes in the Fop Xslt
task which fixed that problem. So I'm not sure why
I am not a committer but here is my unofficial vote:
+1
It's a great advantage for everyone.
Am Donnerstag, 18. Oktober 2001 14:58 schrieben Sie:
Hi people,
recently, some code was donated to the Apache Cocoon project in order to
connect it with JFor (www.jfor.org) which is a FO-RTF
OK, I did this backwards... Does not change my vote, but I just took a look
at the jfor site. I saw a couple of phrases that concerned me a bit. These
are:
jfor uses a simple mapping from XSL-FO to RTF without any layout
computations, which means that the conversion is much faster than with FOP,
thanx Joerg.
It worked ...
but one problem still persists. I actually wanted to display page 1 of
total pages. But in this case, I can't do it coz FOP does not allow to
declare a block with same id more than once in a document. So the known
method of getting the total page numbers
Strong Yes!
__
For the latest news, go to http://www.asia1.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
hi,
I'm using FOP-0.20.1 now, and I'm get the news that there is a latest
version of FOP from the mailing list, so where can I get this latest
version of FOP?
thanks.
best rgds,
ektan
-
To unsubscribe, e-mail: [EMAIL
On Thu, 2001-10-18 at 15:42, Enrico Schnepel wrote:
I am not a committer but here is my unofficial vote:
+1
It's a great advantage for everyone.
I'm not a committer. I'm just a user of FOP. I haven't heard of jfor
before today.
I urge FOP committers to examine the proposal to merge and
On Thursday 18 October 2001 23:06, Art Welch wrote:
snip
My concerns are that if jfor excels at speed at the expense of
presentation.
1. Are jfor users going to be happy with jfor integrated with FOP
which seems to favor presentation over speed?
2. Would FOP users be happy with
27 matches
Mail list logo
