freeing FOP

[Thomas Fitzsimmons]

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.

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.

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.

Tom

[Karsten Wade]

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