Re: Using Avalon/Logkit
Hey Jeremias, Jeremias Maerki wrote: Right, I think we agree here. Cool. I'm exactly proposing this. I suggest you really have a look at Avalon. Avalon is very far from being another large library. Avalon Framework is 46K, LogKit is about 52K. Is that large? Okay, my two large libraries remark was off-centre, but you really need to consider those who, for whatever reason, simply *can't* use Avalon. The reasons may be technical, political or otherwise, but if FOP forces people to use Avalon, then you will end up having people who won't use FOP because of it. I'd love to have the time to get to know Avalon, but I just don't. In addition, the there is no way the particular project here at work I want to embed FOP in is going to use Avalon. Period. If the dependency on Avalon can't be broken, then there's very little chance FOP will be used for this project. Which I'll find very dissapointing, because I'm a big fan of FOP. org.apache.avalon.framework.logger.Logger is almost exactly what you did in your proposal, except that you introduce yet another API, Okay, in it's defence, the LoggingHandler API is very small, being one interface large. The LogkitLoggingHandler class provides a transparent wrapper for using Logkit and Avalon with FOP. For existing applications, such as the command line app, it took (IIRC) one extra line and changing three others to use the LoggingHandler mechanism, and it still uses Logkit for the logging. If you want to use your own logger, then just wrap it in a LogkitLoggingHandler and away you go. The amount of additional work required to use the new interface is absolutely minimal, and it will still work with Avalon, most likely by changing one single line of code or configuration. We're talking about reusing mature code. And that sometimes means we have one more jar to include. I'm not talking about throwing it all away - you can still use all of that existing code if you want. And sometimes one more jar is one too many. I'm disappointed that you're shooting against something you don't know. I'll be the first to admit that I'm not familiar with Avalon, but I do know I can't use it every project, even if I had the time to learn about it, and I also know that if you start making core FOP functionality depend on external services such as Avalon, a lot of embedders will go elsewehre. Seems like we agree here. What I don't understand is how you can agree with using something like ErrorHandler but be against using a LoggingHandler, which works *precisely* in the same way. It's the *exact* same mechanism, but for logging. If it still works with Avalon and Logkit, and works for embedders, how can you lose from such a win-win situation? Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: merging two libraries
Keiron Liddle writes: That sounds like a good suggestion. To start with I think we should consider only this: FOP behaves exactly the same but instead of having its own pdf generation code then iText is used as a library to generate pdf. So the questions are: - is the license useable I did a little search and I found people saying that MPL is compatible with the Apache license and others saying it isn't. My main concern is that I don't want a license that allows my employer to prevent me from distributing the code I write at my work for free. I don't know if the Apache License is strict enough to ensure me that. - is the api sufficient for FOP to use I don't know, but we can always fill the gaps. kind regards, Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: userconfig.xml
--cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So, then would that be JAVA_HOME? When I checked user.dir, i got c:\winnt\= system32. On Tue, Mar 12, 2002 at 08:55:22AM +0100, Beer, Christian wrote: Yeah. If I try File file =3D new File(userconfig.xml), where=20 is it looking relative to the class file requesting the file? =20 No, he is looking relative to the path you started java from. =20 Greets,=20 Christian =20 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --=20 David B. Bitton [EMAIL PROTECTED] Diversa ab illis virtute valemus. --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8jnY7MNOMzNRRk50RAqc/AKCz/pMMwvbecfU0Ptx5kwpuFEACHQCfWlN+ kddSonvUQEmcYSz1lYfCrhc= =LLT3 -END PGP SIGNATURE- --cvVnyQ+4j833TQvp--
FOP Chinese characters in PDF
hello, I'm trying to generate a PDF document containing Chinese characters with FOP v0.20.3. The result PDF fail to show chinese character but show something like #32456; instead. I learnt from newsgroup that there should be some mapping (PDFCMap?) to overcome this, but I cannot figure out the use of this. (Moreover I found in the program source that most PDFCMap-relating-codes are remarked out). I'd be grateful if you can provide me with some hints on the issue. Thanks a lot. cheers George -- Åwªï¨Ï¥ÎHongKong.com¶l¥ó¨t²Î Thank you for using hongkong.com Email system - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Newbie question: master-reference
Hi, sorry for asking such a basic question, but why does this fo code not work??? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master page-width=8.5in page-height=11in master-name=toto fo:region-body margin-top=15mm margin-right=20mm margin-bottom=15mm margin-left=20mm/ fo:region-before extent=13mm display-align=after/ fo:region-after extent=13mm display-align=before/ /fo:simple-page-master fo:simple-page-master page-width=8.5in page-height=11in master-name=CoverPage fo:region-body margin-top=15mm margin-right=20mm margin-bottom=15mm margin-left=20mm/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-name=toto I get this error with FOP 0.20.3 [ERROR]: 'master-reference' for 'fo:page-sequence'matches no 'simple-page-master' or 'page-sequence-master' What did I miss? Thanks. Bruno Verachten. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: merging two libraries
From: [EMAIL PROTECTED] Keiron Liddle writes: That sounds like a good suggestion. To start with I think we should consider only this: FOP behaves exactly the same but instead of having its own pdf generation code then iText is used as a library to generate pdf. So the questions are: - is the license useable I did a little search and I found people saying that MPL is compatible with the Apache license and others saying it isn't. My main concern is that I don't want a license that allows my employer to prevent me from distributing the code I write at my work for free. I don't know if the Apache License is strict enough to ensure me that. The Apache licen(c|s)e makes the code available for any use as long as due credit is given. No reference is given to availability of the source code of the modifications. If you modify Apache licen(c|s)e code, you can keep the modifications for yourself, as long as you give due credit. If the code is to ask to become an Apache project, the source code *must* be Apache licen(c|s)e 1.1. If not, it can be still used by FOP as a jar if the licen(c|s)e permits its distribution with Apache software-code. - is the api sufficient for FOP to use I don't know, but we can always fill the gaps. :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: merging two libraries
Bruno : whatever license iText gets, if you sign a non-disclosure with your employer, he can withhold you from publishing whatever you get to know or do during working hours, if he expects it of being of strategic importance to him. Apart from that : keep an eye on different legal copyright approach between continental Europe and Anglo-saxon countries (read UK/US). In Belgium and other EU countries in principle you're the de facto owner of anything you create, even during working hours. Often employers then try to agree on a transfer of exploitation rights, but that must be stated explicitely in your contract...and doesn't give them intellectual property rights. Though they can still ask you to sign a non-disclosure. Kind of dull and boring, but definitely of importance to anyone writing/publishing code I'm afraid ... Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: woensdag 13 maart 2002 8:45 To: alex Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: merging two libraries alex writes: I think however it would require a significant software change which I am not qualified to estimate. Those more familiar with the FOP source code can evaluate that. I am now working on 'Styles' and 'default fonts', so that you can tell some iText object 'please apply this style'. Once this is finished, I will take a look at FOP. So the questions are: - is the license useable - is the api sufficient for FOP to use A look at Sourceforge tells us that the licenCes (bloody Americans can't spell English words) are License: GNU Lesser General Public License (LGPL), Mozilla Public License 1.1 If Bruno is still the copyright holder then he can presumably simply add an Apache-style licence. I don't feel comfortable using the LGPL for this and don't know about the Mozilla license. Now I can't even find the exact text of these on the sourceforge site but I know they must be somewhere. I suppose I could always just download the software since the licences will be in the software package, no? You don't need to download the complete package, the licen[c|s]es are on my site: http://www.lowagie.com/iText/lgpl.txt http://www.lowagie.com/iText/MPL-1.1.txt You can find my motivation for using these libraries here: http://www.lowagie.com/iText/faq.html#lgpl If Apache is compatible with MPL, I can indeed add it. But as I stated before: I am going to work in the private sector again soon (for the moment I work for the government). I didn't like some non-disclosure clausules in my contract at my new company, but I signed it because I feel protected by the MPL: if they ask me to write extra functionality for iText, the MPL has priority over my contract (if they'll disagree, I'll quit). I fear that if iText gets an Apache licen[c|s]e, my new company will be able to prevent my from distributing all improvements. kind regards, Bruno - 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: Using Avalon/Logkit
Joe Batt wrote: Given the above is true, you could use something as simple as printlns to s global print writer. In debug mode it would go to the bit bucket. OK, I've used log4j, so I understand you may want something a little more substantial than that, but why does the user care to integrate FOP debugging into a larger logging structure? I agree with all of your other points - I think you state the purpose of logging very clearly. However, for this point, my answer is: yes, the user does care, because: 1. If a solution is deployed at a user's site and the user observes problems, he or she wants to be able to reproduce the problems with logging turned on, because then the log file can be sent to the creator of the solution, whether that's a company or an open source initiative. 2. If a solution consists of multiple building blocks like FOP, and the user wants to turn on logging for the reason outlined under 1., then it's preferable that all building blocks share the same logging mechanism. Nevertheless, I have another point about user-side logging that matches your points nicely: However much I like logging (I actually prefer logging and staring into source code over using debuggers), I have one general problem with logging in the production code. Quite a number of developers seem to misunderstand logging as a replacement for careful and thorough error handling and recovery. In my opinion, logging (in production code) is always only a diagnostic enhancement of error handling - not a replacement. BTW: Yes, I do prefer log output over no error handling at all. 8-) Arnd Beissner -- Arnd Beißner IT-Engineering Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917
Re: Using Avalon/Logkit
Joe
So you would be one of the users who will be simply using some kind of /dev/null
logger (like org.apache.avalon.framework.logger.NullLogger). What we're
discussing here will enable you to just do that: Switch of logging
messages if you don't want them.
(I am a user of FOP, not an active developer of FOP, but I do develop
apps that use FOP.)
I've been watching the discussion of logging within FOP rage for at
least 6 months now. It seems pointless to me.
Logging within FOP is for debugging FOP. It doesn't need to integrate
with anything. As a user of FOP, I want it to be silent, just like my
JDBC driver is silent, just like my AWT layer is silent, just like my
messaging driver is silent. As a developer of FOP, I want logging to
debug the FOP code.
Given the above is true, you could use something as simple as printlns
to s global print writer. In debug mode it would go to the bit bucket.
OK, I've used log4j, so I understand you may want something a little
more substantial than that, but why does the user care to integrate FOP
debugging into a larger logging structure?
For example to log any warnings should there be any problems later with
the printouts.
So far, any logging in FOP has been a problem for me. It fills my logs,
and in the old version of FOP I am using, I can't turn it off without a
recompile.
So you're still stuck with MessageHandler. You could do something in
your code (just an example):
boolean enableFOPLogging = System.getProperty(fop.log).equals(true);
if (enableFOPLogging) {
MessageHandler.setOutputMethod(MessageHandler.SCREEN);
} else {
MessageHandler.setOutputMethod(MessageHandler.NONE);
}
That way you don't have to recompile.
Cheers,
Jeremias Märki
mailto:[EMAIL PROTECTED]
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: merging two libraries
alex writes: I think however it would require a significant software change which I am not qualified to estimate. Those more familiar with the FOP source code can evaluate that. I am now working on 'Styles' and 'default fonts', so that you can tell some iText object 'please apply this style'. Once this is finished, I will take a look at FOP. So the questions are: - is the license useable - is the api sufficient for FOP to use A look at Sourceforge tells us that the licenCes (bloody Americans can't spell English words) are License: GNU Lesser General Public License (LGPL), Mozilla Public License 1.1 If Bruno is still the copyright holder then he can presumably simply add an Apache-style licence. I don't feel comfortable using the LGPL for this and don't know about the Mozilla license. Now I can't even find the exact text of these on the sourceforge site but I know they must be somewhere. I suppose I could always just download the software since the licences will be in the software package, no? You don't need to download the complete package, the licen[c|s]es are on my site: http://www.lowagie.com/iText/lgpl.txt http://www.lowagie.com/iText/MPL-1.1.txt You can find my motivation for using these libraries here: http://www.lowagie.com/iText/faq.html#lgpl If Apache is compatible with MPL, I can indeed add it. But as I stated before: I am going to work in the private sector again soon (for the moment I work for the government). I didn't like some non-disclosure clausules in my contract at my new company, but I signed it because I feel protected by the MPL: if they ask me to write extra functionality for iText, the MPL has priority over my contract (if they'll disagree, I'll quit). I fear that if iText gets an Apache licen[c|s]e, my new company will be able to prevent my from distributing all improvements. kind regards, Bruno - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Fop 0.20.3 released
Raimund Kammering wrote: Hi, in the announcement for the fop 0.20.3 release there was a note about EPS images. I am not sure what this means: a.) Now you can also use EPS images in the FOP - PDF process b.) FOP can now produce an EPS file as output For the announcement I just copied some stuff from CHANGES: (I really shouldn't write announcements that late..) -Add support for EPS images in PostScript renderer and limited EPS support in PDF Renderer (Tore Engvig) I don't know what limited means here, maybe Tore can comment. A simple include by fo:external-graphic src=myepsfile.eps width=400px scaling=uniform display-align=center/ (just the way as it is done with JPEG) dose not work. I got an error message like: --snip-- [INFO]: [2] [ERROR]: Batik not in class path [ERROR]: Error while creating area : No ImageReader for this type of image (myepsfile.eps) --snip-- What am I doing wrong (by the way batik IS definitely in my classpath)? Or is there no support for input of EPS images - meaning b.) was right? Hmm, the error message with Batik seems to be wrong, I'll have a look a this. Any comments and tips are very wellcome! Maybe there is a epstosvg converter? Or we could add support for PDF graphics, I've succsessfully used epstopdf and PDFTeX some time ago. Raimund Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Using Avalon/Logkit
On 2002.03.13 12:25 Joe Batt wrote: Logging within FOP is for debugging FOP. It doesn't need to integrate with anything. As a user of FOP, I want it to be silent, just like my JDBC driver is silent, just like my AWT layer is silent, just like my messaging driver is silent. As a developer of FOP, I want logging to debug the FOP code. I disagree. You may want it silent but users do need error messages. It also may need to be associated with a context and thread and placed in order with other messages. Messages such as if the document could not be rendered due to some error in the fo or missing images etc. It is obvious that no matter what solution is used then someone will complain. The real culprit is Sun for not putting logging in much ealier. So what solution can we use that satisfies most people, is flexible and requires minimum code to maintain. The solution I keep coming up with is the avalon logging interface. Now can we get back to what FOP is about, if I remember correctly something about formatting xsl:fo :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FW: Missing source package FOP
Not acked... Pier -- Forwarded Message From: MARTIN Franck [EMAIL PROTECTED] Date: Wed, 13 Mar 2002 12:04:53 +0100 To: [EMAIL PROTECTED] Subject: Missing source package FOP Hello, The package org/apache/fop/fo/properties is missing from the fop source downloadable file. Just so you know that developpers can't contribute much in those circumstances. Franck MARTIN -- End of Forwarded Message - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: SV: Newbie question: master-reference
Klosa Uwe wrote: Hi Bruno, you have to change fo:page-sequence master-name=toto to fo:page-sequence master-reference=toto Regards OOooopsss. Thanks a lot for that answer to that basic question ;-) I'll be back with a more interesting question! ;-) Later, Bruno Verachten, France. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Missing source package FOP
This package is generated during build by some XSLT transformations based on XML files in src/codegen. The files can be found in build/src after build. Have a look at build.xml! Not acked... Pier -- Forwarded Message From: MARTIN Franck [EMAIL PROTECTED] Date: Wed, 13 Mar 2002 12:04:53 +0100 To: [EMAIL PROTECTED] Subject: Missing source package FOP Hello, The package org/apache/fop/fo/properties is missing from the fop source downloadable file. Just so you know that developpers can't contribute much in those circumstances. Franck MARTIN -- End of Forwarded Message Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
from-nearest-specified-value on compounds
Fops and others, What's the opinion on whether an assignment to a compound qualifies for from-nearest-specified-value() on one of the components? My attitude would be that it does qualify because of the implicit assignment to the component. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
svg content not compiling
I have complied an xml file with an xsl file containing svg content on my windows mechine and it works fine... but when i compile the same files on my linux mechine with the same distribution of fop (0.20.3) it crashes: Exception in thread "main" java.lang.NoClassDefFoundError at org.apache.fop.svg.SVGElement.init(SVGElement.java:197) at org.apache.fop.svg.SVGElement.init(SVGElement.java:84) It seems to be the classpath issue involving batik.jar. I have all of the needed .jar files located in JAVA_HOME/jre/lib/ext/. What else do i need to tryin order tosolve this problem. I also need to solve this for tomcat (FopServlet runs fine as long as there is no svg elements) Thanks,
Re: svg content not compiling
try to set the classes in the lib dir of your webapp in tomcat root dir. because every jarfile that is in the lib dir should be found... i know it's not much but i hope it helps... Jochen Jochen Maes EDP departement Programmeur KBC-Securities Havenlaan 16 1080 Brussel Tel : 02/429.96.81 Fax : 02/429.17.48 E-mail : [EMAIL PROTECTED] ** This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. KBC Securities reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: svg content not compiling
i have them there also in the... CATALINA_HOME/lib/ - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 13, 2002 9:17 AM Subject: Re: svg content not compiling try to set the classes in the lib dir of your webapp in tomcat root dir. because every jarfile that is in the lib dir should be found... i know it's not much but i hope it helps... Jochen Jochen Maes EDP departement Programmeur KBC-Securities Havenlaan 16 1080 Brussel Tel : 02/429.96.81 Fax : 02/429.17.48 E-mail : [EMAIL PROTECTED] ** This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. KBC Securities reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. ** - 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: svg content not compiling
no sorry iu think i didn't explain it right set them here /your webapp/WEB-INF/lib/ dir... that is the root dir for your servlet... try it and reboot the tomcat server it should work then (this is how i do it) Jochen Maes EDP departement Programmeur KBC-Securities Havenlaan 16 1080 Brussel Tel : 02/429.96.81 Fax : 02/429.17.48 E-mail : [EMAIL PROTECTED] ** This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. KBC Securities reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: svg content not compiling
i have them placed there also...
I have placed the .jar files in all three locations
JAVA_HOME/ljre/lib/
CATALINA_HOME/lib/
CATALINA_HOME/webapps/{my folder}/WEB-INF/lib/
When i use the list.fo file that is found in fop/docs/ with the FopServlet
it works fine... but when i use an xsl file with svg elements with an xml
file it gives me a blank pdf screen...
When i tried to step back and compiled from the command line. I have an svg
error.
I hope this helps you understand my issue better
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 13, 2002 9:34 AM
Subject: Re: svg content not compiling
no sorry iu think i didn't explain it right set them here
/your webapp/WEB-INF/lib/ dir...
that is the root dir for your servlet...
try it and reboot the tomcat server it should work then (this is how i do
it)
Jochen Maes
EDP departement
Programmeur
KBC-Securities
Havenlaan 16
1080 Brussel
Tel : 02/429.96.81
Fax : 02/429.17.48
E-mail : [EMAIL PROTECTED]
**
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. You must not,
directly or indirectly, use, disclose, distribute, print, or copy any part
of this message if you are not the intended recipient. KBC Securities
reserves the right to monitor all e-mail communications through its
networks. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorised to state them to be the views of any such entity.
**
-
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: distribute the PDF file
thank you! Arved. Do you need the ASF license to commercially distribute PDFs made using FOPs? If yes, what and where can I get any information of this license? ps. I'm not interested in distributing the FOP itself. - Original Message - From: "Arved Sandstrom" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 11, 2002 8:31 PM Subject: RE: distribute the PDF file The license is the ASF license. It is at the top-level of the FOP distribution. Not only can you commercially distribute the PDFs, you can commercially distribute FOP if you wish. Or build a product around it and commercially distribute that. Just keep the license handy. Regards, Arved Sandstrom -Original Message- From: Yuko Nakayama [mailto:[EMAIL PROTECTED]] Sent: March 11, 2002 7:20 AM To: [EMAIL PROTECTED] Subject: distribute the PDF file Hello. Is it possible to distribute the PDF file made from FOP for the commercial purpose? Description of a license was not able to be found even if referred to Web.. 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: svg content not compiling
Not sure if this is related, but do you have any AWT support on your Linux box? On an iSeries or AS/400 system I have to run a version of X-windows and a package that supplies native AWT support. I believe that the PJA package works on Linux systems. You can find out more about PJA at: http://www.eteks.com/pja/en/ David Morris [EMAIL PROTECTED] 03/13/02 08:16AM I have complied an xml file with an xsl file containing svg content on my windows mechine and it works fine... but when i compile the same files on my linux mechine with the same distribution of fop (0.20.3) it crashes: Exception in thread main java.lang.NoClassDefFoundError at org.apache.fop.svg.SVGElement.init(SVGElement.java:197) at org.apache.fop.svg.SVGElement.init(SVGElement.java:84) It seems to be the classpath issue involving batik.jar. I have all of the needed .jar files located in JAVA_HOME/jre/lib/ext/. What else do i need to try in order to solve this problem. I also need to solve this for tomcat (FopServlet runs fine as long as there is no svg elements) Thanks, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
Given what has been said on the mailing lists of FOP and iText, and given the current scope of the two projects, I feel reasonably sure that this could be a proposal accepted by bot communities. - FOP uses iText as a PDF generation library - This could have greater benefits than a merger and keep intact the strenghts that these two projects have (remember AOL+Time Warner? is the result we want?). iText could continue to be an excellent PDF (and RTF AFAIK) generation package with a good java API. FOP could concentrate on FO2AreaTree and use iText as the last step. Given the licences, nobody is prohibited to cross-collaborate. iText developers can send patches to FOP and viceversa, and be [VOTE]d as usual when the time is right. FOP can distribute iText jar as it's MPL, and both projects would cross-link in a clear way. AFAIK iText is already able to produce PDF using an XML file. If FOP could make a transformation step from FO to this format, we could get this up running in a short time. And IText can also output to html, which is not bad at all. What do you think? Shall we pull this off? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
I'm wondering if marying FOP +iText would sacrifice the -awt -print -ps options. (Same question for -text, but i'm personally not interested in that.) At 10:58 AM 3/13/02, you wrote: Given what has been said on the mailing lists of FOP and iText, and given the current scope of the two projects, I feel reasonably sure that this could be a proposal accepted by bot communities. - FOP uses iText as a PDF generation library - This could have greater benefits than a merger and keep intact the strenghts that these two projects have (remember AOL+Time Warner? is the result we want?). iText could continue to be an excellent PDF (and RTF AFAIK) generation package with a good java API. FOP could concentrate on FO2AreaTree and use iText as the last step. Given the licences, nobody is prohibited to cross-collaborate. iText developers can send patches to FOP and viceversa, and be [VOTE]d as usual when the time is right. FOP can distribute iText jar as it's MPL, and both projects would cross-link in a clear way. AFAIK iText is already able to produce PDF using an XML file. If FOP could make a transformation step from FO to this format, we could get this up running in a short time. And IText can also output to html, which is not bad at all. What do you think? Shall we pull this off? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)
Nicola Ken Barozzi wrote: Given the licences, nobody is prohibited to cross-collaborate. iText developers can send patches to FOP and viceversa, and be [VOTE]d as usual when the time is right. FOP can distribute iText jar as it's MPL, and both projects would cross-link in a clear way. Advance warning: I didn't follow possible discussions on the iText list regarding this issue. IF the integration FOP-iText is done in a way where PDF output via iText is not just an option but a replacement for the existing PDF output - or even for the other renderers, too, then I'd say this step contradicts the intention though not the letters of the Apache license. Why? If FOP - under Apache license - can no longer be used for essential purposes without using an additional component (iText) under MPL or LGPL, then in effect FOP is no longer Apache licensed, though technically speaking it still is. This would reduce the usefulness of FOP for a (unknown, agreed) number of users while enhancing the usefulness for others (not license-concerned users). My personal favourite would be a FOP renderer implementation that makes use of iText. Then, time could tell whether there are enough people interested in keeping Apache-licensed PDF output alive. If the decision goes toward a full replacement, I'd say that at least all existing FOP committers and possibly the major contributors to FOP should agree to this step as it - in one respect - decreases the value of their work so far. Arnd Beissner -- Arnd Beißner IT-Engineering Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917
Re: Using Avalon/Logkit
Sigh, this is getting long, please bear with me here. Jeremias Maerki wrote: Ok, let's look at it that way: With your reasoning people who *can't* use Avalon *can't* use Cocoon, for example. But Cocoon only uses Avalon internally. Err, as an application framework unto itself, I would have thought Cocoon would be the basis for building an application, not just something you'd pull in because you need to do some XML processing. In any case, if someone really could not use Avalon, and Cocoon exposed non-Avalon interfaces, then there would be no problem. The problem with FOP at the moment is *there is no non-Avalon interface*. To be clear, I'm not talking about developing an application, I'm talking about embedding FOP into an existing framework which already has it's own logging, configuration and management services. What I want to say is the following: FOP users don't necessarily have to fiddle with Avalon since we can provide non-avalon interfaces for the outside world. Users don't, but embedders do. I know because I just tried. Right now, no such non-Avalon interfaces exist. My proposal provides that non-Avalon interface for logging. Actually, your proposal and mine are exactly the same except that I'd like to use existing code. You introduce more FOP-specific stuff that we have to maintain and support. Yep, and I still maintain that the once-off amounts of additional code (tiny) and the effort to maintain it (tiny, if any) is far offset by the benfit to emedders (great). Actually, the amount of maintanence potentially goes *down*. When the Avalon interfaces inevitably change (which they already have: did you know that Loggable is deprecated?), at the moment you'll need to go through all of the FOP code and make those changes. Using an interface to it like LoggingHandler, you change one classs: the Logkit handler. When we introduce your logging idea (It's a good one I just happen to think there's a better one) we start something like that again. No, to my mind it is a different story - although if LoggingHandlers appeard in FOP for other logging mechanisms, such as 1.4's, it would be the same story. As I said before, I'm all for code reuse. By all means, use Batik for rendering SVG, use Excalibur's URIResolver, but of FOP is going to be widely used by embedders, you want to keep the amount of additional work required to embedd it down to a bare minimum. The LogkitLoggingHandler class provides a transparent wrapper for using Logkit and Avalon with FOP. Avalon is no logger. It has logger facilities exactly for the same reason that we need one for FOP. So why don't we use Avalon's? I didn't mean to imply it was - I was saying that the LogkitLoggingHandler can be used as a Avalon Loggable object - i.e., one that can do some logging, so it still fits nicely into the Avalon framework. That would mean LoggingHandler wraps Avalon's Logger interface which in turns wraps Logkit, Log4J, JDK14Logger etc. No benefit here, I think. No, LoggkitLoggingHandler wraps Avalon's Logger, and implements the LoggingHandler interface. The benefit is to embedders who don't want to use Avalon - they provide their own implementation of LoggingHandler. I wouldn't trade in code reuse for a reduced number of jars. When this is really a problem you can always repack jars, so fop.jar, for example, includes the things needed from Avalon. (as I already said). But I'm *not talking about less code reuse*. It's *not* the number of jars that is the problem - it's the additional amount of code that a developer must be familiar with to effectively use, develop against, debug and support. Because Avalon's Logger interface is almost exactly the same as yours. And because we don't have to reinvent the wheel. No, I defined an interface to a logging mechanism. Logkit *is* a logging mechanism. There's a *huge*, *massive* difference here. I can't emphasize that enough. Granted, we (may) have one more jar (avalon-framework.jar) but when we want to use Avalon some more (Caching, URI Resolving etc) we have to include it anyway (ok, probabaly another one: avalon-excalibur.jar). And FOP can concentrate on layout Right, but embedders don't have to care about how FOP resolves a URI, or does it's caching, it's all internal, and as long it is kept purely internal, it does *not* matter. It's the external interfaces to FOP that embedders care about. For FOP to be used by developers, it *must* not impose undue constraints on them. Pigoenholing them into using a particular framework or forcing them to write translation layers from that framework to theirs *is* an undue constraint, regardless of how you attempt to justify it. Take Mozilla for example. Moz uses some outstanding technologies, XPCOM, Gecko, Necko, libpr0n, XUL, XBL, Spidermonkey, etc, etc, etc. People use Moz for browsing the web, and they indirectly benefit from all of these technologies. Developers also
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: mergingtwo libraries)
Nicola, I think there are a few issues to be considered here. Essentially, what is FOP? There may be a number of requirements of an XSL-FO processor. The basic one is, Show me this on a page or screen. Any kind of renderer, using any approach whatsoever, will achieve this, more or less. The so-called structure renderers, like the rtf and mif renderers, do this with a useful side-effect; the file they produce can be not only viewed, but edited. It seems to me that what you are proposing is to use iText as a basic structure renderer, mapping the fo structures into iText-compatible structures. With all of the structure renderers, however, you are at the mercy of the individual layout engines. Anyone who has tried to produce a complex document using two versions of MS-Word will have an acute understanding of what it means to be at the mercy of someone else's renderer. The spec itself defines a layout engine in the production of the area tree from the fo tree. Admittedly, there are a number of grey areas in layout, especially when constraints conflict, in which the final decision is up to the User Agent. Effectively, it's up to the implementation. The area tree, though, defines the position of every mark on every page. It inherently holds out the prospect of producing identical layouts from every renderer downstream of the area tree. I was initially skeptical about this, because of the dependency of the layout on the font characteristics. It was pointed out to me, though, that as long as a renderer honoured the metrics of the design font then, even if individual glyphs were considerably different, the *layout* would still be identical down ot the position of individual glyphs on a page. It seems to me that that is what a full implementation of the spec implies, and that such a search for consistency in the position of marks on page or screen is one of the most desirable features of the spec. What may not be achievable across different implementations, we may still seek to achieve within a single implementation. With that in mind, we can probably conclude that a true structure renderer cannot achieve this cross-renderer consistency. That wouls also be true of iText, used in such a way. If however, the interface to iText were defined such that the position and size of al marks to be put on the page could be rigorously determined, it could meet the requirement. I, for one, would like to see such a precise and relatively low-level pdf library. Peter Nicola Ken Barozzi wrote: Given what has been said on the mailing lists of FOP and iText, and given the current scope of the two projects, I feel reasonably sure that this could be a proposal accepted by bot communities. - FOP uses iText as a PDF generation library - This could have greater benefits than a merger and keep intact the strenghts that these two projects have (remember AOL+Time Warner? is the result we want?). iText could continue to be an excellent PDF (and RTF AFAIK) generation package with a good java API. FOP could concentrate on FO2AreaTree and use iText as the last step. Given the licences, nobody is prohibited to cross-collaborate. iText developers can send patches to FOP and viceversa, and be [VOTE]d as usual when the time is right. FOP can distribute iText jar as it's MPL, and both projects would cross-link in a clear way. AFAIK iText is already able to produce PDF using an XML file. If FOP could make a transformation step from FO to this format, we could get this up running in a short time. And IText can also output to html, which is not bad at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote: . . . - FOP uses iText as a PDF generation library - . . . Maybe the following scenario could help making FOP more pipeline-oriented, making it easier to plug in various renderers, layout engines, debugging tools, etc. I'm just making up component names, hopefully understandable 1. FopParser parses and validates the input XSL-FO document 2. FopPropertyResolver does its job, attributes inheritance, etc. Then two options: 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout and produces PDF 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the XSL-FO vocabulary but with all attributes explicity specified (as far as possible, I know there are some issues here). After 3b, various XSLT transforms and/or XML-to-something converters can be plugged in using the well-defined and loosely-coupled SAX/XML interface. I think using XML/SAX to interface between future pipeline components (ParsingAndPropertyResolving - Layout - Serialization) opens up much more options than using java APIs for this, and could help keep FOP small and focused. If using Cocoon, being able to just resolve properties and pass the result on to various transforms opens up new horizons for XSL-FO processing. At the other end of the pipeline, what about an XML-to-MIF converter, for example, much more generally useful than a tightly-coupled MIF renderer for FOP. Implementing 3b should be fairly easy (isn't that a serialization of the FOTree?), and we can go from here to reuse important parts of FOP as individual components. How does this sound? -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Using Avalon/Logkit
Hi Michael Sigh, this is getting long, please bear with me here. It doesn't make so much sense go on a lot further, but to make things clear about Avalon and LogKit, I think I have to explain something about Avalon: There's LogKit, a logging facility, similar to Log4J for example. It has a class named org.apache.log.Logger which FOP currently uses for logging. As has nothing to do with Avalon except that it came out from that project. LogKit does not use Avalon. And then, there's org.apache.avalon.framework.logger.Loggable, an interface (yes, I know it's deprecated) defining a contract on how to provide logging for a component/object (not how to log per se). The reason it's deprecated is that it's bound to LogKit. Now, there's org.apache.avalon.framework.logger.LogEnabled which replaces Loggable. It defines the same contract as Loggable except that it's bound to the org.apache.avalon.framework.logger.Logger interface (which corresponds to your LoggingHandler). Most probably FOP will just shift from using org.apache.log.Logger to org.apache.avalon.framework.logger.Logger. This will remove logkit.jar and add the somewhat smaller avalon-framework.jar. As a aside to your previous mail: I agree with most of what you said. But I think you have some fears because you know too little of Avalon. I hope the above clears some of this. And I guarantee you that the Avalon solution will in no way get more difficult than your proposal. We just want to use a tiny part from Avalon where logging is concerned and an embedder will not have to learn the Avalon way if he doesn't want to. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
From: Peter B. West [EMAIL PROTECTED] Nicola, I think there are a few issues to be considered here. Essentially, what is FOP? Good point. There may be a number of requirements of an XSL-FO processor. The basic one is, Show me this on a page or screen. Any kind of renderer, using any approach whatsoever, will achieve this, more or less. The so-called structure renderers, like the rtf and mif renderers, do this with a useful side-effect; the file they produce can be not only viewed, but edited. It seems to me that what you are proposing is to use iText as a basic structure renderer, mapping the fo structures into iText-compatible structures. As a start, yes. With all of the structure renderers, however, you are at the mercy of the individual layout engines. Anyone who has tried to produce a complex document using two versions of MS-Word will have an acute understanding of what it means to be at the mercy of someone else's renderer. I think the POI team (http://jakarta.apache.org/poi/) would have something to say about this, but it would not be appreciation for the MS file formats ;-) The spec itself defines a layout engine in the production of the area tree from the fo tree. Admittedly, there are a number of grey areas in layout, especially when constraints conflict, in which the final decision is up to the User Agent. Effectively, it's up to the implementation. The area tree, though, defines the position of every mark on every page. It inherently holds out the prospect of producing identical layouts from every renderer downstream of the area tree. This implies AFAIK that the creation of the area tree is the crucial point, the pivotal scope of FOP. I was initially skeptical about this, because of the dependency of the layout on the font characteristics. It was pointed out to me, though, that as long as a renderer honoured the metrics of the design font then, even if individual glyphs were considerably different, the *layout* would still be identical down ot the position of individual glyphs on a page. It seems to me that that is what a full implementation of the spec implies, and that such a search for consistency in the position of marks on page or screen is one of the most desirable features of the spec. What may not be achievable across different implementations, we may still seek to achieve within a single implementation. Yes. With that in mind, we can probably conclude that a true structure renderer cannot achieve this cross-renderer consistency. And this is taken in account for in the spec as you know, which defines many tags as optional and hints on how to downgrade gracefully. That would also be true of iText, used in such a way. If however, the interface to iText were defined such that the position and size of al marks to be put on the page could be rigorously determined, it could meet the requirement. I, for one, would like to see such a precise and relatively low-level pdf library. In the proposal, the hint to active collaboration is there to achieve this synergy. Itext can give FOP a boost in rendering, and the FOP community can give iText greater precision in rendering. The iText community has shown IMO sincere quest for an active collaboration, and even donation of the code to FOP. As both communities pointed out correctly, just merging two project usually doesn't make a bigger project, but a bigger mess. So it seems that this thing can start :-) There is no need for a VOTE, since plain discussion and sharing of views is free, of course. Although I'm subscribed to this mailing list for quite some time now, I didn't really understand the status of the works that are going on to get to FOP2 or whatever you are going to call it. AFAIK, changing codebase requires a notice of this, a branch in CVS (no vote is necessary), and a final VOTE if the codebase is to switch. This is how Tomcat, Xalan, Xerces and many other projects did it, and how the priject guidelines advise. (http://xml.apache.org/source.html) What's the current status? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Using Avalon/Logkit
On 2002.03.14 08:29 Michael Gratton wrote: If I write a patch to move FOP over to Avalon's Logger, will that patch get comitted? Or is someone already working on it? Is there a schedule for this? If you submit a patch for this it will be committed before you know it! No-one else has mentioned working on it so go ahead. It will probably need to be done on both branches but do whatever you want to. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
From: Bertrand Delacretaz [EMAIL PROTECTED] On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote: . . . - FOP uses iText as a PDF generation library - . . . Maybe the following scenario could help making FOP more pipeline-oriented, making it easier to plug in various renderers, layout engines, debugging tools, etc. I'm just making up component names, hopefully understandable 1. FopParser parses and validates the input XSL-FO document Not needed if using Cocoon as a pipeline. 2. FopPropertyResolver does its job, attributes inheritance, etc. Then two options: 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout and produces PDF 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the XSL-FO vocabulary but with all attributes explicity specified (as far as possible, I know there are some issues here). 3b After 3b, various XSLT transforms and/or XML-to-something converters can be plugged in using the well-defined and loosely-coupled SAX/XML interface. I think using XML/SAX to interface between future pipeline components (ParsingAndPropertyResolving - Layout - Serialization) opens up much more options than using java APIs for this, and could help keep FOP small and focused. If using Cocoon, being able to just resolve properties and pass the result on to various transforms opens up new horizons for XSL-FO processing. This is the proposal I made, and I think it stands even stronger now. If FOP is pipeline driven, any renderer can be quite easily plugged in. AFAIK, the pipeline architecture is one of the major design differences that in some way has been agreed on. What I would like to see, is that FOP stops discussing about the logging, resolving, pipelineing and stuff and starts to focus on the core functionality. IMHO, the best way to get this thing going *quick* is to use Cocoon as a pipeline. Cocoon gives you all these features, and gives you a solid framework to work on. When it works on Cocoon, we can see if performance for stand-alone processing is good enough. If not, we can *then* talk about the structure around FOP, and break eventually free from Cocoon. At the other end of the pipeline, what about an XML-to-MIF converter, for example, much more generally useful than a tightly-coupled MIF renderer for FOP. Implementing 3b should be fairly easy (isn't that a serialization of the FOTree?), and we can go from here to reuse important parts of FOP as individual components. I agree. This can big opportunity also for other projects to collaborate in the rendering. JFor, for example (I don't remember who maintains it ;-P) And POI. At POI, we are going to do a Word .doc format writer. It could fit easily in this picture. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Using Avalon/Logkit
Keiron Liddle wrote: If you submit a patch for this it will be committed before you know it! Excellent! No-one else has mentioned working on it so go ahead. It will probably need to be done on both branches but do whatever you want to. Right, I'll get onto it, then. Jeremias mentioned LogEnabled is replacing Loggable, is there any concensus about moving Driver over to the new interface, making it implement both, or just leaving it as-is for now? I'd suggest moving it over, if not, then implementing both. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
