Re: Signup for the Cocoon GT Hackathon
Added myself. The Cocoon Serializer is a good idea, IF!!! Maven is kind with me this time. ;-) We could also do a Bugzilla cleanup (long due). Improving the docs and the FAQ is another idea. On 21.09.2006 10:02:46 Bertrand Delacretaz wrote: Hi FOPpers, As I think some of you are coming to the Cocoon GetTogether: you're welcome to sign up at http://wiki.apache.org/cocoon/GT2006Hackaton. I have added creating a Cocoon serializer for the current FOP release as a hacking idea. Not sure if I'll have much time to work on this myself, but it'd be very nice to have. -Bertrand Jeremias Maerki
Re: Re: Signup for the Cocoon GT Hackathon
On 9/22/06, Jeremias Maerki [EMAIL PROTECTED] wrote: Added myself. The Cocoon Serializer is a good idea, IF!!! Maven is kind with me this time. ;-)... I might get some flak from the Cocoon team for saying this, but I think a FOP trunk serializer would be good for Cocoon 2.1.x as well (the 2.1 build does not use Maven, it's only 2.2 which uses Maven). Many people still use Cocoon 2.1, and this is especially true of people who use it only for publishing purposes, IMHO. -Bertrand
Re: Signup for the Cocoon GT Hackathon
Cocoon 2.1.x then. That sounds like a more productive approach. :-) If they fire up their flak, I'll retaliate by ranting about Maven. Hehe. On 22.09.2006 15:50:50 Bertrand Delacretaz wrote: On 9/22/06, Jeremias Maerki [EMAIL PROTECTED] wrote: Added myself. The Cocoon Serializer is a good idea, IF!!! Maven is kind with me this time. ;-)... I might get some flak from the Cocoon team for saying this, but I think a FOP trunk serializer would be good for Cocoon 2.1.x as well (the 2.1 build does not use Maven, it's only 2.2 which uses Maven). Many people still use Cocoon 2.1, and this is especially true of people who use it only for publishing purposes, IMHO. -Bertrand Jeremias Maerki
Re: Re: Signup for the Cocoon GT Hackathon
On 9/22/06, Vincent Hennebert [EMAIL PROTECTED] wrote: I know about nothing of Cocoon, will that be a problem? :-/... I'm sure Cocoonistas will be delighted to have you guys around. -Bertrand
DO NOT REPLY [Bug 40583] New: - Under Cygwin, fop bash script CLASSPATH problem
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=40583. 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=40583 Summary: Under Cygwin, fop bash script CLASSPATH problem Product: Fop Version: 0.92 Platform: PC OS/Version: other Status: NEW Severity: major Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The LOCALCLASSPATH variable in the script is set to longer than 256 characters, making any reasonable cygwin basic install fail with: cygpath: error converting /cygdrive/c/win2k/fop/lib/xmlgraphics-commons-1.0.jar:/cygdrive/c/win2k/fop/lib/xml-apis-1.3.02.jar:/cygdrive/c/win2k/fop/lib/xercesImpl-2.7.1.jar:/cygdrive/c/win2k/fop/lib/xalan-2.7.0.jar:/cygdrive/c/win2k/fop/lib/serializer-2.7.0.jar:/cygdrive/c/win2k/fop/lib/commons-logging-1.0.4.jar:/cygdrive/c/win2k/fop/lib/commons-io-1.1.jar:/cygdrive/c/win2k/fop/lib/batik-all-1.6.jar:/cygdrive/c/win2k/fop/lib/avalon-framework-4.2.0.jar:/cygdrive/c/win2k/fop/build/fop.jar:/cygdrive/c/win2k/fop/build/fop-sandbox.jar:/cygdrive/c/win2k/fop/build/fop-hyph.jar: - File name too long Exception in thread main java.lang.NoClassDefFoundError: org/apache/fop/cli/Main I have ant installed in the same directory, and it does not fail like this. The reason for this is that it has the ANT_LIB and ANT_HOME directories passed to it as properties, and (i guess) deals with the classpath issues internally. -- 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.
Re: Signup for the Cocoon GT Hackathon
On Fri, Sep 22, 2006 at 06:05:54PM +0200, Vincent Hennebert wrote: I know about nothing of Cocoon, will that be a problem? :-/ Also, although this is perhaps a bit ambitious for two days, we could discuss about the merging of the line- and page-level breaking algorithms? It is a good idea to look at this, although it is a very complex subject. What is a Cocoon serializer in FOP? What does Maven have to do with it? Simon Vincent Jeremias Maerki a écrit : Added myself. The Cocoon Serializer is a good idea, IF!!! Maven is kind with me this time. ;-) We could also do a Bugzilla cleanup (long due). Improving the docs and the FAQ is another idea. On 21.09.2006 10:02:46 Bertrand Delacretaz wrote: Hi FOPpers, As I think some of you are coming to the Cocoon GetTogether: you're welcome to sign up at http://wiki.apache.org/cocoon/GT2006Hackaton. I have added creating a Cocoon serializer for the current FOP release as a hacking idea. Not sure if I'll have much time to work on this myself, but it'd be very nice to have. -Bertrand Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.eu
Re: Signup for the Cocoon GT Hackathon
On 22.09.2006 20:40:17 Simon Pepping wrote: On Fri, Sep 22, 2006 at 06:05:54PM +0200, Vincent Hennebert wrote: I know about nothing of Cocoon, will that be a problem? :-/ Certainly not. But it might help you getting to know Cocoon since you're likely going to do Cocoon projects in the future, right? Also, although this is perhaps a bit ambitious for two days, we could discuss about the merging of the line- and page-level breaking algorithms? It is a good idea to look at this, although it is a very complex subject. Yeah, and don't expect to get much done at a hackathon. What is a Cocoon serializer in FOP? What does Maven have to do with it? A serializer is a Cocoon component that converts an XML stream (FO in this case) to a binary stream (PDF in this case). It's how FOP is integrated into Cocoon so the Cocooners can generate PDFs. They have a FOPSerializer for 0.20.5 but now that the API has changed they need a new one. http://cocoon.apache.org/2.1/userdocs/pdf-serializer.html Maven is used to build Cocoon 2.2 and I've already tried to write a FOPSerializer during the last ApacheCon but I spent the whole day just trying to build Cocoon using Maven, failing in the end. snip/ Jeremias Maerki
Re: Including an sRGB color profile?
Ok, so here's a rough overview what needs to be done. No guarantee for completeness or accuracy. 1. Implementation of the rgb-icc() function. See also: http://www.antennahouse.com/xslfo/axf4-extension.htm#rgb-icc http://www.renderx.com/reference.html#Color_Specifiers Whether the #CMYK pseudo-profile is really needed or if ICC colors are sufficient, I cannot say at this time. In the end, the function needs to generate a java.awt.Color (or descendant if necessary). I'm not sure if the rgb-icc() function can sufficiently be mapped into FOP's function infrastructure because it uses a non-constant number of parameters. 2. Internal representation of colors Thanks to Max Berger FOP already uses java.awt.Color throughout the layout engine so we don't have to worry much anymore how the color information is transported to the renderers. However, I can't tell if Java's color infrastructure is up to the task of transporting the color information as we need it for CMYK support. 3. org.apache.fop.image package This package is in need of a redesign for various reasons, one of them being that it doesn't use RenderedImage/BufferedImage internally to represent decoded images. Instead it uses byte arrays with decoded RGB data. In order to properly support CMYK not only for JPEGs, the refactoring will need to be done if we want a clean solution. 4. Improving the renderers to implement CMYK I assume the PDF renderer is the most important here. It needs to be able to deal with the additional color types. But the other renderers at least shouldn't fail when they encounter non-RGB data. The PDF library is another place to look out for color stuff (like the PDFColor class). PDF profiles like PDF/A-1b and PDF/X-3:2003 will also need to be verified to work again after CMYK support is there. Having CMYK support enables the implementation of other PDF/X standards. 5. SVG support As XSL-FO, SVG is primarily operating in the sRGB space, but has extensions for ICC color (icc-color() function in SVG). I'm not sure about the status of ICC color support in Batik, so this has to be investigated. At any rate, there will need to be some changes to handle CMYK requirements for SVG graphics. Otherwise, you will only get RGB/sRGB colors in the PDF. That's quite a bit to do. I guess it would make sense to start a Wiki page to write down all the info around the topic, gather knowledge, to track progress and to coordinate. As for estimates, that's actually quite difficult at this time, without further investigation. Point 1 shouldn't be all that hard, maybe a day or so. Point 2 is probably ignorable except if AWT cannot hold the color information like we need it. Point 3 is larger, probably 4 to 5 days. It will take some more investigation and design. I've got a idea how this should look like but so far I haven't written it down. I've only done some requirements gathering on http://wiki.apache.org/xmlgraphics-fop/ImageSupport. Point 4 is probably not that difficult but a lot of tedious work which involves a lot of testing and reading specifications. I assume it's another 3 to 4 days. Point 5 is difficult to estimate at this time. Add at least a couple of days if you're not familiar with color handling and the PDF specification. The good news is that all this doesn't require knowledge about the layout engine which simplifies getting into this a lot!!! But of course, there's still a lot to learn about colors, PDF and PDF profiles. Point 3 is on my middle-term radar, as is the rest but with lower priority. So it's most likely I can help with the image package, but not immediately. Ideas and guidance, sure, but not code at this time. On 20.09.2006 22:48:20 Peter Coppens wrote: FOP fans, I could also use cmyk support in fop. My options are to buy some xsl fo implementation that supports it or trye to contribute to fop (assuming the community lets me) Could someone give me a very rough estimate on how much work it would require, including getting acquainted with the fop architecture. Thanks, Peter Jeremias Maerki-2 wrote: On 31.03.2006 21:48:43 Max Berger wrote: I know I have no vote in this, but I do disagree. Every opinion is always welcome. 1) I still believe that PDF is a print medium and should therefore default to CMYK colorspace. If supported correctly by software, the colors should show up right on the screen. One use case of PDF is as a print medium, but it's not the only one. If we're talking about producing documents for offset printing, then yes, I agree with you. Fact is that most PDF-producing software packages I know produce RGB (either uncalibrated DeviceRGB or sRGB). This applies to OpenOffice, Acrobat Distiller with its default settings, GhostScript. The list probably goes on. Supporting CMYK in FOP means some additional work which I don't have time for (and don't really have a need myself). The client that has asked me to implement PDF/A-1 is
