date:20081124

Adrian,

I'm unhappy with this change. I know you're constantly trying to
improve things by refactoring but you also need to be careful about
preserving compatibility. In this case, you broke my external PDF-in-PDF
plug-in by changing the interface from Class getSupportedImageClass()
to Class[] getSupportedImageClasses(). Furthermore, chosing
ImageHandler as the interface name will result in a name clash when
the AFP branch is merged back into Trunk and I'll try to merge those
changes into the IF branch. After all, in this branch the whole image
handling is already properly abstracted for all renderers, not just PDF
and AFP. So I think we need to revisit that before we consider a merge
of the AFP GOCA branch into Trunk.

I think, we have the following options:
1. Remove ImageHandler in the GOCA branch, restore plug-in compatibility
for PDFImageHandler and have a separate service registry class for AFP
and PDF. (My preffered option)
2. We can selectively merge parts of the IF branch (the ImageHandler
abstraction) into trunk before merging the rest (I could do that for you,
if nobody objects the partial merge-back). From there you could make use
of it in the GOCA branch and restore the PDFImageHandler. You could then
use the same image handlers for the current code as well as the
implementation for the new IF.
3. I have to adjust my PDF plug-in and do another release knowing that
this is only for restoring compatibility.

On 13.11.2008 17:12:00 acumiskey wrote:
 Author: acumiskey
 Date: Thu Nov 13 08:11:58 2008
 New Revision: 713747
 
 URL: http://svn.apache.org/viewvc?rev=713747view=rev
 Log:
 * PDFImageHandler interface split into ImageHandler and PDFImageHandler.
 * Deleted AFPDataObjectInfoProvider and AFPImage*Factory implementations, and 
 abstracted AbstractImageHandlerRegistry from PDFImageHandlerRegistry, 
 creating AFPImageHandlerRegistry and AFPImageHandler so there is a common 
 reuse of image handling implementation between AFP and PDF now.
 * RendererContext instantiation is now overridable in PrintRenderer.
 * Created AFPRendererContext that is able to provide AFPInfo.
 * toString() added to RendererContext for ease of use.
 * Removed GraphicsObjectPainterAFP.
 * Added package.html for AFP (sub)packages.
 * Abstracted AbstractFOPBridgeContext from PDFBridgeContext and provided 
 AFPBridgeContext implementation.
 * Abstracted AbstractFOPTextElementBridge from PDFTextElementBridge and 
 provided AFPTextElementBridge implementation.
 * Abstracted AbstractFOPImageElementBridge from PDFImageElementBridge and 
 provided AFPImageElementBridge implementation.
 * Provided inline image support/handling in AFPGraphics2D for SVG.
 * Created NativeImageHandler interface.
 * Fix for path iterator filled line drawing in AFPGraphics2D adding 
 coordinate drawing implementations GraphicsLineRelative and 
 GraphicsFilletRelative (Thanks for the patch Jeremias).
 * Improved configuration.xml documentation for images mode/native setting in 
 AFP renderer configuration.
snip/



Jeremias Maerki

DO NOT REPLY [Bug 46272] printing the first page with full contents but page breaks in next pages itself

https://issues.apache.org/bugzilla/show_bug.cgi?id=46272


Chris Bowditch [EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Comment #1 from Chris Bowditch [EMAIL PROTECTED]  2008-11-24 02:02:18 PST 
---
Can you please supply a sample FO File (not XML or XSLT) that demonstrates the
problem?


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: svn commit: r713747 [1/4] - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources/src: documentation/content/xdocs/trunk/ java/META-INF/services/ java/org/apache/fop/afp/ java/org/apache/fop/afp/font


Jeremias,

Jeremias Maerki wrote:

Adrian,

I'm unhappy with this change. I know you're constantly trying to
improve things by refactoring but you also need to be careful about
preserving compatibility. In this case, you broke my external PDF-in-PDF
plug-in by changing the interface from Class getSupportedImageClass()
to Class[] getSupportedImageClasses(). Furthermore, chosing
ImageHandler as the interface name will result in a name clash when
the AFP branch is merged back into Trunk and I'll try to merge those
changes into the IF branch. After all, in this branch the whole image
handling is already properly abstracted for all renderers, not just PDF
and AFP. So I think we need to revisit that before we consider a merge
of the AFP GOCA branch into Trunk.

I think, we have the following options:
1. Remove ImageHandler in the GOCA branch, restore plug-in compatibility
for PDFImageHandler and have a separate service registry class for AFP
and PDF. (My preffered option)


I think this option would involve the most amount of work and regression testing.  Furthermore, this 
is work that will probably be thrown away later.  It does not need to be done now and can be 
revisited later when the Temp_AreaTreeNewDesign branch is ready to be merged back into trunk.



2. We can selectively merge parts of the IF branch (the ImageHandler
abstraction) into trunk before merging the rest (I could do that for you,
if nobody objects the partial merge-back). From there you could make use
of it in the GOCA branch and restore the PDFImageHandler. You could then
use the same image handlers for the current code as well as the
implementation for the new IF.


This sounds a bit messy, its better we do the merge in one go, a halfway situation is never a good 
one and I would expect quite a bit of management overhead created by this.



3. I have to adjust my PDF plug-in and do another release knowing that
this is only for restoring compatibility.


I would favour this option.  This represents the least amount of change to FOP and the least amount 
of work/regression testing etc.  This is a very small change that should only effect a small number 
of users who upgrade their FOP installation to trunk and forget to upgrade their pdf images plugin.


I have included the simple 2 line patch file for 
src/java/org/apache/fop/render/pdf/pdfbox/PDFBoxPDFImageHandler.java.  Apologies if this creates a 
little more work for you.


Adrian.
112,113c112,113
 public Class[] getSupportedImageClasses() {
 return new Class[] { ImagePDF.class };
---
 public Class getSupportedImageClass() {
 return ImagePDF.class;

Re: svn commit: r713747 [1/4] - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources/src: documentation/content/xdocs/trunk/ java/META-INF/services/ java/org/apache/fop/afp/ java/org/apache/fop/afp/font

On 24.11.2008 13:14:35 Adrian Cumiskey wrote:
 Jeremias,
 
 Jeremias Maerki wrote:
  Adrian,
  
  I'm unhappy with this change. I know you're constantly trying to
  improve things by refactoring but you also need to be careful about
  preserving compatibility. In this case, you broke my external PDF-in-PDF
  plug-in by changing the interface from Class getSupportedImageClass()
  to Class[] getSupportedImageClasses(). Furthermore, chosing
  ImageHandler as the interface name will result in a name clash when
  the AFP branch is merged back into Trunk and I'll try to merge those
  changes into the IF branch. After all, in this branch the whole image
  handling is already properly abstracted for all renderers, not just PDF
  and AFP. So I think we need to revisit that before we consider a merge
  of the AFP GOCA branch into Trunk.
  
  I think, we have the following options:
  1. Remove ImageHandler in the GOCA branch, restore plug-in compatibility
  for PDFImageHandler and have a separate service registry class for AFP
  and PDF. (My preffered option)
 
 I think this option would involve the most amount of work and regression 
 testing.  Furthermore, this 
 is work that will probably be thrown away later.  It does not need to be done 
 now and can be 
 revisited later when the Temp_AreaTreeNewDesign branch is ready to be merged 
 back into trunk.
 
  2. We can selectively merge parts of the IF branch (the ImageHandler
  abstraction) into trunk before merging the rest (I could do that for you,
  if nobody objects the partial merge-back). From there you could make use
  of it in the GOCA branch and restore the PDFImageHandler. You could then
  use the same image handlers for the current code as well as the
  implementation for the new IF.
 
 This sounds a bit messy, its better we do the merge in one go, a halfway 
 situation is never a good 
 one and I would expect quite a bit of management overhead created by this.
 
  3. I have to adjust my PDF plug-in and do another release knowing that
  this is only for restoring compatibility.
 
 I would favour this option.  This represents the least amount of change to 
 FOP and the least amount 
 of work/regression testing etc.  This is a very small change that should only 
 effect a small number 
 of users who upgrade their FOP installation to trunk and forget to upgrade 
 their pdf images plugin.

Cheap excuse to ignore backwards-compatibility. What if there were other
people who wrote plug-ins of their own?

 I have included the simple 2 line patch file for 
 src/java/org/apache/fop/render/pdf/pdfbox/PDFBoxPDFImageHandler.java.  
 Apologies if this creates a 
 little more work for you.

Your patch has one problem: it kills backwards-compatibility for FOP
0.95. I won't delete the old method so this whole thing will still work
with 0.95.

The necessary changes in my plug-in are negligible. What isn't is the
time I'll spend documenting which version of the plug-in the users have
to select for which FOP version. Add to that time I spend on answering
the questions of the people who don't RTFM.

I wonder if you've spent one second thinking about
backwards-compatibility before changing the PDFImageHandler interface.

So I guess it's up to me anyway to fix this problem.


Jeremias Maerki

DO NOT REPLY [Bug 41942] fo:leader elements are ignored when converted to RTF

https://issues.apache.org/bugzilla/show_bug.cgi?id=41942


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Comment #2 from [EMAIL PROTECTED]  2008-11-24 05:19:43 PST ---
I tested it with 0.95 and there an empty line was generated.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 46277] New: RTF - Block elements with id but without other content shouldn't create a paragraph

https://issues.apache.org/bugzilla/show_bug.cgi?id=46277

   Summary: RTF - Block elements with id but without other content
shouldn't create a paragraph
   Product: Fop
   Version: 0.95
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: rtf
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Created an attachment (id=22923)
 -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22923)
example fo

Block elements which have only an id defined should not create a paragraph in
RTF, because they are just used to reference somewhere, to the last page for
example. 

fo:block id=middle font-size=15pt/
fo:block id=last font-size=18pt/fo:block


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 46276] New: Justified text rendered poorly in AFP Renderer

https://issues.apache.org/bugzilla/show_bug.cgi?id=46276

   Summary: Justified text rendered poorly in AFP Renderer
   Product: Fop
   Version: 0.95
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Created an attachment (id=22922)
 -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22922)
sample AFP File

This affect can be observed using the FO from the test case
block_text-indent.xml in test\layoutengine\standard-testcases. I have attached
a generated AFP file to illustrate. See the second paragraph where the lines
don't end evenly against the right margin.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[VOTE] Merge Temp_AFPGOCAResources branch into trunk


Hi all,

I would like to call for a merge of the AFP branch [1] back into trunk.

This branch [1] contains a major rewrite of pretty much all the original AFP 
code.  The majority of
the AFP code is now homed in its own package separate from the renderer code in 
org.apache.fop.afp.
The AFPRenderer itself is now only sone 800 or so lines long down from the 
previous 1800+ lines and
now more properly extends the AbstractPathOrientedRenderer.  There is also now 
much more shared code
now betweeen the PDF and AFP renderers.

Major new functionality in the branch includes :-

* An AFPGraphics2D implementation which provides the ability to use Batik to 
drive the production of
 AFP Graphics (GOCA) output from SVG.
* Resource group leveling, external streaming and de-duplication of images and 
graphics using
IncludeObject and ResourceGroup.
* Native image embedding support (e.g. JPEG, GIF, TIFF) using ObjectContainer 
and a MOD:CA Registry
implementation.
* More robust AFP font parsing, although this is still in need of some rework 
in the future.

I realize that testing these new AFP features in FOP may not be easy for some 
of you.  You can
however use the Infoprint Solutions (IBM) AFP Workbench Viewer for Windows
(http://www.ibm.com/support/docview.wss?uid=psd1P4000360) to view the output.

[1] 
https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AFPGOCAResources

+1 from me.

Adrian.

DO NOT REPLY [Bug 46277] RTF - Block elements with id but without other content shouldn't create a paragraph

https://issues.apache.org/bugzilla/show_bug.cgi?id=46277





--- Comment #1 from [EMAIL PROTECTED]  2008-11-24 06:07:24 PST ---
Created an attachment (id=22924)
 -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22924)
Patch proposal


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 46278] AFP Renderer doesn't handle fixed with spaces, e.g. thin space #x2009;

https://issues.apache.org/bugzilla/show_bug.cgi?id=46278





--- Comment #1 from Chris Bowditch [EMAIL PROTECTED]  2008-11-24 06:10:28 PST 
---
Created an attachment (id=22926)
 -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22926)
PDF File


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk

2008-11-24 Thread Chris Bowditch


Adrian Cumiskey wrote:


Hi all,

I would like to call for a merge of the AFP branch [1] back into trunk.

This branch [1] contains a major rewrite of pretty much all the original 
AFP code.  The majority of
the AFP code is now homed in its own package separate from the renderer 
code in org.apache.fop.afp.
The AFPRenderer itself is now only sone 800 or so lines long down from 
the previous 1800+ lines and
now more properly extends the AbstractPathOrientedRenderer.  There is 
also now much more shared code

now betweeen the PDF and AFP renderers.

Major new functionality in the branch includes :-

* An AFPGraphics2D implementation which provides the ability to use 
Batik to drive the production of

 AFP Graphics (GOCA) output from SVG.
* Resource group leveling, external streaming and de-duplication of 
images and graphics using

IncludeObject and ResourceGroup.
* Native image embedding support (e.g. JPEG, GIF, TIFF) using 
ObjectContainer and a MOD:CA Registry

implementation.
* More robust AFP font parsing, although this is still in need of some 
rework in the future.


I realize that testing these new AFP features in FOP may not be easy for 
some of you.  You can

however use the Infoprint Solutions (IBM) AFP Workbench Viewer for Windows
(http://www.ibm.com/support/docview.wss?uid=psd1P4000360) to view the 
output.


[1] 
https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_AFPGOCAResources 





Adrian,

you've put a lot of work into the GOCA branch and it has some great 
features, but


There's one thing I don't like, which Jeremias points out in this thread:

http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200811.mbox/[EMAIL 
PROTECTED]

We currently use the PDF plugin in our software and I prefer not to 
upgrade the plugin without knowing what the justification the interface 
change is?



+1 from me.


-0 from me (although this would change to +1 with the above issue resolved)



Adrian.



Thanks,

Chris

Re: svn commit: r713747 [1/4] - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources/src: documentation/content/xdocs/trunk/ java/META-INF/services/ java/org/apache/fop/afp/ java/org/apache/fop/afp/font

Jeremias Maerki wrote:

On 24.11.2008 13:14:35 Adrian Cumiskey wrote:

Jeremias,

Jeremias Maerki wrote:

Adrian,

I'm unhappy with this change. I know you're constantly trying to
improve things by refactoring but you also need to be careful about
preserving compatibility. In this case, you broke my external PDF-in-PDF
plug-in by changing the interface from Class getSupportedImageClass()
to Class[] getSupportedImageClasses(). Furthermore, chosing
ImageHandler as the interface name will result in a name clash when
the AFP branch is merged back into Trunk and I'll try to merge those
changes into the IF branch. After all, in this branch the whole image
handling is already properly abstracted for all renderers, not just PDF
and AFP. So I think we need to revisit that before we consider a merge
of the AFP GOCA branch into Trunk.

I think, we have the following options:
1. Remove ImageHandler in the GOCA branch, restore plug-in compatibility
for PDFImageHandler and have a separate service registry class for AFP
and PDF. (My preffered option)
I think this option would involve the most amount of work and regression testing. Furthermore, this
is work that will probably be thrown away later. It does not need to be done now and can be
revisited later when the Temp_AreaTreeNewDesign branch is ready to be merged back into trunk.

2. We can selectively merge parts of the IF branch (the ImageHandler
abstraction) into trunk before merging the rest (I could do that for you,
if nobody objects the partial merge-back). From there you could make use
of it in the GOCA branch and restore the PDFImageHandler. You could then
use the same image handlers for the current code as well as the
implementation for the new IF.
This sounds a bit messy, its better we do the merge in one go, a halfway situation is never a good
one and I would expect quite a bit of management overhead created by this.

3. I have to adjust my PDF plug-in and do another release knowing that
this is only for restoring compatibility.
I would favour this option. This represents the least amount of change to FOP and the least amount
of work/regression testing etc. This is a very small change that should only effect a small number
of users who upgrade their FOP installation to trunk and forget to upgrade their pdf images plugin.

Cheap excuse to ignore backwards-compatibility. What if there were other
people who wrote plug-ins of their own?

I'm sure if such a person existed and they wrote their own FOP plug-in they could very easily fix a
very small compatibility issue such as this.

I have included the simple 2 line patch file for
src/java/org/apache/fop/render/pdf/pdfbox/PDFBoxPDFImageHandler.java. Apologies if this creates a
little more work for you.

Your patch has one problem: it kills backwards-compatibility for FOP
0.95. I won't delete the old method so this whole thing will still work
with 0.95.

I don't see how this would at all affect 0.95 compatibility. You already
provide a cersion 1.2
(http://www.jeremias-maerki.ch/download/fop/pdf-images) which will work just
fine for 0.95
installations - so no change there. And you also already provide a version 1.1a (from rev 611768 or
later), so all that needs to be done once the Temp_AFPGOCAResources branch is merged back into trunk
is release a new trunk version with the 2 line patch applied.

The necessary changes in my plug-in are negligible. What isn't is the
time I'll spend documenting which version of the plug-in the users have
to select for which FOP version. Add to that time I spend on answering
the questions of the people who don't RTFM.

I sympathize, users can be demanding even when you give of your time freely :).

I wonder if you've spent one second thinking about
backwards-compatibility before changing the PDFImageHandler interface.

Quite simply I wasn't aware that your external pdf images package touched upon this interface. Its
not part of the FOP code base. I will continue to always want what is best for the health of the
project, I find your comment both unnecessarily rude and disrespectful.

Adrian.

Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk


Hi Chris (and all),

Chris Bowditch wrote:


Adrian,

you've put a lot of work into the GOCA branch and it has some great 
features, but


There's one thing I don't like, which Jeremias points out in this thread:

http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200811.mbox/[EMAIL PROTECTED] 



We currently use the PDF plugin in our software and I prefer not to 
upgrade the plugin without knowing what the justification the interface 
change is?


Providing support for native image embedding in AFP involves providing the image data (in whatever 
form it may be) without any requirement for any image specific processing.  So there is one handler 
which takes care of this in AFP, and this handler needs to declare itself able to support the 
handling of more than one image class.  This use case was probably not envisaged when the 
PDFImageHandler interface was first introduced.  Hope this explanation helps :).


Adrian.

Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk

2008-11-24 Thread The Web Maestro

Can other potential renderers take advantage of this new declaration,
or is done in an AFP-specific way?

Clay

On 11/24/08, Adrian Cumiskey [EMAIL PROTECTED] wrote:
 Hi Chris (and all),

 Chris Bowditch wrote:

 Adrian,

 you've put a lot of work into the GOCA branch and it has some great
 features, but

 There's one thing I don't like, which Jeremias points out in this thread:

 http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200811.mbox/[EMAIL
  PROTECTED]



 We currently use the PDF plugin in our software and I prefer not to
 upgrade the plugin without knowing what the justification the interface
 change is?

 Providing support for native image embedding in AFP involves providing the
 image data (in whatever
 form it may be) without any requirement for any image specific processing.
 So there is one handler
 which takes care of this in AFP, and this handler needs to declare itself
 able to support the
 handling of more than one image class.  This use case was probably not
 envisaged when the
 PDFImageHandler interface was first introduced.  Hope this explanation helps
 :).

 Adrian.



-- 
Regards,

The Web Maestro
-- 
[EMAIL PROTECTED] - http://ourlil.com/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk

Hi Clay,

Yes with the refactoring and code reuse changes in the Temp_AFPGOCAResource branch, other renderers
can now also take advantage of creating specialized concrete implementations of
AbstractImageHandlerRegistry and ImageHandler. Prior to these changes these features were only
available for PDF. But now both the PDF and AFP renderers make use of this same service oriented
framework.

There are also now some new extensible Batik bridges in org.apache.fop.svg that have been refactored
that were previously only available for PDF, these could also be extended for other output formats.

Adrian.

The Web Maestro wrote:

Can other potential renderers take advantage of this new declaration,
or is done in an AFP-specific way?

Clay

On 11/24/08, Adrian Cumiskey [EMAIL PROTECTED] wrote:

Hi Chris (and all),

Chris Bowditch wrote:

Adrian,

you've put a lot of work into the GOCA branch and it has some great
features, but

There's one thing I don't like, which Jeremias points out in this thread:

http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200811.mbox/[EMAIL
PROTECTED]

We currently use the PDF plugin in our software and I prefer not to
upgrade the plugin without knowing what the justification the interface
change is?

Providing support for native image embedding in AFP involves providing the
image data (in whatever
form it may be) without any requirement for any image specific processing.
So there is one handler
which takes care of this in AFP, and this handler needs to declare itself
able to support the
handling of more than one image class. This use case was probably not
envisaged when the
PDFImageHandler interface was first introduced. Hope this explanation helps
:).

Adrian.

DO NOT REPLY [Bug 46277] [PATCH] RTF - Block elements with id but without other content shouldn't create a paragraph

https://issues.apache.org/bugzilla/show_bug.cgi?id=46277


Jeremias Maerki [EMAIL PROTECTED] changed:

   What|Removed |Added

   Keywords||PatchAvailable
Summary|RTF - Block elements with id|[PATCH] RTF - Block elements
   |but without other content   |with id but without other
   |shouldn't create a paragraph|content shouldn't create a
   ||paragraph




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: Updating the FOP release plan

Looks like there won't be any more voices. The majority seems to favor a
1.0 release. That's fine by me as long as we can break the 0.x curse.
I'm surprised and grateful that we can finally move forward
version-number-wise.

I think we'll need to announce that release (codename Curse Breaker ;-))
carefully so people don't suddenly assume we have a 100% implementation
of XSL 1.0 or something. I think it'll make sense to work with the PRC
to do this right. After all, this particular release will create its
ripples even if on a technical level the jump isn't that big.

So my proposal would be to work towards a beta release early next year.
By then the AFP and newIF branches should be merged with trunk.
Hopefully it shouldn't take us another half year to release the final
1.0 after the beta. The previous beta-phase was really much too long.

On 19.11.2008 09:37:41 Jeremias Maerki wrote:
 On a serious note (as opposed to my outburst on fop-users), I think we
 should really discuss the FOP release plan which we haven't updated in a
 while. I would hate to see FOP in 0.x mode after 10 years of existence.
 Let's assume 0.20.5 was actually FOP 1.0, and FOP 0.95 was actually FOP
 2.0. How about calling the next version 2.009 (to be released in early
 2009). Skip 1.0 entirely since that would only let the expectations rise
 into the sky. FOP had a major redesign which warrants at least a version
 jump of one major version. Not calling it 2.0 means it's not a first
 release from a fresh development branch. That will carry the message
 along that FOP is stable and usable in a productive environment. Hell,
 it's used in production by so many people for so many years.
 OhpointXitis is really bad.
 
 I know we still have about one item left on our pre-1.0 list:
 http://wiki.apache.org/xmlgraphics-fop/ReleasePlanning
 But that's still going to take a while. I want to revisit this list and
 see what today's view is.
 
 Flame away.
 
 Jeremias Maerki
 




Jeremias Maerki

Re: svn commit: r713747 [1/4] - in /xmlgraphics/fop/branches/Temp_AFPGOCAResources/src: documentation/content/xdocs/trunk/ java/META-INF/services/ java/org/apache/fop/afp/ java/org/apache/fop/afp/font