DO NOT REPLY [Bug 35534] - fo document output is placed in page margins
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35534. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35534 --- Additional Comments From [EMAIL PROTECTED] 2005-07-26 09:55 --- The situation is now improved here. The missing glues are now produced but if there are shrink and stretch possibilities the spaces are currently not adjusted, i.e. differing .minimum/.optimum/.maximum values on space-before and space-after may produce undesirable results. Changes: http://svn.apache.org/viewcvs?rev=225133view=rev http://svn.apache.org/viewcvs?rev=225135view=rev http://svn.apache.org/viewcvs?rev=225147view=rev http://svn.apache.org/viewcvs?rev=225249view=rev http://svn.apache.org/viewcvs?rev=225250view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
fop contribution
Hello Do not know exactly the person that is responsible for such issue as mine. So I decided to write to fop-dev. Our company has been sucessfully using FOP for several years. As our customers required extended functionality and FOP had several bugs and restrictions, 3 years ago we created our own FOP branch. Those days we were in a hurry and did not consider the issue of commitment of our modifications to Apache. Now we have troubles with our FOP branch support because we have to constantly merge it with Apache's FOP. Having now necessary resources we'd like very much to commit our changes to Apache. There are two main features we have implemented in the FOP: 1. the insertion of exeternal PDF documents into the rendered PDF document. The mechanism is similar on the images insertion, we use fo:external-graphics element and put content-type property equals to pdf For example, fo:external-graphics content-type=pdf file=c:\test\testfile.pdf/ An external PDF file is inserted into rendered PDF document AS-IS, also there is a possibility to insert page range, not the whole external PDF. For external PDF uploading we use the third-party library Etymon Pj (http://www.etymon.com/epub.html) . It is under GNU GPL license . 2. MathML 2.0 support. To implement MathML support, we also used the third-party library named JEuclid. But we can consider the case of MathML support implementation fully inside of FOP project, without JEuclid usage. It would be not very expensive in human/time resources as our guys almost fully re-implemented JEuclid. Some other features and bugs fixes were made. 3 years ago we based our FOP branch on the Apacehe FOP version 0.20.4rc. As FOP maintenance branch is not being developed, we'd like to make contributions on the main branch. Coule you please advise on the steps on how to contribute. I guess there should be some code compliance rules and some agreements with Apache. Also in case our customers will port their applications on new FOP we could participate in FOP contribution more actively and push forward its success. -- Thanks in advance, Siarhei Baidun
Re: fop contribution
On 26.07.2005 15:47:03 Siarhei Baidun wrote: Hello Do not know exactly the person that is responsible for such issue as mine. Not a single person, but the whole FOP developer community and eventually the XML Graphics project management committee (PMC). But you found exactly the right spot to write to. So I decided to write to fop-dev. Our company has been sucessfully using FOP for several years. As our customers required extended functionality and FOP had several bugs and restrictions, 3 years ago we created our own FOP branch. Those days we were in a hurry and did not consider the issue of commitment of our modifications to Apache. Now we have troubles with our FOP branch support because we have to constantly merge it with Apache's FOP. Having now necessary resources we'd like very much to commit our changes to Apache. That's very good news. There are two main features we have implemented in the FOP: 1. the insertion of exeternal PDF documents into the rendered PDF document. The mechanism is similar on the images insertion, we use fo:external-graphics element and put content-type property equals to pdf For example, fo:external-graphics content-type=pdf file=c:\test\testfile.pdf/ An external PDF file is inserted into rendered PDF document AS-IS, also there is a possibility to insert page range, not the whole external PDF. This sounds quite interesting and has been asked for a few times. A simpler use case would be simply to be able to add PDF pages to a FOP-generated document, possibly through a custom extension. For external PDF uploading we use the third-party library Etymon Pj (http://www.etymon.com/epub.html) . It is under GNU GPL license . This is a problem. Apache software can't include or use GPL-licensed software. A different approach would be to extend our own PDF library to support parsing PDF or to use iText (which is MPL 1.1 licensed and therefore usable for us). But the latter option would probably mean to rewrite the whole PDFRenderer to use iText with all the implications that arise with this. That's why I'd personally prefer extending our own PDF library. But that is open for discussion. 2. MathML 2.0 support. To implement MathML support, we also used the third-party library named JEuclid. But we can consider the case of MathML support implementation fully inside of FOP project, without JEuclid usage. It would be not very expensive in human/time resources as our guys almost fully re-implemented JEuclid. Are you aware of the MathML extension in the FOP repository? http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/mathml/ Some other features and bugs fixes were made. 3 years ago we based our FOP branch on the Apacehe FOP version 0.20.4rc. As FOP maintenance branch is not being developed, we'd like to make contributions on the main branch. That would be extremely welcome and just at the right time!!! Coule you please advise on the steps on how to contribute. I guess there should be some code compliance rules and some agreements with Apache. Also in case our customers will port their applications on new FOP we could participate in FOP contribution more actively and push forward its success. Most of the basic information for contributors is found here: http://xml.apache.org/fop/dev/index.html If you plan to contribute anything larger than a bugfix on an existing file we will need a CLA (contributor license agreement) for each person that contributes to the project (to be sent to the ASF secretary). In addition to that it may be necessary to submit a CCLA (corporate contributor license agreement). Please see the following link for more information: http://www.apache.org/licenses/ Code conventions are found here: http://xml.apache.org/fop/dev/conventions.html Before you start to work on anthing bigger, please tell us what it is so we can give some guidance and make sure there aren't any big disappointments. Contributions should be sent to us using Bugzilla entries which we will review and commit to the repository once everything is fine. People contributing substantially to the project (code, documentation, support etc.) over a longer period of time are eligible to become a committer which includes write-access to the code-repository, voting right and stuff like that. More infos on how that works under: http://xmlgraphics.apache.org/charter.html http://www.apache.org/foundation/faq.html I hope that helps. If you have any further questions, don't hesitate to ask. Jeremias Maerki
Re: fop contribution
Jeremias, I'm impressed with your fluency in English... :-p On Jul 26, 2005, at 7:10 AM, Jeremias Maerki wrote: snip I hope that helps. If you have any further questions, don't hesitate to ask. Jeremias Maerki Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: MathML and barcode support for FOP
It all sounds good to me. I was one of those asking for batik-less FOP, since I needed to output PDF from a headless system (I think we ended up using the Postscript renderer, and cat'ing it to the printer...). I also welcome the thought of additional XML Graphics projects. Not so much for the sake of quantity, but because I hope that additional projects might bring additional users (folks interested in MathML or Barcode4J, but not necessarily brought in because of XSL-FO/PDF or SVG), and eventually additional committers (mmm... fresh blood ;-)). Web Maestro Clay On Jul 26, 2005, at 7:26 AM, Jeremias Maerki wrote: Devs, I'd like to have your thoughts about the following proposal. MathML and barcodes are frequently asked for and I would consider it a service to our users if we provided support for both out-of-the-box without people having to scratch together the little pieces to make this stuff work. JEuclid is AL1.1 and Barcode4J is AL2.0 licensed. So no worries about redistribution. I'd like to promote the MathML extension out of the examples directory where it seems to be a little hidden. We still have the plan extension as a good example for FOP extensions. But I wouldn't really want to integrate the MathML extension sources into the main source tree where it adds to the existing blob of code. I'd rather make SVG support separate and therefore optional and put both (SVG and MathML) alongside each other in a separate place next to the main sources. FOP without Batik-dependency has also been asked for a few times which we could get almost for free if we did this. Barcode4J 1.0 as my proposed barcode package (what a surprise!) has its own FOP extension and would simply be added as a JAR file in the lib directory. I could do the necessary changes while doing the whole XML Graphics Commons stuff which I really really really want to do really really soon now. :-) Jeremias Maerki Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Flame-fodder: Thinking about starting to release again....
Another thing, that I'd like to bring up. We're approaching a state where FOP Trunk code is usable for more serious use cases. The important FOs are all implemented. In the past, we talked about making 1.0 meet XSL 1.0 Basic Conformance. I believe to do that would be bad for the project in its current state. We can't wait much longer and we desperately need to attract active contributors. I don't mean that the first release has to be a 1.0. But IMO we should get close to that. Maybe call the first unstable preview release 0.9pr1. Once we have a stable code base with a reasonable feature set and updated documentation we should IMO call it 1.0 and go on from there. I believe that we could do an initial unstable preview release with big disclaimers all over the place in about two months. My next tasks are to update the PostScript renderer and to make sure that PDF, PS and Java2D output is more or less on the same level. After that we should do a testing/bugfixing round to make the overall package real-world-usable. Your thoughts? Jeremias Maerki
Re: MathML and barcode support for FOP
I was not so much thinking about additional XML Graphics projects. Bringing Barcode4J here was on my mind, but not lately. I'm not sure if it would be a good fit as it doesn't exclusively have to do the converting XML to graphical output. That's only one use case. Generating barcodes as bitmap images, for example, has absolutely nothing to do with XML stuff. Bringing JEuclid into the ASF and XML Graphics, however, could be quite interesting and would be fully in line with the project charter. On 26.07.2005 16:34:08 The Web Maestro wrote: It all sounds good to me. I was one of those asking for batik-less FOP, since I needed to output PDF from a headless system (I think we ended up using the Postscript renderer, and cat'ing it to the printer...). I also welcome the thought of additional XML Graphics projects. Not so much for the sake of quantity, but because I hope that additional projects might bring additional users (folks interested in MathML or Barcode4J, but not necessarily brought in because of XSL-FO/PDF or SVG), and eventually additional committers (mmm... fresh blood ;-)). Web Maestro Clay On Jul 26, 2005, at 7:26 AM, Jeremias Maerki wrote: Devs, I'd like to have your thoughts about the following proposal. MathML and barcodes are frequently asked for and I would consider it a service to our users if we provided support for both out-of-the-box without people having to scratch together the little pieces to make this stuff work. JEuclid is AL1.1 and Barcode4J is AL2.0 licensed. So no worries about redistribution. I'd like to promote the MathML extension out of the examples directory where it seems to be a little hidden. We still have the plan extension as a good example for FOP extensions. But I wouldn't really want to integrate the MathML extension sources into the main source tree where it adds to the existing blob of code. I'd rather make SVG support separate and therefore optional and put both (SVG and MathML) alongside each other in a separate place next to the main sources. FOP without Batik-dependency has also been asked for a few times which we could get almost for free if we did this. Barcode4J 1.0 as my proposed barcode package (what a surprise!) has its own FOP extension and would simply be added as a JAR file in the lib directory. I could do the necessary changes while doing the whole XML Graphics Commons stuff which I really really really want to do really really soon now. :-) Jeremias Maerki Regards, Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet Jeremias Maerki
Re: fop contribution
1. the insertion of exeternal PDF documents into the rendered PDF document. The mechanism is similar on the images insertion, we use fo:external-graphics element and put content-type property equals to pdf For example, fo:external-graphics content-type=pdf file=c:\test\testfile.pdf/ An external PDF file is inserted into rendered PDF document AS-IS, also there is a possibility to insert page range, not the whole external PDF. This sounds quite interesting and has been asked for a few times. A simpler use case would be simply to be able to add PDF pages to a FOP-generated document, possibly through a custom extension. I may have expressed the idea not very clearly. We do add PDF pages to a FOP-generated document, except we do not use extension pight now. We modified PDFRenderer A BIT and particulary have added there the method renderExternalPage(...) For external PDF uploading we use the third-party library Etymon Pj (http://www.etymon.com/epub.html) . It is under GNU GPL license . This is a problem. Apache software can't include or use GPL-licensed software. A different approach would be to extend our own PDF library to support parsing PDF or to use iText (which is MPL 1.1 licensed and therefore usable for us). But the latter option would probably mean to rewrite the whole PDFRenderer to use iText with all the implications that arise with this. That's why I'd personally prefer extending our own PDF library. But that is open for discussion. To extend PDF library is the perfect solution. But it might take a long time and we need the working solution asap. So as a temporary solution we can consider the use of iText instead of Pj. Right now I do not think such substitution is a bit problem. If iText is able to parse PDF document and if it provides the API to retrieve PDF entities (e.g. Pages, resources, objects) - no problem. Should say again, in case of the present implementation PDFRenderer is affected in a little extent. 2. MathML 2.0 support. Are you aware of the MathML extension in the FOP repository? http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/mathml/ Have just had a look on it and was really surprised - it uses JEuclid! Just would like to say that we have been developing MathML support for several month and made a deep tests for it. During development we were modifying JEuclid and have almost re-written it. We can now consider the case of the implementation of mathML sub-project in the scope of FOP (as PDF library) If you plan to contribute anything larger than a bugfix on an existing file we will need a CLA (contributor license agreement) for each person that contributes to the project (to be sent to the ASF secretary). In addition to that it may be necessary to submit a CCLA (corporate contributor license agreement). Please see the following link for more information: http://www.apache.org/licenses/ Code conventions are found here: http://xml.apache.org/fop/dev/conventions.html Before you start to work on anthing bigger, please tell us what it is so we can give some guidance and make sure there aren't any big disappointments. Contributions should be sent to us using Bugzilla entries which we will review and commit to the repository once everything is fine. People contributing substantially to the project (code, documentation, support etc.) over a longer period of time are eligible to become a committer which includes write-access to the code-repository, voting right and stuff like that. More infos on how that works under: http://xmlgraphics.apache.org/charter.html http://www.apache.org/foundation/faq.html Ok, we are ready to provide you our source code for features I outlined above through Bugzilla. As I understand, the license agreement (CLA) is requried when the issue of becoming a contributor will arise (after several sucessfull contributions through Bugzilla, as you wrote). -- Siarhei Baidun
Re: Flame-fodder: Thinking about starting to release again....
Jeremias Maerki wrote: Another thing, that I'd like to bring up. We're approaching a state where FOP Trunk code is usable for more serious use cases. The important FOs are all implemented. In the past, we talked about making 1.0 meet XSL 1.0 Basic Conformance. I believe to do that would be bad for the project in its current state. We can't wait much longer and we desperately need to attract active contributors. I don't mean that the first release has to be a 1.0. But IMO we should get close to that. Maybe call the first unstable preview release 0.9pr1. Once we have a stable code base with a reasonable feature set and updated documentation we should IMO call it 1.0 and go on from there. I totally agree that a release is necessary to move the project on and since most of the functionality of 0.20.5 has been restored in Head plus keep-* property support I feel the code is ready for a release. Also I agree with your reasoning that it should be called 0.9 to make it clear that there are still some limitations to be addressed. I believe that we could do an initial unstable preview release with big disclaimers all over the place in about two months. My next tasks are to update the PostScript renderer and to make sure that PDF, PS and Java2D output is more or less on the same level. After that we should do a testing/bugfixing round to make the overall package real-world-usable. I wouldnt go as far as calling the code totally unstable! I have used it for some documents and the output looks okay. However, we should call it rc or pr as you suggest. I thought the Apache convention was 'rc', but I have no real preference. Just so long as its clear that we expect to find a few bugs and fix them before a production ready release is done. Chris
Re: fop contribution
On 26.07.2005 16:51:35 Siarhei Baidun wrote: 1. the insertion of exeternal PDF documents into the rendered PDF document. The mechanism is similar on the images insertion, we use fo:external-graphics element and put content-type property equals to pdf For example, fo:external-graphics content-type=pdf file=c:\test\testfile.pdf/ An external PDF file is inserted into rendered PDF document AS-IS, also there is a possibility to insert page range, not the whole external PDF. This sounds quite interesting and has been asked for a few times. A simpler use case would be simply to be able to add PDF pages to a FOP-generated document, possibly through a custom extension. I may have expressed the idea not very clearly. We do add PDF pages to a FOP-generated document, except we do not use extension pight now. We modified PDFRenderer A BIT and particulary have added there the method renderExternalPage(...) Ah, I see. But in that case external-graphic is probably not the right element to use as it is an inline-level element. For external PDF uploading we use the third-party library Etymon Pj (http://www.etymon.com/epub.html) . It is under GNU GPL license . This is a problem. Apache software can't include or use GPL-licensed software. A different approach would be to extend our own PDF library to support parsing PDF or to use iText (which is MPL 1.1 licensed and therefore usable for us). But the latter option would probably mean to rewrite the whole PDFRenderer to use iText with all the implications that arise with this. That's why I'd personally prefer extending our own PDF library. But that is open for discussion. To extend PDF library is the perfect solution. But it might take a long time and we need the working solution asap. So as a temporary solution we can consider the use of iText instead of Pj. Right now I do not think such substitution is a bit problem. If iText is able to parse PDF document and if it provides the API to retrieve PDF entities (e.g. Pages, resources, objects) - no problem. Should say again, in case of the present implementation PDFRenderer is affected in a little extent. iText is able to handle that, yes. 2. MathML 2.0 support. Are you aware of the MathML extension in the FOP repository? http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/mathml/ Have just had a look on it and was really surprised - it uses JEuclid! Just would like to say that we have been developing MathML support for several month and made a deep tests for it. During development we were modifying JEuclid and have almost re-written it. We can now consider the case of the implementation of mathML sub-project in the scope of FOP (as PDF library) Provided, we get the licensing issues right, yes. This would include contacting the original authors of JEuclid if you based your code on it. Furthermore, bringing in a whole subproject such as JEuclid would involve going through the Apache Incubator. But let's first get some opinions on that move (see my other thread). If you plan to contribute anything larger than a bugfix on an existing file we will need a CLA (contributor license agreement) for each person that contributes to the project (to be sent to the ASF secretary). In addition to that it may be necessary to submit a CCLA (corporate contributor license agreement). Please see the following link for more information: http://www.apache.org/licenses/ Code conventions are found here: http://xml.apache.org/fop/dev/conventions.html Before you start to work on anthing bigger, please tell us what it is so we can give some guidance and make sure there aren't any big disappointments. Contributions should be sent to us using Bugzilla entries which we will review and commit to the repository once everything is fine. People contributing substantially to the project (code, documentation, support etc.) over a longer period of time are eligible to become a committer which includes write-access to the code-repository, voting right and stuff like that. More infos on how that works under: http://xmlgraphics.apache.org/charter.html http://www.apache.org/foundation/faq.html Ok, we are ready to provide you our source code for features I outlined above through Bugzilla. As I understand, the license agreement (CLA) is requried when the issue of becoming a contributor will arise (after several sucessfull contributions through Bugzilla, as you wrote). No, the ASF policy was recently changed (or rather clarified) so you would need to submit a CLA for any contribution bigger than a trivial bugfix on an existing file, i.e. for new files, even if you're not yet a committer. Jeremias Maerki
Re: MathML and barcode support for FOP
Jeremias Maerki wrote: Devs, I'd like to have your thoughts about the following proposal. MathML and barcodes are frequently asked for and I would consider it a service to our users if we provided support for both out-of-the-box without people having to scratch together the little pieces to make this stuff work. JEuclid is AL1.1 and Barcode4J is AL2.0 licensed. So no worries about redistribution. I'd like to promote the MathML extension out of the examples directory where it seems to be a little hidden. We still have the plan extension as a good example for FOP extensions. But I wouldn't really want to integrate the MathML extension sources into the main source tree where it adds to the existing blob of code. I'd rather make SVG support separate and therefore optional and put both (SVG and MathML) alongside each other in a separate place next to the main sources. FOP without Batik-dependency has also been asked for a few times which we could get almost for free if we did this. Barcode4J 1.0 as my proposed barcode package (what a surprise!) has its own FOP extension and would simply be added as a JAR file in the lib directory. I could do the necessary changes while doing the whole XML Graphics Commons stuff which I really really really want to do really really soon now. :-) I am in favour of seeing MathML and barcode support out of the box in FOP. Most people using XSL-FO for printed documents have a requirement to add Barcodes and there are a small number of people asking for Mathematic Formula representions. As you already mentioned it might be a good idea to move the JEuclid code into a sub project of Xml Graphics. Possibly the code that Siarhei Baidun is proposing to commit to Apache in another thread. Chris
Re: Flame-fodder: Thinking about starting to release again....
On 26.07.2005 17:22:28 The Web Maestro wrote: Before we actually move to make this release, I'd like to understand the discrepancies between 0.20.5 and the proposed 0.9rc1 release of TRUNK a bit better. Yes, that's an important point. I was under the impression that the first TRUNK release would be on parity with 0.20.5. I'm not *certain* that is necessary, although it is certainly preferred. Jeremias mentioned parity between the PDF, Postscript Java2D renderers, and that's a good goal. I agree that it is preferred to have a 0.20.5 equivalent, but not so much that it obstructs us from doing a perfectly usable release. I think 0.20.5 will still be around for a while. There's no easy way around that. The FOPProjectTasks Wiki[1] is a good place to start, but a comparison chart similar to the FOP Compliance Page might be better. That way our users can quickly identify how usable the TRUNK release is for them. In fact, it might make sense to just update the FOP Compliance page with this information, changing support to 0.20.5 support, and creating an additional 0.9xx1 support group of columns[3]. As I mentioned myself a couple of times the compliance page is extremely important for us as an instrument to inform users of the status of the development. That's also a point where non-developers can easily contribute. :-) Jeremias Maerki
Re: Flame-fodder: Thinking about starting to release again....
Jeremias Maerki wrote: I don't know of any such convention. I've seen various variants: rc, beta, previews etc. I think we're free to choose. I'd rather go for alpha. rc means release candidate, meaning features and APIs are stable, and I don't think HEAD is there already. Other than that, a release as a sign that the project isn't dead is highly recommended, regardless of bugs and incomplete features. J.Pietschmann
Re: MathML and barcode support for FOP
I understand your concerns but we should make it as easy as possible for beginners. There are a lot of them, many knowing almost nothing about Java and classpaths. The beauty with these extensions is that they can easily be deleted when not used. No rebuild necessary. On 26.07.2005 21:45:33 Simon Pepping wrote: Having MathML and barcode support is a good thing. But I am not very enthousiastic about the goal of providing support for both out-of-the-box. Scratching pieces of functionality together and integrating them is a different role than developing an application. I am a Debian Linux user, and an advocate of the model of Debian (and other distributions): development is one role, integration is another role. I am horrified of the Apache packages, which make me have Xerces and other libs many times on my computer. I am in favour of promoting the MathML extension to a more visible place. I have no opinion on JEuclid in XMLGraphics. Separating SVG support from FOP core is OK with me. Jeremias Maerki
Re: svn commit: r225143 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: apps/ fo/ render/ render/java2d/ render/pdf/ render/ps/ render/svg/ render/xml/ util/
Jeremias Maerki wrote: Just had. I must say that I don't get it from a 5 minute glance at it. Me too. Commons math used to use discovery for getting an implementation class for root solvers, but they abandoned the approach because they thought the added dependency wont outweight the benefits. But they do have a Service class! J.Pietschmann
