struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: [SAF2] Tossing an idea around: PDFResult
Date Wed, 07 Jun 2006 02:59:04 GMT
On 6/5/06, Joe Germuska <> wrote:
> At 3:38 PM -0400 6/5/06, Frank W. Zammetti wrote:
> >Not a bad idea... I've never been a big fan of XSLT, always seemed overly
> >difficult to me for what it was, but certainly sticking with a standard
> >has appeal, and I've done a little bit of FOP work, so it's not all new.
> >
> >One thing I was thinking about for the Ajax result stuff was to have
> >optionally a toXML() and toJSON() method on the Action... if they are
> >present, they would be used by the Results rather than the automatic
> >generation process... would allow for more complex outputs than the
> >automatic process is capable of.. having toXML() on the Action might be a
> >good idea in general, precisely for things like PDF generation and the
> >XSLT Result you mention.  Maybe some default implementation (the one from
> >AjaxXMLResult possibly?) in ActionSupport might open some doors?
> >
> >In any case, I may have to play with your suggestion a bit and see what
> it
> >might look like... I like the idea of using standards, but I have some
> >doubts as to how easy it would be for developers to use, generally.
> It depends a lot upon your use case -- but for starters, this very
> question suggests that if you do write anything, you should call it
> ITextResult, or FOPResult, not PDFResult.
> Writing FO can be kind of tedious, while IText has an API that is
> pretty well suited to just flowing text in if you have simple needs.
> I haven't used either exhaustively -- my day job is a LOT about
> generating PDFs but ours need much finer design control than either
> of those APIs really support.
> It seems like design of a generalized (custom) XML format for
> describing PDF templates for iText is a pretty big chunk of
> responsibility which doesn't really belong at Struts.  It seems like
> something that should be done in cooperation with the iText team for
> eventual integration to their project, or if not, to be served
> independently.

I agree that this doesn't sound like something that should happen here. As
for working with the iText team, unless things have changed recently, there
are two iText teams, because the two guys that started it went their
separate ways some time ago, so now there's "Paulo's iText" and the other
guy's iText. (Sorry, I don't recall the other guy's name.) Also, the last
time I checked, each of the two iText versions were one-man teams.

Is there any problem with iText's license? (dual LGPL/MPL)?  May be
> worth a look at PDFBox, which is BSD licensed:

I think MPL is OK. The bigger concern, as Ted mentioned, would be that
they're all one-man shows. I haven't looked at PDFBox, but I've been
singularly unimpressed by the iText API (although it's been a couple of
years now since I last looked at it). Hopefully PDFBox is better.

Martin Cooper

Just a few fragmentary thoughts...
> Joe
> --
> Joe Germuska
> *
> "You really can't burn anything out by trying something new, and
> even if you can burn it out, it can be fixed.  Try something new."
>         -- Robert Moog
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message