struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: [SAF2] Tossing an idea around: PDFResult
Date Wed, 07 Jun 2006 05:20:45 GMT
On 6/6/06, Frank W. Zammetti <fzlists@omnytex.com> wrote:
>
> Martin Cooper wrote:
> > I agree that this doesn't sound like something that should happen here.
>
> Your saying that in terms of the custom XML wrapper around
> iText/PDFBox/whatever, right?


Yes.

  I.e., going the FOP direction is a
> different story, right?


No. FOP = whatever. I consider anything --> PDF to be out of scope / too
specialised here.

--
Martin Cooper


  I do agree, even though I've already done it
> once, the XML template specification is something bigger than we'd
> probably want here, and is more appropriate elsewhere.
>
> One existing possibility is here:
>
> http://ujac.sourceforge.net/
>
> This library contains an XML template format around iText.  It is
> however GPL/LGPL, which I recall being a problem at Apache, correct?
>
> I think FOP is still the interesting option here.  Much more flexible
> certainly, more output options than just PDF, and licensing shouldn't be
> any kind of concern, nor should community and future development.  I'm
> just starting to think about what could be done to make it easier on
> developers...  Certainly I could see a Result to generate the data XML
> automatically in some way, then all the developer would really have to
> do is create the XSLT.
>
> > 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.
>
> That's interesting, I wasn't aware of any of those politics.  I know
> that when I go here: http://www.lowagie.com/iText/ I see both Bruno and
> Paul's name... that may just be a historical thing, I don't know.
>
> > 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.
>
> I just spent a little time looking at PDFBox... it looks decent.  I need
> to look in more detail though... I wasn't too thrilled to see 2+ years
> of development and still not a 1.0 release... I know Ted said how is
> anything supposed to get there without being used, and he's of course
> right, but it still worries me a little... I also see a couple of API
> changes in recent releases... perfectly OK before a 1.0 of course, but
> it doesn't exactly make one comfortable about building against it :)
>
> Jasper was mentioned in this thread as another possibility... I thought
> there were some licensing issues there?  I thought I remember something
> about that in the earlier WW->SAF2 talks.
>
> I'm not sure a whole reporting solution is the answer, but, thinking
> about that a bit...
>
> There is another possibility along those lines: Datavision.  The idea of
> moving it to Apache was discussed a few weeks back, but it wound up not
> going anywhere... if there were to be a champion for it, I think it
> might be a good move.  I already have permission from Jim Menard, the
> original author, to pursue that if there should be interest.
>
> In the mean time, I think I've all but convinced myself to explore the
> FOP path.  Seems like if we're not going to go the custom template
> route, might as well go with the standard, and one that opens up more
> possibilities than just PDFs in the process.
>
> Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

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