Recently I've been taking a look at how far along the xmlroff project is (http://sourceforge.net/projects/xmlroff), and whether it can meet the needs of the Fedora Project documentation yet.
The short answer is that it cannot yet do all that we need; most notably, the implementation of images is in flux and so they do not work at the moment. The upstream maintainer looks to have a good idea of how it should be done, and has posted a step-by-step list on the xmlroff mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_id=6775778&forum_id=...
However, aside from images, what other things would we need from an XSL-FO processor? My thinking is that if "all" that's missing for us in xmlroff is the images rewrite, it might be quite a nice project to focus on.
Tim. */
On Wed, Mar 30, 2005 at 10:46:47AM +0100, Tim Waugh wrote:
However, aside from images, what other things would we need from an XSL-FO processor? My thinking is that if "all" that's missing for us in xmlroff is the images rewrite, it might be quite a nice project to focus on.
What about FOP (Java-based, from the Apache project)? Does that work with GCJ (I only tried it with Sun Java IIRC)? It is far from complete, but it more or less works.
On Wed, Mar 30, 2005 at 11:59:18AM +0200, Jos Vos wrote:
On Wed, Mar 30, 2005 at 10:46:47AM +0100, Tim Waugh wrote:
However, aside from images, what other things would we need from an XSL-FO processor? My thinking is that if "all" that's missing for us in xmlroff is the images rewrite, it might be quite a nice project to focus on.
What about FOP (Java-based, from the Apache project)? Does that work with GCJ (I only tried it with Sun Java IIRC)? It is far from complete, but it more or less works.
Other discussions on this list have talked about FOP, but I haven't seen any conclusions yet.
Just pointing out that FOP is not the only other usable XSL-FO processor out there.
Tim. */
<quote who="Tim Waugh">
Recently I've been taking a look at how far along the xmlroff project is (http://sourceforge.net/projects/xmlroff), and whether it can meet the needs of the Fedora Project documentation yet.
The short answer is that it cannot yet do all that we need; most notably, the implementation of images is in flux and so they do not work at the moment. The upstream maintainer looks to have a good idea of how it should be done, and has posted a step-by-step list on the xmlroff mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_id=6775778&forum_id=...
However, aside from images, what other things would we need from an XSL-FO processor? My thinking is that if "all" that's missing for us in xmlroff is the images rewrite, it might be quite a nice project to focus on.
I think that only a few guides have images in them, so it's too much off a killer. I would just like PDF creation.
Gavin.
Tim.
*/
fedora-docs-list mailing list fedora-docs-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-docs-list
Uttered Tim Waugh twaugh@redhat.com, spake thus:
Recently I've been taking a look at how far along the xmlroff project is (http://sourceforge.net/projects/xmlroff), and whether it can meet the needs of the Fedora Project documentation yet.
Unfortunately, xmlroff can process a DocBook input only by throwing out the hard stuff; there is even a special stylesheet, for that very purpose, included with the distribution.
The folk at tldp.org have taken the same approach (subsetting) with their LinuxDoc sheets.
FOP needs to "just work"; it looks furtherest along to me.
Cheers
On Wed, 2005-03-30 at 11:13 +0100, Tim Waugh wrote:
On Wed, Mar 30, 2005 at 11:59:18AM +0200, Jos Vos wrote:
On Wed, Mar 30, 2005 at 10:46:47AM +0100, Tim Waugh wrote:
However, aside from images, what other things would we need from an XSL-FO processor? My thinking is that if "all" that's missing for us in xmlroff is the images rewrite, it might be quite a nice project to focus on.
What about FOP (Java-based, from the Apache project)? Does that work with GCJ (I only tried it with Sun Java IIRC)? It is far from complete, but it more or less works.
Other discussions on this list have talked about FOP, but I haven't seen any conclusions yet.
A quick update on this.
Tommy Reynolds patched xmlto to use FOP as a target. Mark Johnson is using this along with the package from jpackage.org in some tests over the next few weeks. Hopefully this will give us a clearer picture of where FOP falls short.
Just pointing out that FOP is not the only other usable XSL-FO processor out there.
Thanks, and definitely everyone keep your eyes open for other possible solutions. No matter what, we need a fully functional open source XSL- FO processor solution ...
- Karsten
Uttered Tim Waugh twaugh@redhat.com, spake thus:
FOP needs to "just work"; it looks furtherest along to me.
Really? I thought we just needed to have 'xmlto pdf ...' work? I can make xmlto run two stylesheets -- not hard. That was my plan actually.
Then I don't expect the generated PDF to bear any resemblance to the appearance of the on-line document.
However, even bad breath is better than no breath at all ...
On Wed, 2005-03-30 at 11:54 -0800, Karsten Wade wrote:
Tommy Reynolds patched xmlto to use FOP as a target. Mark Johnson is using this along with the package from jpackage.org in some tests over the next few weeks. Hopefully this will give us a clearer picture of where FOP falls short.
Last I looked there was a non free buildrequires on jimi for FOP.
Thanks, and definitely everyone keep your eyes open for other possible solutions. No matter what, we need a fully functional open source XSL- FO processor solution ...
Something on top of Cairo would be shiny and new, or docbook support in evince. May attract desktop style ppl.
Paul
Uttered Paul Nasrat pnasrat@redhat.com, spake thus:
Tommy Reynolds patched xmlto to use FOP as a target. Mark Johnson is using this along with the package from jpackage.org in some tests over the next few weeks. Hopefully this will give us a clearer picture of where FOP falls short.
Last I looked there was a non free buildrequires on jimi for FOP.
The jpackage.org stuff looks to be a cadillac build.
It's not really a requirement. Without jimi, FOP doesn't recognize .PNG images. Native support for .gif and .jpg are supported without any external packages, though. FOP can be built to support these non-free packages if they can be found at runtime, but doesn't require them: they are runtime optional.
Cheers
-
Gavin Henry -
Jos Vos -
Karsten Wade -
Paul Nasrat -
Tim Waugh -
Tommy Reynolds