date:20081124

On 24.11.2008 15:50:40 Adrian Cumiskey wrote:
> 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.

Again: it's not the fix that is the problem. It is about
backwards-compatibility and that's an issue mostly for users and release
managers. Developers have an easy life. Imagine what would happen if
Linus Torvalds would constantly change the API for low-level drivers or
if Sun would simply change APIs in their Java class library without
respecting backwards compatibility.

> >> 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.

Yeah, and after your logic I'll continue to play that game indefinitely.
Each time we release a new FOP, I have to update my plug-in. That's not
my idea of software development.

> > 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 
> fo

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

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: [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.

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]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

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: 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

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

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

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.

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

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

   Summary: AFP Renderer doesn't handle fixed with spaces, e.g. thin
space  
   Product: Fop
   Version: 0.95
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P4
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


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

This effect is illustrated by the FO in the layout engine test case
block_white-space_4. I have attached the AFP File generated and the PDF for
comparison.


-- 
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] 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.

[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 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.

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. 





-- 
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 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.

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

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;

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