Re: Problems with embedding graphics using fo:instream-foreign-object and svg...
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 height=85mm
svg:image xlink:href={CompanyLogo/@src}
image-rendering=optimizeQuality
x=0 y=0 width=25mm height=35mm/
/svg:svg
/fo:instream-foreign-object
But I get the SVG-Error-Image. Before I updatet to the newest SVG-Version
that worked
fine... What has happend???
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Performance
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 18, 2001 12:29 AM To: [EMAIL PROTECTED] Subject: Performance I have performance problems with Fop on Linux for S390. The same document (for example 4 tables on one page) takes 3 seconds on Win NT, while it takes more than one minute on Linux. The same happens with examples which came with FOP - they are slow on Linux. What should I do? Thanks!!
Re: Table Layout with Page Breaks (re-visited)
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 number. This is assuming your page number is in the region-after area used by 'static-content flow-name=xsl-region-after'. simple-page-master name=pages region-before extent=Y.0in/ region-body margin-bottom=X.0in margin-top=Y.0in/ region-after extent=X.0in/ /simple-page-master Same with the region-before tag and margin-top attribute to keep it out of your header. Hope that helps/works. JohnPT fop-dev-return-10926-jthaemlitz=oreillyauto.com@XML. APACHE.ORG To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] 10/17/01 01:12 PM cc: Please respond to fop-dev Subject: Table Layout with Page Breaks (re-visited) I previously made a posting regarding this topic and received some helpful responses. However, I'm still having the problem. This time, I'll describe the problem in greater detail. I use FOP to dynamically create a table from database data. The resulting table can range from just a few rows to many rows, requiring multiple pages to display the table. The problem I'm having is that a multi-page table doesn't gracefully traverse the page boundaries. The table can continue past the page number to the very bottom of the page, with sometimes only half of the last row appearing on the first page, with the remaining table being displayed on the next page. I've tried keep-with-next, plus other attributes, but haven't had any success at resolving this issue. I've made sure that all table tags are nested under the xsl-region-body tag, as suggested by John T. Perhaps part of my problem is that the text in one of the columns is wrapped onto three lines, as the column width is not sufficient for all of the text to fit on one line. I'm thinking that perhaps FOP can't set up the page breaks properly as a result (which is simply a guess). I'm added some logic in my XSL file to end the table and start a new table every x number of rows (by using the mod() method). However, I need to be able to set the cell height for this to consistently work (as the number of rows in a cell could vary). I tried setting height from the row tag as well as from the cell tag, but the requested height is being ignored. I've been using version 0.19.0. Today, I'm going to try 0.20.1 to see if there is a difference. Any help or suggestion would be greatly appreciated Chris W. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Problems with embedding graphics using fo:instream-foreign-object and svg...
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 (E-Mail)
Subject: Problems with embedding graphics using
fo:instream-foreign-object and svg...
Hi Folks!
I wanted to embed images using:
fo:instream-foreign-object
svg:svg width=25mm height=85mm
svg:image xlink:href={CompanyLogo/@src}
image-rendering=optimizeQuality
x=0 y=0 width=25mm height=35mm/
/svg:svg
/fo:instream-foreign-object
But I get the SVG-Error-Image. Before I updatet to the newest SVG-Version
that worked
fine... What has happend???
Christian
__
DIRON Wirtschaftsinformatik GmbH Co. KG
Christian Beer ([EMAIL PROTECTED])
Daimlerweg 39-41Tel. : +49(251)979-200
48163 Muenster Fax : +49(251)979-2020
Germany Email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Problems with embedding graphics using fo:instream-foreign-object and svg...
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 [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 18, 2001 8:27 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Problems with embedding graphics using
fo:instream-foreign-object and svg...
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 (E-Mail)
Subject: Problems with embedding graphics using
fo:instream-foreign-object and svg...
Hi Folks!
I wanted to embed images using:
fo:instream-foreign-object
svg:svg width=25mm height=85mm
svg:image xlink:href={CompanyLogo/@src}
image-rendering=optimizeQuality
x=0 y=0 width=25mm height=35mm/
/svg:svg
/fo:instream-foreign-object
But I get the SVG-Error-Image. Before I updatet to the newest SVG-Version
that worked
fine... What has happend???
Christian
__
DIRON Wirtschaftsinformatik GmbH Co. KG
Christian Beer ([EMAIL PROTECTED])
Daimlerweg 39-41Tel. : +49(251)979-200
48163 Muenster Fax : +49(251)979-2020
Germany Email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Problems with embedding graphics using fo:instream-foreign-object and svg...
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 [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 18, 2001 9:36 AM
To: [EMAIL PROTECTED]
Subject: RE: Problems with embedding graphics using
fo:instream-foreign-object and svg...
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 [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 18, 2001 8:27 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Problems with embedding graphics using
fo:instream-foreign-object and svg...
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 (E-Mail)
Subject: Problems with embedding graphics using
fo:instream-foreign-object and svg...
Hi Folks!
I wanted to embed images using:
fo:instream-foreign-object
svg:svg width=25mm height=85mm
svg:image xlink:href={CompanyLogo/@src}
image-rendering=optimizeQuality
x=0 y=0 width=25mm height=35mm/
/svg:svg
/fo:instream-foreign-object
But I get the SVG-Error-Image. Before I updatet to the newest SVG-Version
that worked
fine... What has happend???
Christian
__
DIRON Wirtschaftsinformatik GmbH Co. KG
Christian Beer ([EMAIL PROTECTED])
Daimlerweg 39-41Tel. : +49(251)979-200
48163 Muenster Fax : +49(251)979-2020
Germany Email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[vote] Merging JFor with FOP
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 jfor developers, jfor users, FOP users and FO visibility in general to join forces. Bertrand, here attached, is the main developer behind the project and he already agreed on donating the code to the ASF. IMO, rather than creating another project, it would be best to merge jfor code with FOP to allow yet another (and widely used) binary format to render FO in. Technical details are not that important at the moment, but Bertrand already stated his flexibility in reshaping jfor code in order to make it easier/cleaner/more-manageable the merging. This said, in order for the donation to take place, I'm officially requesting a vote from the FOP developers community. The Apache XML PMC is already informed and will accept any position taken by the community. So, here it is, please vote on the following question: 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? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
overflow
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 PROTECTED]
DO NOT REPLY [Bug 4269] - space-end property is ignored silently in fo:inline
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. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4269 space-end property is ignored silently in fo:inline --- Additional Comments From [EMAIL PROTECTED] 2001-10-18 08:07 --- Created an attachment (id=695) The test case mentioned in the description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance
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 don't see the same degradation. I'm sure BEA support will figure out this problem in no time. To benchmark I used a servlet with embedded FOP to render a 200 page PDF document from an XSLT transform on a static XML-file (no database connection is involved). Both boxes are running Weblogic 6.1. The XSLT transform takes very little time compared to the FOP renderer. I've tried a DomSource for input, a SaxSource, and the XSLTInputHandler. The results are almost exactly the same in each case. Below are the results I see. Initial heap size=max heap size in each case. Each server is running the latest JDK 131 (w/Hotspot). (I have set all the HP system variables (max_thread_proc, etc.) to Sun recommendations.) Nt dev box (NT4-Worksatation, PIII-933mhz, 512MB ram): Heap Size=64M, 1 report = 251ms/page Heap Size=64M, 2 reports = 750ms/page Heap Size=256M, 1 report = 245ms/page Heap Size=256M, 2 reports = 500/page HP server (HP-Unix, 2x550 mhz, 2GB ram): Heap Size=64M, 1 report = 545ms/page (frequent out of memory errors) Heap Size=64M, 2 reports = didn't try Heap Size=256M, 1 report = 372ms/page Heap Size=256M, 2 reports = 1700ms/page Heap Size=512M, 1 report = 350ms/page Heap Size=512M, 2 reports = 1675ms/page The only difference I can see for sure between the two boxes is that the NT machine performs at least 10 times as much garbage collection. (Sometimes several times per page, as opposed to once every 8-10 pages on the NT box.) Garbage collection occurs a little more frequenly on the HP box when I lower the heap size, but still not nearly as often as on the NT--at any heap size. Also the HP box runs out of memory if I lower the heap size. I was hoping this was due to some HP setting, but I'm starting to come to the conclusion that it's just some difference in the hotspot implementations. Amit wrote: Yup I run it under Linux and it is actually way faster than windowsNT or 98. I have the latest kernel 2.4.12 and am using jdk1.2.2 with 128MB or RAM this is in my development environment. Jim Wright wrote: 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 18, 2001 12:29 AM To: [EMAIL PROTECTED] Subject: Performance I have performance problems with Fop on Linux for S390. The same document (for example 4 tables on one page) takes 3 seconds on Win NT, while it takes more than one minute on Linux. The same happens with examples which came with FOP - they are slow on Linux. What should I do? Thanks!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance
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 performance problems with Fop on Linux for S390. The same document (for example 4 tables on one page) takes 3 seconds on Win NT, while it takes more than one minute on Linux. The same happens with examples which came with FOP - they are slow on Linux. What should I do? Thanks!!
RE: [vote] Merging JFor with FOP
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]' Subject: RE: [vote] Merging JFor with FOP With proper care it is always possible to restructure the distribution so that unnecessary classes are not included. There are Ascii, PCL and PDF renderers in FOP - each can be in a separate jar file with no compile-time dependencies from the main jar, so if you don't use some format, drop the jar and be happy. Same applies to other included jars, like batik and logkit - they are not necessarily needed for everybody. Unfortunately, I don't have free time to volunteer to do this sort of decoupling of FOP subsystems, nor do I have a pressing need for it. My unofficial vote for merging JFor with FOP is: +1 YS -Original Message- From: Alistair Hopkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 11:46 AM To: [EMAIL PROTECTED] Subject: RE: [vote] Merging JFor with FOP Can I just appeal for some limitation on the size of the JAR files required? Not all java is server side and downloads sizes matter a lot! Alistair [still thinks Swing is a good idea] [but so is rtf] -Original Message- From: Beer, Christian [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 3:54 PM To: '[EMAIL PROTECTED]' Subject: AW: [vote] Merging JFor with FOP Although I am not a committer, I would like to give following unofficial vote: 1+; [...snip...] So, here it is, please vote on the following question: 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? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
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 contributions, occasioned by real life, I haven't lost any enthusiasm for FOP, and hope to get back on track. Certainly I've kept an eye on JFOR and I'm pleased to see that we have a chance to join that functionality with FOP...I think it can only help both existing communities. A big +1 from me...a code contribution of this nature merits committer status, IMHO, plus Bertrand has been active on this list in any case. And we can always use more committers. Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [vote] Merging JFor with FOP
-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 have. Yes combinune fop and jfor would make life easier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
+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 things go, but merging jfor and fop would solve several issues I currently have. Yes combinune fop and jfor would make life easier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
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 (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 jfor developers, jfor users, FOP users and FO visibility in general to join forces. Bertrand, here attached, is the main developer behind the project and he already agreed on donating the code to the ASF. IMO, rather than creating another project, it would be best to merge jfor code with FOP to allow yet another (and widely used) binary format to render FO in. Technical details are not that important at the moment, but Bertrand already stated his flexibility in reshaping jfor code in order to make it easier/cleaner/more-manageable the merging. This said, in order for the donation to take place, I'm officially requesting a vote from the FOP developers community. The Apache XML PMC is already informed and will accept any position taken by the community. So, here it is, please vote on the following question: 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? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Table Layout with Page Breaks (re-visited)
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 object in FOP where keep-together works. Also check the relation between the extent attribute on your before and after regions and top and bottom margins on your body region to make sure the body doesn't overlap the after region. HTH, Karen West, Chris wrote: I previously made a posting regarding this topic and received some helpful responses. However, I'm still having the problem. This time, I'll describe the problem in greater detail. I use FOP to dynamically create a table from database data. The resulting table can range from just a few rows to many rows, requiring multiple pages to display the table. The problem I'm having is that a multi-page table doesn't gracefully traverse the page boundaries. The table can continue past the page number to the very bottom of the page, with sometimes only half of the last row appearing on the first page, with the remaining table being displayed on the next page. I've tried keep-with-next, plus other attributes, but haven't had any success at resolving this issue. I've made sure that all table tags are nested under the xsl-region-body tag, as suggested by John T. Perhaps part of my problem is that the text in one of the columns is wrapped onto three lines, as the column width is not sufficient for all of the text to fit on one line. I'm thinking that perhaps FOP can't set up the page breaks properly as a result (which is simply a guess). I'm added some logic in my XSL file to end the table and start a new table every x number of rows (by using the mod() method). However, I need to be able to set the cell height for this to consistently work (as the number of rows in a cell could vary). I tried setting height from the row tag as well as from the cell tag, but the requested height is being ignored. I've been using version 0.19.0. Today, I'm going to try 0.20.1 to see if there is a difference. Any help or suggestion would be greatly appreciated Chris W. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
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 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 jfor developers, jfor users, FOP users and FO visibility in general > to join forces. > > Bertrand, here attached, is the main developer behind the project and he > already agreed on donating the code to the ASF. > > IMO, rather than creating another project, it would be best to merge > jfor code with FOP to allow yet another (and widely used) binary format > to render FO in. > Technical details are not that important at the moment, but Bertrand > already stated his flexibility in reshaping jfor code in order to make > it easier/cleaner/more-manageable the merging. > > This said, in order for the donation to take place, I'm officially > requesting a vote from the FOP developers community. The Apache XML PMC > is already informed and will accept any position taken by the community. > > So, here it is, please vote on the following question: > > 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? > > I remind that only people with committer status are entitled to place a > binding vote, but I suggest everybody on this list to express their vote > and, in case of negative vote, explain their reasons so that we can > properly deal with them. > > Thanks to all. > > Stefano. > > P.S. Sorry for the formality, people but this is legal stuff so I'm > required to wear my ASF member hat :) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] begin:vcard n:Cuevas;Emmanuel x-mozilla-html:FALSE org:Internet de Alta Calidad;Desarrollo adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Ingeniero x-mozilla-cpt:;0 fn:Emamnuel Cuevas end:vcard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: padding in table-row
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 padding-bottom to put some space between rows of a table. These attributes don't seem to be working in table-row, but the desired result can be achieved using padding in table-cell. I think this might be a bug and would just like to make whoever needs to know aware. Cheers Tim The information in this e-mail together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any form of review, disclosure, modification, distribution and/or publication of this e-mail message is prohibited. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: xalan version
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 you're seeing it. I'll try to look into it again. Regards, Karen Lease Guillaume Rousse wrote: Sorry if this has already been asked there, but list archive are currently unreachable. The current fop version (0.20.1) ships with xalan-j 2.0.0, and builds fine. Trying to build it with current xalan-j 2.2.D11 fails with those error messages: [xslt] org.apache.xml.utils.WrappedRuntimeException: /home/guillaume/tmp/Fop-0.20.1/foproperties.xml (Aucun fichier ou répertoire de ce type) [..] file:/home/guillaume/tmp/Fop-0.20.1/./build/src/codegen/genconst.xsl; Line 9; Column -1; Can not load requested doc: /home/guillaume/tmp/Fop-0.20.1/foproperties.xml (Aucun fichier ou répertoire de ce type) [xslt] org.apache.xml.utils.WrappedRuntimeException: /home/guillaume/tmp/Fop-0.20.1/foproperties.xml (Aucun fichier ou répertoire de ce type) [..] file:/home/guillaume/tmp/Fop-0.20.1/./build/src/codegen/genconst.xsl; Line 9; Column -1; Can not load requested doc: /home/guillaume/tmp/Fop-0.20.1/foproperties.xml (Aucun fichier ou répertoire de ce type) Is this a known error, and if so, is there a workaround ? Thanks -- Guillaume Rousse [EMAIL PROTECTED] GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
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 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 jfor developers, jfor users, FOP users and FO visibility in general to join forces. Bertrand, here attached, is the main developer behind the project and he already agreed on donating the code to the ASF. IMO, rather than creating another project, it would be best to merge jfor code with FOP to allow yet another (and widely used) binary format to render FO in. Technical details are not that important at the moment, but Bertrand already stated his flexibility in reshaping jfor code in order to make it easier/cleaner/more-manageable the merging. This said, in order for the donation to take place, I'm officially requesting a vote from the FOP developers community. The Apache XML PMC is already informed and will accept any position taken by the community. So, here it is, please vote on the following question: 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? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [vote] Merging JFor with FOP
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, for example (because jfor has much less to do - there's no magic here) and jfor attempts to preserve the structure of the document (a table is a table, a list is a list, etc.), which can cause some loss of presentation information (distances between elements, etc.) 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 the RTF generated if it loses presentation information? Of course hopefully when they are merged the whole will be greater than the sum of the parts. I do not know though. Assuming that the FOP architecture does not change significantly - my experience with the renderers is that they account for something like maybe 5 - 10 percent of the processing time (maybe less, don't have the numbers in front of me right now). Still I think that it is a good idea (especially for FOP users). Inexact presentation should not necessarily invalidate a renderer - after all - I am to blame for the TXTRenderer (talk about loss of presentation information). Just thought that I would mention it. Art -Original Message- From: Art Welch Sent: Thursday, October 18, 2001 4:44 PM To: '[EMAIL PROTECTED]' Subject: RE: [vote] Merging JFor with FOP Sounds like a good idea to me. The more renderers the better. +1 Art -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 8:58 AM To: FOP Cc: Bertrand Delacretaz Subject: [vote] Merging JFor with FOP 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 jfor developers, jfor users, FOP users and FO visibility in general to join forces. ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Antwort: page numbering problem...
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 (fo:page-number-citation ref-id =endofdoc/) can't work here as it does not let me declare the block with this name in every page sequence. Moreover is there any limitation with the maximum number of page sequences we can have in one document.? Is there any wayout Please help thanks wali Hi wali, I creat a PDF document which have reports for different customers. One document can contain many reports. Now I want to mark the pages for reports individually. i.e. ... Every new report starts at new page. and every report can consist of different number of pages. Create a page sequence for each report. If you are creating the FO via XSLT, and if you have the reports in individual XML elements (here called report), you can use something like xsl:template match=report fo:page-sequence master-name=report initial-page-number=1 fo:static-content flow-name=xsl-region-before xsl:textReport /xsl:text xsl:value-of select=title /fo:static-content fo:static-content flow-name=xsl-region-after fo:blockfo:leader leader-pattern=rule leader-length =max//fo:block fo:block text-align=endxsl:textPage /xsl:textfo:page-number//fo:block /fo:static-content fo:flow flow-name=xsl-region-body xsl:apply-templates/ /fo:flow /fo:page-sequence /xsl:template Tailor this to your needs. Of course you'll have to define a page master report (you may have different page masters for the title page, the TOC, appendices etc.) HTH Joerg Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
Strong Yes! __ For the latest news, go to http://www.asia1.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
latest version of FOP
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 PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
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 vote yes only if the merge does not adversely affect the already strained performance of FOP in both space and time. -- Weiqi Gao [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP (jfor speed/presentation)
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 the RTF generated if it loses presentation information? snip Thanks for putting this up - the thing with RTF is that there is a fairly strong similarity between XSL-FO and RTF constructs, that does not need any layout work in the FO-RTF transformation (we had a good discussion about this earlier this year on this list). The layout is done later by the wordprocessor when the RTF file is opened. Hence jfor being called an XSL-FO to RTF *converter* and not *formatter*. jfor does a fairly simple mapping of XSL-FO elements to RTF constructs, hence the speed and small code size. So, technically I think the initial merging might see jfor sharing only some infrastructure with FOP (command-line and Cocoon invocation mechanisms, configuration, logging, parser, etc.), with a -rtf option that would more or less switch between jfor and FOP for processing of the XSL-FO elements. This is of course going to be discussed with the FOP community, I'm only thinking outloud here. As Stefano rightly mentioned in the private discussion that lead to this merging proposal, such a side-by-side merging would already be a big advantage for *users* of FOP who would get RTF output for free, without needing separate downloads and configuration. Not to mention increased visibility for both projects. Later on, we will have to refactor the jfor code to use more of the the FOP codebase where it makes sense. This might lead to new interfaces between FOP and its renderers (post-processors?), where a renderer could be plugged in at an earlier stage of the FOP formatting chain, not necessarily after the layout stage. So, IMHO jfor would not be a FOP renderer per se initially, but might become one later in the integration process. -- -- Bertrand Delacrétaz, www.codeconsult.ch -- jfor.org lead developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
