Re: move Ant task to Ant project ( was Contribution - anttask)
On Thu, 10 Jul 2003, M. Sean Gilligan [EMAIL PROTECTED] wrote: Putting the Fop task directly in Ant would be great. I would really like to see that happen. I suppose we could get it in Ant 1.6 if we submit it soon. Does anyone know what the criteria is for inclusion as a Core or Optional task within Ant? What work would be required on our part? Actually, it is not too likely to get accepted at all (I'm an Ant committer and PMC member, but I'm just speaking for myself here - some of it still is speculation). Over the past months (no, years) we've spent a lot of time maintaining optional tasks and fixing bugs in them, more time than we spent on improving Ant itself. As a consequence you'll find a big reluctance with Ant developers to accept any new tasks at all. In particular if the new tasks relies on a third-party tool/library that is an open source project itself. We'd probably send you back to FOP. Not having followed the discussion leading up to this, why would you want to ship it with Ant rather than FOP? Currently we are adding the infrastructure for something we call Ant libraries. Self contained jars that you need to put into ANT_HOME/lib (to be defined) and all tasks/data-types contained within will get discovered by Ant on startup. This will make deploying third party tasks even easier than it is now. First parts of this will be available in 1.6. It's pretty likely that we'll even break up our current set of tasks in the future and ship Ant with only a minimal amount of tasks - the rest will go into separately maintained and separately released Ant libaries. Some more comments. I assume that if we targeted Ant 1.6, we would use the 0.20.x code base. If it wants to be in Ant 1.6, it must not rely on any unreleased code. So if Ant 1.6 was released tomorrow, any FOP task in Ant would have to work with 0.20.5rc3a - any unreleased dependency like CVS HEAD is completely out of question. I don't know how it is done for other Ant tasks with external dependencies, but I suppose the Ant task would check to see if org.apache.fops.apps.Driver is on the classpath before preceding. Currently Ant simply tries to load all task classes (in 1.5.x at startup in 1.6 this will get delayed until you try to use the task). If there a dependency on org.apache.fops.apps.Driver in the task and the class is not available, Ant will catch the NoClassdefFoundError and simply proceed, making the task unavailable. If you then try to run the task, your build will fail - at the point where you try to run the task. taskdef is different than the tasks that ship with Ant in that it will cause the build to fail immediately when the class cannot be loaded. It also means that the Driver interface (or some other interface?) would have to be frozen. Which seems a very good argument to keep the task with FOP, IMHO. You'd adapt the task to the interface as necessary and people will always have a working combination of FOP and the task. Otherwise you'd end up with documentation that says this task requires FOP 0.20.4 or later, but won't work with 1.0. The but won't work with 1.0 part is rather difficult to add after a release of the task. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PDFWArray.java NullPointerException
Fopdevs, Has anyone else had problems compiling PDFWArray.java in fop.pdf under Eclipse? In a previous incarnation, I was getting persistent NullPointerExceptions at Line 0 when attempting to build. I couldn't see what the problem was, so I did a clean checkout and it built cleanly. After my last update, I have the problem back again. It seems like a coding problem, but the file compiles under Ant, outside Eclipse. Any ideas? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Naming of jars in lib
Fopdevs, It might make life a little easier if library jars retained common names as we upgraded; ant.jar, for instance. We have a many version-numbered jars in lib, the most particular of which is commons-io-dev-20030703.jar. As we are all getting our libraries updated through CVS anyway, would it not be better to name them consistently, and include a text file detailing the current versions? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Henrik Olsson/IRD/Intentia is out of the office.
I will be out of the office starting 2003-07-11 and will not return until 2003-08-11. I am on vacation, I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Naming of jars in lib
As we are all getting our libraries updated through CVS anyway, would it not be better to name them consistently, and include a text file detailing the current versions? Peter -- I don't think so--it is helpful to immediately see the version of the libraries when viewing the files. I suspect that text file you're mentioning will out fall out of date--and users may be unaware of it. However, there *may* be an issue (I don't know, I haven't researched the matter) of the team not relying on production releases of other jars, but interim releases where unwarranted, nightly builds, etc., which I would assume would make a mess in CVS due to the different file names, constant atticking, etc. *That* might be something to work on: attempting to rely on more production-release jars in the future. Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Naming of jars in lib
On 7/11/2003 6:49 AM, Glen Mazza wrote: I don't think so--it is helpful to immediately see the version of the libraries when viewing the files. I suspect that text file you're mentioning will out fall out of date--and users may be unaware of it. I should preface this with: I've used CVS to submit *1* change, so I'm not exactly an expert here... ;-p but... Is it not possible to display the 'modified date' and/or 'version' in a separate column in CVS? I thought that was what 'Rev.' was for... I guess the 'Timestamp' relates to the time the item was added to the library, and not necessarily the file's 'modification date'. Hope this helps in some way... However, there *may* be an issue (I don't know, I haven't researched the matter) of the team not relying on production releases of other jars, but interim releases where unwarranted, nightly builds, etc., which I would assume would make a mess in CVS due to the different file names, constant atticking, etc. *That* might be something to work on: attempting to rely on more production-release jars in the future. ...sounds messy... Don't forget to wash your hands afterwards... -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Just a stupid question ... =P
Hello guys @ fop-dev !Firstable, congratulation for your work on the fop API, we are using it here for 6 monthes now and it is a real success from the user point of view !!!I work for a french TV Channel (so excuse my english) and we use FOP to generate catalogs of our programs. Until right now, we had no memory problem because we generated catalog of 300~400 pages on a 1Go RAM server.But we hav to generate a big catalog (more than 1 000 pages) and FOP throws a OutOfMemoryException after 700~800 pages (depends on the number of images integrated). So here's come the first stupid question : is there a way to make FOP swap on hard drive for big document generation (we don't care about the time it takes to generate our catalogs), if not, can you explain me why ? Do you know if XEP can swap on drive ?And here's my second question, if the first response is "no", do you think we will be able to generate our monstruously big catalog if we add 2Go RAM on our server ?Thanks forward for you responses, and congratulations again.Symon
cvs commit: xml-fop/src/documentation/content/xdocs configuration.xml faq.xml fo.xml
vmote 2003/07/11 12:01:54
Modified:src/documentation/content/xdocs configuration.xml faq.xml
fo.xml
Log:
1. add section about external resources in fo.xml
2. update the faq regarding external resources to point to this new section
3. update configuration.xml to include additional information about the default
baseDir (which information was formerly in the faq).
Revision ChangesPath
1.14 +2 -2 xml-fop/src/documentation/content/xdocs/configuration.xml
Index: configuration.xml
===
RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/configuration.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- configuration.xml 10 Jul 2003 18:33:16 - 1.13
+++ configuration.xml 11 Jul 2003 19:01:54 - 1.14
@@ -45,7 +45,7 @@
tr
tdbaseDir/td
tdURL/td
-tddirectory containing the input FO file/td
+tdFor command-line, the directory containing the input FO or XML file.
For embedded, the current working directory./td
/tr
tr
tdfontBaseDir/td
@@ -53,7 +53,7 @@
tdvalue of baseDir/td
/tr
tr
-tdhyphenation-dir/td
+tdlink href=#hyphenation-dirhyphenation-dir/link/td
tdURL/td
tdNone. This is for custom hyphenation patterns./td
/tr
1.36 +1 -16 xml-fop/src/documentation/content/xdocs/faq.xml
Index: faq.xml
===
RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/faq.xml,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- faq.xml 21 Jun 2003 14:41:08 - 1.35
+++ faq.xml 11 Jul 2003 19:01:54 - 1.36
@@ -309,22 +309,7 @@
faq id=cannot-find-external-graphics
questionFOP cannot find a file for fo:external-graphics./question
answer
-p
- The src attribute of the fo:external-graphics element takes an URI,
- not a file name.
-/p
-p
- Relative URLs are resolved against the baseDir property of FOP. For
- the command line FOP application, the baseDir is the directory of the
- input file, either the FO file or the XML source. If FOP is used
- embedded in a servlet, link href=embedding.htmlbaseDir can be
-set explicitely/link. If it's not set, it is usually the current
- working directory of the process which runs FOP.
-/p
-!--p
- See Understanding URIs and URLs and Understanding
- URL resolving.
-/p--
+pThe src attribute of the fo:external-graphics element requires a URI,
not a file name. See link href=fo.html#external-resourcesExternal Resources/link
for more information about specifying URIs./p
/answer
/faq
faq id=fonts-not-found
1.6 +8 -0 xml-fop/src/documentation/content/xdocs/fo.xml
Index: fo.xml
===
RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/fo.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- fo.xml17 Jun 2003 19:02:25 - 1.5
+++ fo.xml11 Jul 2003 19:01:54 - 1.6
@@ -436,6 +436,14 @@
/fo:simple-page-master
/fo:layout-master-set]]/source
/section
+ section id=external-resources
+titleExternal Resources/title
+pResources needed by an XSL-FO file that are external to it (graphics,
for example), are defined in the XSL-FO standard as being of type uri-specification.
This is defined in the standard at jump
href=http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N8794-Property-Datatypes;Section
5.11 Property Datatypes/jump, which includes a link to the URI standard itself.
Refer to the XSL-FO and URI standards themselves for more detailed instructions./p
+pURIs may be either absolute or relative to a base URI. (See link
href=configuration.htmlFOP: Configuration/link for information on setting the
base URI for a FOP session). Here is an example referencing an external-graphic that
is relative to the base URI:/p
+source![CDATA[fo:external-graphic
src=url('images/logo.jpg')/]]/source
+pHere is an example referencing an external-graphic that is an absolute
URI on a local filesystem:/p
+source![CDATA[fo:external-graphic
src=url('file:d:///images/logo.jpg')/]]/source
+ /section
/section
/body
/document
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PDFWArray.java NullPointerException
Yup, same here. It seems to be a Checkstyle problem. I still need to check if the same happens with the Checkstyle ant target. On 11.07.2003 11:54:50 Peter B. West wrote: Has anyone else had problems compiling PDFWArray.java in fop.pdf under Eclipse? In a previous incarnation, I was getting persistent NullPointerExceptions at Line 0 when attempting to build. I couldn't see what the problem was, so I did a clean checkout and it built cleanly. After my last update, I have the problem back again. It seems like a coding problem, but the file compiles under Ant, outside Eclipse. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: JPEG images in Postscript
On 07.07.2003 10:28:59 Chris Bowditch wrote: I'm currently figuring out how best to solve this. I'm looking at the code from jpeg2ps which doesn't seem to have a problem with these JPEG files. The code in there is made to ignore any trailing bytes but processes the whole stream twice if I interpret correctly. Maybe looking for the EOI marker in our code and cutting off there is better performance-wise. But jpeg2ps' code is on the safe side in any case. Preferences anyone? Sorry but this message arrived after I left on Friday. I dont have a preference. Out of interest, which option did you go for? Speed or mimicking the jpeg2ps code? I can't say for sure what the performance differences are between the two solutions. Anyway I have chosen the quick easy path and went for the jpeg2ps-style approach since I don't have too much time available. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: move Ant task to Ant project
Over the past months (no, years) we've spent a lot of time maintaining optional tasks and fixing bugs in them, more time than we spent on improving Ant itself. As a consequence you'll find a big reluctance with Ant developers to accept any new tasks at all. I see the problem. In particular if the new tasks relies on a third-party tool/library that is an open source project itself. We'd probably send you back to FOP. Not having followed the discussion leading up to this, why would you want to ship it with Ant rather than FOP? The advantages to shipping with Ant are that it would become more of a standard and get more exposure and usage. It is also nice to have all the task documentation accessible through the single (frames-based) web page. I know from experience that a user is more likely to start using an Ant task that is built in to Ant, even if it requires external Jars. I've been using xslt for months, but only recently began using the Fop ant task. Currently we are adding the infrastructure for something we call Ant libraries. ... This will make deploying third party tasks even easier than it is now. That's a great solution. One suggestion for Ant libraries - it would be nice to have a task name registry so that the task names can be standardized. Also, it might make sense to have a recommended mechanism for having multiple implementations implement the same Ant task. I'm sure you must have this mechanisms for javac and it looks like xslt uses Trax. If there were a standardized xslfo task it is conceivable that people might want to use a processor other than Fop. Is there a link that I can look at to see the work in progress in this area? I assume that if we targeted Ant 1.6, we would use the 0.20.x code base. If it wants to be in Ant 1.6, I'm sorry my message really had two *subjects* and I only put one in the subject line. I was trying to say that we should put the changes into the Fop project and begin the process of submitting to Ant. The three options were for putting the patch into a Fop release. (I suspected that the Ant committers would feel more comfortable with including a task that had been shipping for some time.) -- Sean -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
