8:47 a.m.
I'm sure I'll have more questions later, but I figured I'd throw this
one out here -- Is anyone else able to build PDFs using Publican? I've
been playing with it all weekend, but I keep getting errors from FOP
when I try to build PDFs.
(This is after I tweaked /usr/share/publican/xsl/main-pdf.xsl to pull
the import the stylesheets on the local system provided by the
docbook-style-xsl package, instead of having it pull them from the
internet every time. I'm on a very slow internet connection, and it was
timing out while trying to download these files.)
The error I"m getting is:
SEVERE: javax.xml.transform.TransformerException:
file:/tmp/test-article/tmp/en-US/xml/test-article.fo:1:28716:
Error(1/28716): No element mapping definition found for (Namespace URI:
"http://xml.apache.org/fop/extensions", Local Name: "destination")
Feb 18, 2008 9:25:10 AM org.apache.fop.cli.Main startFOP
SEVERE: Exception
javax.xml.transform.TransformerException:
org.apache.fop.apps.FOPException:
file:/tmp/test-article/tmp/en-US/xml/test-article.fo:1:28716:
Error(1/28716): No element mapping definition found for (Namespace URI:
"http://xml.apache.org/fop/extensions", Local Name: "destination")
at
org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:168)
at
org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:115)
at org.apache.fop.cli.Main.startFOP(Main.java:166)
at org.apache.fop.cli.Main.main(Main.java:196)
FWIW, I'm not running the very latest rawhide, but I've updated fop,
xalan, xerces, xml-commons-*, xmlgraphics-*, and the whole IcedTea stack
to the latest versions. I'm no Java or FOP guru by any stretch of the
imagination, so I'm open to any or all suggestions at this point.
-Jared
2:43 p.m.
On Mon, 2008-02-18 at 09:47 -0500, Jared Smith wrote:
I'm sure I'll have more questions later, but I figured
I'd throw this
one out here -- Is anyone else able to build PDFs using Publican? I've
been playing with it all weekend, but I keep getting errors from FOP
when I try to build PDFs.
OK, sorry for the noise on the list... I think I've made some pretty
good progress on tracking down this problem. To make a long short,
publican is assuming that we're using FOP 0.20, while what's in rawhide
is 0.94. This meant xsltproc was adding fox:destination elements to
the .fo file, instead of the new fo:bookmarks instead. To work around
this problem, I had to pass two additional string parameters to xsltproc
(in Makefile.templates):
--stringparam fop1.extensions 1 --stringparam fop.extensions 0
That got the .fo file generated so that FOP 0.94 would handle it
correctly, but then FOP died complaining that it couldn't find Batik in
the classpath. (Which is strange, because I have batik installed. I'm
wondering if the version of FOP in rawhide needs to be rebuilt with
something to tell it to look for batik, but that's just a wild guess.)
FOP needs batik to render the SVG graphics. To get around this problem,
I removed the SVG logo from my document, and I passed one more parameter
to xsltproc to tell it to use the .png admonition graphics instead of
the SVG versions:
--stringparam admon.graphics.extension .png
Ah, lo and behold, I was able to render a PDF!
I'll go ahead and create a diff against Makefile.templates and post it
to bugzilla tomorrow, but this raises a few questions:
1) Do we want the toolchain to be able to detect the version of FOP and
adjust itself accordingly?
2) Do we want to expose other parameters to xsltproc? In my very
rudimentary home-grown toolchain, I create a custom XSLT stylesheet that
exposes a bunch of settings (paper.type, double.sided, draft.mode,
shade.verbatim, etc.) which imports the standard XSL stylesheet. Would
this be more manageable in the long run that passing a bunch of
stringparam arguments to xsltproc?
3) Makefile.templates currently tells FOP to use the fop configuration
file in $(COMMON_CONFIG)/fop/fop-0.20.5.xconf, but that doesn't come as
part of the publican package. Should we remove the reference (and
assume people have a valid FOP config file in /etc/fop.conf), or expose
this via a variable in the Makefile? (This isn't a big deal -- I just
thought I'd mention it in passing while I was thinking about it.)
4) Can somebody take a look at why fop isn't seeing batik in the
classpath? My Java skills are obviously too weak to fix this problem.
-Jared
5:23 p.m.
Hi Jared, we do indeed use FOP 0.20.5, and although I have some configuration data
I used when testing FOP 0.93, it is by no means complete and I have no idea if
they work with FOP 0.94.
FWIW I have found FOP 0.20.5 to be significantly more reliable than FOP 0.93, I
haven't had time to test FOP 0.94 yet :(
Jared Smith wrote:
On Mon, 2008-02-18 at 09:47 -0500, Jared Smith wrote:
> I'm sure I'll have more questions later, but I figured I'd throw this
> one out here -- Is anyone else able to build PDFs using Publican? I've
> been playing with it all weekend, but I keep getting errors from FOP
> when I try to build PDFs.
OK, sorry for the noise on the list... I think I've made some pretty
good progress on tracking down this problem. To make a long short,
publican is assuming that we're using FOP 0.20, while what's in rawhide
is 0.94. This meant xsltproc was adding fox:destination elements to
the .fo file, instead of the new fo:bookmarks instead. To work around
this problem, I had to pass two additional string parameters to xsltproc
(in Makefile.templates):
--stringparam fop1.extensions 1 --stringparam fop.extensions 0
That got the .fo file generated so that FOP 0.94 would handle it
correctly, but then FOP died complaining that it couldn't find Batik in
the classpath. (Which is strange, because I have batik installed. I'm
wondering if the version of FOP in rawhide needs to be rebuilt with
something to tell it to look for batik, but that's just a wild guess.)
FOP needs batik to render the SVG graphics. To get around this problem,
I removed the SVG logo from my document, and I passed one more parameter
to xsltproc to tell it to use the .png admonition graphics instead of
the SVG versions:
--stringparam admon.graphics.extension .png
Ah, lo and behold, I was able to render a PDF!
I'll go ahead and create a diff against Makefile.templates and post it
to bugzilla tomorrow, but this raises a few questions:
1) Do we want the toolchain to be able to detect the version of FOP and
adjust itself accordingly?
This is probably the best approach, however different versions of FOP require
different configuration files and font metrics files. So we really want to keep
the number of supported version to a low number, like say 2 :)
2) Do we want to expose other parameters to xsltproc? In my very
rudimentary home-grown toolchain, I create a custom XSLT stylesheet that
exposes a bunch of settings (paper.type, double.sided, draft.mode,
shade.verbatim, etc.) which imports the standard XSL stylesheet. Would
this be more manageable in the long run that passing a bunch of
stringparam arguments to xsltproc?
The custom xsl has been specifically modified to give the best layout for the
targeted formatting. It _may_ break horribly if you change parameters like single
page and paper size. By "break horribly" I mean it may output ugly things, which
I'm assured is close to criminal ... Andy likes his pretty things!
The thing about brands is that you don't want people changing things arbitrarily,
if they want that they need to make their own brand.
The first custom brand will probably be a little difficult, I'll be happy to help
anyone trying to setup a custom brand to get any kinks worked out.
I think the best way of doing this is to check for Brand specific xsl files, and
if they exist use them. This way you can guarantee that books built using your
brand, on your build server, will always be "on brand". But it also allows
people
to make custom brands and change the layout however they want.
If you wanted to offer two different outputs for a single real format, i.e. two
flavors of pdf, one way would be to make a new main-<format>.xsl file.
e.g. Say you were wrong, yes wrong, and wanted to use US Letter (he he he :P) and
single page, you could make a new target, say pdf-LS, you just cp main-pdf.xsl to
main-pdf-LS.xsl, and make your changes to main-pdf-LS.xsl.
The slightly tricky part is to add the extra build targets to the appropriate
Makefile, and viola you have an easy way of building US Letter, Single Page, PDFs
(make pdf-LS). This is tricky since it uses Makefile templates, but the actually
changes are easy once you grok how they work.
This would allow you to heavily customize the pdf-LS output without impacting the
standards compliant, highly correct, extremely sexy, A4 pdf output ;)
I'll be adding Brand specific Makefiles to allow Brands to customize the build
process, so this kind of thing will be easier for Brands to do.
3) Makefile.templates currently tells FOP to use the fop
configuration
file in $(COMMON_CONFIG)/fop/fop-0.20.5.xconf, but that doesn't come as
part of the publican package. Should we remove the reference (and
assume people have a valid FOP config file in /etc/fop.conf), or expose
this via a variable in the Makefile? (This isn't a big deal -- I just
thought I'd mention it in passing while I was thinking about it.)
It's at /usr/share/publican/fop/fop-0.20.5.xconf
There is also /usr/share/publican/fop/fop-0.93.xconf
The default fop config file lacks font entries, causing most translated PDFs to be
unreadable.
Definitely need to be able to switch fop config files, I'll poke around to find a
workable way of doing this.
Cheers, Jeff.
5:43 a.m.
On Tue, 2008-02-19 at 09:23 +1000, Jeff Fearn wrote:
Jared Smith wrote:
> 1) Do we want the toolchain to be able to detect the version of FOP and
> adjust itself accordingly?
This is probably the best approach, however different versions of FOP require
different configuration files and font metrics files. So we really want to keep
the number of supported version to a low number, like say 2 :)
How about three+? This is because we have Fedora N, Fedora N-1,
rawhide, and EPEL 5. I'm reckoning that you might want to see the a
preferred version of fop in EPEL. We'll continue to need it working in
the current, current-minus-one, and rawhide.
- Karsten
--
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
6:19 p.m.
Karsten 'quaid' Wade wrote:
On Tue, 2008-02-19 at 09:23 +1000, Jeff Fearn wrote:
> Jared Smith wrote:
>> 1) Do we want the toolchain to be able to detect the version of FOP and
>> adjust itself accordingly?
> This is probably the best approach, however different versions of FOP require
> different configuration files and font metrics files. So we really want to keep
> the number of supported version to a low number, like say 2 :)
How about three+? This is because we have Fedora N, Fedora N-1,
rawhide, and EPEL 5. I'm reckoning that you might want to see the a
preferred version of fop in EPEL. We'll continue to need it working in
the current, current-minus-one, and rawhide.
I came up with a way that can support an arbitrary number of config files :)
I have some patches in place to try and get FOP 0.94 working, however
it's proving to be a pain to get working. Still plugging away on that.
Cheers, Jeff.
--
Jeff Fearn <jfearn(a)redhat.com>
Software Engineer
Engineering Operations
Red Hat, Inc
8:05 a.m.
On Thu, 2008-02-21 at 10:19 +1000, Jeff Fearn wrote:
I came up with a way that can support an arbitrary number of config
files :)
I have some patches in place to try and get FOP 0.94 working, however
it's proving to be a pain to get working. Still plugging away on that.
OK, let me know if I can be of any help, as I currently have FOP 0.94
working just fine with Publican in Rawhide, with the exception of
support for SVG graphics. I still haven't got that sorted out yet.
-Jared
8:32 p.m.
On Thu, 2008-02-21 at 09:05 -0500, Jared Smith wrote:
On Thu, 2008-02-21 at 10:19 +1000, Jeff Fearn wrote:
> I came up with a way that can support an arbitrary number of config files :)
>
> I have some patches in place to try and get FOP 0.94 working, however
> it's proving to be a pain to get working. Still plugging away on that.
OK, let me know if I can be of any help, as I currently have FOP 0.94
working just fine with Publican in Rawhide, with the exception of
support for SVG graphics. I still haven't got that sorted out yet.
IIRC, Batik originally had some dependencies for graphics processing
that couldn't be cleanly included under IcedTea. It may not yet be able
to process SVG?
I think Mark (Cc:'d) might be able to shed some light on this.
- Karsten
--
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
4:48 a.m.
Hi Karsten,
On Thu, 2008-02-21 at 18:32 -0800, Karsten 'quaid' Wade wrote:
On Thu, 2008-02-21 at 09:05 -0500, Jared Smith wrote:
> On Thu, 2008-02-21 at 10:19 +1000, Jeff Fearn wrote:
> > I came up with a way that can support an arbitrary number of config files :)
> >
> > I have some patches in place to try and get FOP 0.94 working, however
> > it's proving to be a pain to get working. Still plugging away on that.
>
> OK, let me know if I can be of any help, as I currently have FOP 0.94
> working just fine with Publican in Rawhide, with the exception of
> support for SVG graphics. I still haven't got that sorted out yet.
IIRC, Batik originally had some dependencies for graphics processing
that couldn't be cleanly included under IcedTea. It may not yet be able
to process SVG?
I think Mark (Cc:'d) might be able to shed some light on this.
Everything needed for FOP graphics should work now, but I don't have any
experience with it myself. I have CCed Tom Fitzsimmons who does know the
details. And was just yesterday raving about an openoffice SVG plugin
written in java that people should package for Fedora that worked with
IcedTea now.
Cheers,
Mark
5898
days inactive
5905
days old
7 comments
4 participants
participants (4)
-
Jared Smith -
Jeff Fearn -
Karsten Wade -
Mark Wielaard