You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Clay Leeds <cl...@medata.com> on 2003/07/01 17:50:24 UTC
Running FOP 'headless' FAQ
On 7/1/2003 8:22 AM, Clay Leeds wrote:
> This is just a guess, but perhaps you're running FOP headless (there's
> no monitor?). This FAQ might provide a workaround:
>
> http://xml.apache.org/fop/graphics.html#batik
I have a question or two about the "headless" FAQ. This's only mentioned
in the Graphics/Batik section. However, the quote says:
===
Batik must be run in a graphical environment. It uses AWT classes for
rendering SVG, which in turn require an X server on Unixish systems. If
you run a server without X, or if you can't connect to the X server due
to security restrictions or policies (a so-called "headless"
environment), SVG rendering will fail.
===
Unless I'm reading this wrong, this means the "headless" problem is
directly related to AWT, and because Batik "uses AWT classes for
rendering SVG" it is also indirectly affected. Am I correct? If so,
should the "headless" FAQ really be in an AWT section, and the Batik
section provide a reference to the AWT headless issue, rather than the
current way it's shown?
BTW, the FAQ shows the first workaround as:
===
If you are using JDK 1.4, start it with the -Djava.awt.headless=true
command line option.
===
Is that supposed to be "-D java.awt.headless=true" ?
On a somewhat-related issue, since I tend to run FOP from the command
line interface (CLI), I'm always interested in the arguments I can pass
through via the CLI. I haven't seen the above CLI argument documented
anywhere. What other CLI args are there which aren't documented in the
"help" which is displayed if you don't pass FOP the correct args?
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Running FOP 'headless' FAQ
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 01.07.2003 17:50:24 Clay Leeds wrote:
> On 7/1/2003 8:22 AM, Clay Leeds wrote:
> > This is just a guess, but perhaps you're running FOP headless (there's
> > no monitor?). This FAQ might provide a workaround:
> >
> > http://xml.apache.org/fop/graphics.html#batik
>
> I have a question or two about the "headless" FAQ. This's only mentioned
> in the Graphics/Batik section. However, the quote says:
>
> ===
> Batik must be run in a graphical environment. It uses AWT classes for
> rendering SVG, which in turn require an X server on Unixish systems. If
> you run a server without X, or if you can't connect to the X server due
> to security restrictions or policies (a so-called "headless"
> environment), SVG rendering will fail.
> ===
>
> Unless I'm reading this wrong, this means the "headless" problem is
> directly related to AWT, and because Batik "uses AWT classes for
> rendering SVG" it is also indirectly affected. Am I correct?
Yes.
> If so,
> should the "headless" FAQ really be in an AWT section, and the Batik
> section provide a reference to the AWT headless issue, rather than the
> current way it's shown?
That may be better. Wanna send a patch?
> BTW, the FAQ shows the first workaround as:
>
> ===
> If you are using JDK 1.4, start it with the -Djava.awt.headless=true
> command line option.
> ===
>
> Is that supposed to be "-D java.awt.headless=true" ?
No.
> On a somewhat-related issue, since I tend to run FOP from the command
> line interface (CLI), I'm always interested in the arguments I can pass
> through via the CLI. I haven't seen the above CLI argument documented
> anywhere. What other CLI args are there which aren't documented in the
> "help" which is displayed if you don't pass FOP the correct args?
That particular option is an option from the JDK itself. It's not a FOP
feature. See: http://java.sun.com/j2se/1.4.1/docs/guide/awt/AWTChanges.html#headless
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP manual
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Victor Mote schrieb:
> Clay Leeds wrote:
>
>>A single PDF manual for FOP would really be nice... It might even be
[..]
> that, but it might make more sense to try to use Forrest/Cocoon instead, so
http://marc.theaimsgroup.com/?l=forrest-dev&m=105516618908652&w=2 ?
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: FOP manual
Posted by Victor Mote <vi...@outfitr.com>.
Clay Leeds wrote:
> Sounds good. Would you send me what you had (if you can find it! ;-p) so
> I can do a bit of learning? Does this mean (gulp!) I'll have to learn
> how to mess around with Cocoon? I guess it could be a good thing...
It is long gone. Yes, you'll want to get a rudimentary understanding of
Cocoon. There are some good books available, and it seems like the web site
is pretty helpful.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP manual
Posted by Clay Leeds <cl...@medata.com>.
On 7/2/2003 10:08 AM, Victor Mote wrote:
> I actually had this working at one time in the pre-Forrest days, and in the
> days before I was a committer, so I don't think it ever got committed. The
> solution then was a target in the build.xml file, and it could still be
> that, but it might make more sense to try to use Forrest/Cocoon instead, so
> that the PDF can actually be placed on the web site for downloading. Forrest
> uses the book.xml files for its structure, and you could use that, but it
> seems pretty inflexible to me. IIRC, my previous solution was a stylesheet
> that essentially imported the other documents. Cocoon seems to have been
> made for this sort of thing. I think the solution I would probably try first
> is to our Cocoon infrastructure, as it can do the XSLT (some are
> non-standard, FAQ and Compliance for example), aggregate it, then FOP it.
> I'm no expert on any of this, but I can probably help you. Also, eventually
> two manuals would be nice, one for FOP users, another for FOP dev, design,
> and alt-design.
Sounds good. Would you send me what you had (if you can find it! ;-p) so
I can do a bit of learning? Does this mean (gulp!) I'll have to learn
how to mess around with Cocoon? I guess it could be a good thing...
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
FOP manual (WAS: Running FOP 'headless' FAQ)
Posted by Victor Mote <vi...@outfitr.com>.
Clay Leeds wrote:
> A single PDF manual for FOP would really be nice... It might even be
> cool to just make a PDF with links to the other PDFs (I assume that the
> current "manual" is what comes in the build/site directory). What would
> it take to generate a single PDF of the FOP manual? Of course, it would
> be great it it had bookmarks, too. Would it be possible to make this
> happen by creating some sort of 'meta' xml file which somehow contains
> links to all of the sub-files? It could either be a single PDF file or
> it could be a multi-PDf file. Is there a better way to make it happen?
> Anyone? Anyone? ;-p
I actually had this working at one time in the pre-Forrest days, and in the
days before I was a committer, so I don't think it ever got committed. The
solution then was a target in the build.xml file, and it could still be
that, but it might make more sense to try to use Forrest/Cocoon instead, so
that the PDF can actually be placed on the web site for downloading. Forrest
uses the book.xml files for its structure, and you could use that, but it
seems pretty inflexible to me. IIRC, my previous solution was a stylesheet
that essentially imported the other documents. Cocoon seems to have been
made for this sort of thing. I think the solution I would probably try first
is to our Cocoon infrastructure, as it can do the XSLT (some are
non-standard, FAQ and Compliance for example), aggregate it, then FOP it.
I'm no expert on any of this, but I can probably help you. Also, eventually
two manuals would be nice, one for FOP users, another for FOP dev, design,
and alt-design.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Running FOP 'headless' FAQ
Posted by Clay Leeds <cl...@medata.com>.
On 7/1/2003 2:06 PM, J.Pietschmann wrote:
> Running the print renderer in a headless environment works
> the same way as running Batik, given the printer is installed
> correctly (not quite trivial). This and any additional ideas
> like creating PostScript and piping it to lp should be added
> to a sort of user manual. The FAQ is, well, reserved for FAQs.
> I actually culled most from the list last year. A few former
> FAQs should be deprecated now and could be removed (less
> clutter).
A single PDF manual for FOP would really be nice... It might even be
cool to just make a PDF with links to the other PDFs (I assume that the
current "manual" is what comes in the build/site directory). What would
it take to generate a single PDF of the FOP manual? Of course, it would
be great it it had bookmarks, too. Would it be possible to make this
happen by creating some sort of 'meta' xml file which somehow contains
links to all of the sub-files? It could either be a single PDF file or
it could be a multi-PDf file. Is there a better way to make it happen?
Anyone? Anyone? ;-p
FWIW, I haven't begun any changes related to the AWT issue, as I'm not
really sure where to start.
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Running FOP 'headless' FAQ
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Clay Leeds wrote:
> As for using '-print' headless,
> some of my clients have attempted to use such a set up. IIRC, we set
> them up to output to '-ps' and then piped that to the 'lp'. Should we
> add this "workaround" to the FAQ, or is outputting to '-ps' an option
> when SVG is one of the inputs?
Running the print renderer in a headless environment works
the same way as running Batik, given the printer is installed
correctly (not quite trivial). This and any additional ideas
like creating PostScript and piping it to lp should be added
to a sort of user manual. The FAQ is, well, reserved for FAQs.
I actually culled most from the list last year. A few former
FAQs should be deprecated now and could be removed (less
clutter).
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Running FOP 'headless' FAQ
Posted by Clay Leeds <cl...@medata.com>.
On 7/1/2003 12:35 PM, J.Pietschmann wrote:
> This is silly, nobody will start the AWT renderer on a headless
> workstation. If you login via a text console and expect a window
> to pop up, you have already missed something important.
> Well, using the print renderer on a headless station, that's another
> thing. But not (yet) a FAQ but any stretch of imagination.
Makes sense. Sorry for the silliness. As for using '-print' headless,
some of my clients have attempted to use such a set up. IIRC, we set
them up to output to '-ps' and then piped that to the 'lp'. Should we
add this "workaround" to the FAQ, or is outputting to '-ps' an option
when SVG is one of the inputs? I would guess it's fine, but I haven't
tested it.
> The list both displayed by usage() as well as on the web site is
> complete, with respect to FOP options. It doesn't include the JVM
> args, which you have to get from elsewhere, and can't be set through
> the command scripts anyway.
Thanks for setting me straight.
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Running FOP 'headless' FAQ
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Clay Leeds wrote:
> Unless I'm reading this wrong, this means the "headless" problem is
> directly related to AWT, and because Batik "uses AWT classes for
> rendering SVG" it is also indirectly affected. Am I correct? If so,
> should the "headless" FAQ really be in an AWT section, and the Batik
> section provide a reference to the AWT headless issue, rather than the
> current way it's shown?
This is silly, nobody will start the AWT renderer on a headless
workstation. If you login via a text console and expect a window
to pop up, you have already missed something important.
Well, using the print renderer on a headless station, that's another
thing. But not (yet) a FAQ but any stretch of imagination.
> What other CLI args are there which aren't documented in the
> "help" which is displayed if you don't pass FOP the correct args?
The list both displayed by usage() as well as on the web site is
complete, with respect to FOP options. It doesn't include the JVM
args, which you have to get from elsewhere, and can't be set through
the command scripts anyway.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org