As far as using FOP it is still in the early development stages. So you 
can evaluate it and use it if it is good enough for your needs. Due to the 
missing features and bugs etc. it is harder to evaluate and may be a 
problem if you want to extend how you use it.

In terms of the current development status. I would say that there needs 
to be more people invloved and at the current progress it is still a long 
way from being completed. Part of the problem seems to be that to 
implement even a simple fo feature there is still a lot of other code to 
do. Another problem is the lack of effort around all the other important 
areas: website, docs, images etc.

The only thing that will improve FOP is more people doing something 
positive even if it is small.

Keiron Liddle

On 2002.01.25 00:12 [EMAIL PROTECTED] wrote:
> First off, thank you for what looks like a fantastic effort. I admire
> (and
> am envious of) each of you who have found the time to contribute to such
> a
> valuable project.
> I am involved with the approval process for bringing new technology into
> our company.  We have several development groups who have seen the FOP
> engine and would like to include it their applications. The requirements
> are pretty much the same across applications. They need to generate lots
> of
> short dynamic documents in PDF (lots=500-1000 per day, short=1-20 pages,
> mostly text, some tables).  Some of the applications need to support
> unicode or double-byte languages.
> On the surface, I agree that FOP looks like the right answer for what
> they
> need.  However, I also need to ensure that we follow our guidelines for
> technology acquisition.
> One of our primary tenets is "no beta software should be included in
> production applications".
> I have read through many posts in the mail list and appreciate the
> honesty
> and clarity about the current status.
> Back in January of 2001 and again in July 2001, Arved Sandstrom pointed
> out
> that FOP is still a development effort.
> With this message, I am hoping I can persuade one of the committers to
> provide a "January 2002" update on the status.
> I have found the occasional status messages very useful, hopefully any
> response to this message on the archive will help others in the future.
> Here is a snippet from the July 2001 post by Arved:
> >> FOP developers and committers have never suggested that the processor
> is
> >> anything other than a work in progress. My best guess is that if we
> have
> a
> >> production release by the end of the year then we'll be doing well.
> Alpha is
> >> a long ways away.
> Is this still the case?  I am making an assumption that the version
> number
> speaks to the status (v0.x is "pre-release").
> Is the version numbering a reflection of:
>      A. Still early in development
>      B. Indication of how completely the XSL:FO spec is implemented
>      C. A combination of both
> I also in various places reference to RC (Release Candidate) versions. It
> seems that currently v0.20.1 is the latest "stable" release (no
> implication
> intended by "stable" - I just think I saw that phrasing somewhere
> associated with v0.20.1).
> If possible, could someone clarify the intention/meaning of the x.yy.zz
> version scheme.
> (I am guessing that x is major production release, yy is a change to what
> is supported, and zz is for minor changes / patches.)
> I see some notes about the inclusion of jfor (RTF output) into the FOP
> project.  I think that would be really cool, and speaks very well of the
> effort put in thus far. Anyone care to comment on when that may make it
> into a release?
> On a somewhat related note, any updated comments on the following would
> be
> appreciated.
> I have seen several posts that recommend Renderx XEP if you "need
> production level code".  Is that still the case?
> Sometime ago, Renderx apparently put a feature comparison up on their
> site,
> but since removed it (concerns of bias, etc).
> I have seen references to things like "look for independent comparisons".
> Has anyone seen a recent comparison? I can not find one (though I
> understand time is better spent refining the code than dedicating
> resources
> to run comparisons).
> Thanks in advance for any responses,
> Pete Tribulski

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to