On Wed, 2006-02-22 at 00:45 -0500, Thomas Fitzsimmons wrote: > Hi, > > I finished building FOP and its dependencies on the free Java stack. To > pare the dependency tree I built Batik without Rhino support. If such a > feature-limited Batik is acceptable in Fedora Extras then we'll only > need to add about five new packages, rather than the ~80 packages we'd > need for a Rhino-enabled Batik. Rhino is the Mozilla JavaScript interpreter, right? We don't have any need for that I know of. When someone else with such a need packages Rhino for Extras, I suppose we can add support back in. Tommy informed me that our main usage of Batik is for batik-rasterizer for SVG files. If batik-rasterizer works without Rhino, we're fine. > Batik 1.6 also has dependencies on com.sun classes in its JPEG- and > TIFF-encoding code. These dependencies have been removed in Batik CVS > but for now I've disabled JPEG- and TIFF- output in my test RPM. > > Unfortunately, FOP has two non-free dependencies, neither of which has a > free drop-in replacement. These are Jimi and JAI, both image-handling > frameworks. From the FOP error output it seems that JAI is the > preferred framework with Jimi providing a fallback. It may be possible > to provide a second fallback that uses the standard ImageIO framework > which is implemented in the free stack, but that will require upstream > changes. For now free FOP cannot handle images. Our images need is only for PNG support. That lets us output to screen and printed formats. Does it just strip out/ignore image calls in the FO? > To test my FOP RPM I ran build-hig-pdf.sh from the GNOME Human Interface > Guidelines CVS repository. I've attached a log of the console output > and the generated PDF. A GCJ bug is preventing the compilation of FOP's > hyphenation patterns which explains why FOP can't find them. I'll file > a bug for this shortly. > > Perhaps the documentation team can review the attached PDF? Shall I go > ahead and propose FOP and its dependencies for Fedora Extras inclusion, > even though it currently lacks image support? I'm wondering if that > would be a good way for the docs team to track my progress and offer > feedback. Obviously until the image support issues are resolved the > packages will have to be considered preview-quality. The attached PDF looks stellar, from a visual/format stand point. I didn't see any visual bugs in my comb through, and it was nice to see things such as URLs finally formatted well, such as, this is the link text [URI]. We can't really use it in production without image support, but I'm sure some of us would like to see how it handles our most difficult XML to PDF conversions. Thanks so much for working on this. Let us know how the packaging progresses, and I'll roust up a few folks who have been complaining about PDF output and give this to test with. :) - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
Attachment:
signature.asc
Description: This is a digitally signed message part
