You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Adrian Cumiskey <de...@cumiskey.com> on 2008/11/24 15:08:23 UTC
[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.
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 25.11.2008 09:28:18 Jeremias Maerki wrote:
> On 24.11.2008 16:11:00 Adrian Cumiskey 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/%3c20081124101443.78AE.60BA733C@jeremias-maerki.ch%3e
> > >
> > >
> > > 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 :).
>
> Let's look at that. There are:
>
> AFPImageHandlerRawCCITTFax handling ImageRawCCITTFax.class, priority 400
> AFPImageHandlerRawStream handling ImageRawJPEG.class, ImageRawCCITTFax.class, ImageRawEPS.class, priority 100
> AFPImageHandlerRenderedImage handling ImageBuffered.class, ImageRendered.class, priority 300
>
> ImageBuffered is also a ImageRendered, so reporting the handling of
> ImageBuffered is unnecessary.
> ImageRawJPEG, ImageRawCCITTFax and ImageRawEPS all derive from
> ImageRawStream. Just reporting that class as supported class would have
> been enough. The ImageFlavors are there to indicate what formats are
> supported.
>
> Essentially, that means that the interface change was unnecessary. And
> is the AFPImageHandlerRawCCITTFax even used? It has a lower priority
> than AFPImageHandlerRawStream.
>
> So it seems that actually offers up an additional opportunity to resolve
> the whole problem. A shame I haven't taken a closer look earlier. I
> volunteer to revert the interface change and to change the plug-ins here
> so they still work as envisioned. That minimizes the regression testing
> necessary. After that, I'll vote +1 for the merge.
>
I have locally changed "Class[] getSupportedClasses()" to
"getSupportedClass()" and everything seems to work as before. The only
thing I noticed is still AFPImageHandlerRawCCITTFax used because if
reports support for ImageRawCCITTFax.class and is therefore picked
before the more generic raw stream handler. I tried removing the CCITT
handler but then get a fatal error in AFP Worbench whereas I get an
empty space but no error message when the CCITT handler is active. I
assume AFP Workbench doesn't support CCITT images. Unfortunately, I have
no AFP printer to test with. I assume it would be best to remove the
CCITT flavor from the raw stream handler. Adrian, if you can confirm my
assumptions here, I can commit my changes and we've got one problem
fixed.
Jeremias Maerki
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 25.11.2008 13:27:19 Adrian Cumiskey wrote:
> Jeremias,
>
> Jeremias Maerki wrote:
> >>> 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 :).
> >
> > Let's look at that. There are:
> >
> > AFPImageHandlerRawCCITTFax handling ImageRawCCITTFax.class, priority 400
> > AFPImageHandlerRawStream handling ImageRawJPEG.class, ImageRawCCITTFax.class, ImageRawEPS.class, priority 100
> > AFPImageHandlerRenderedImage handling ImageBuffered.class, ImageRendered.class, priority 300
> >
> > ImageBuffered is also a ImageRendered, so reporting the handling of
> > ImageBuffered is unnecessary.
> > ImageRawJPEG, ImageRawCCITTFax and ImageRawEPS all derive from
> > ImageRawStream. Just reporting that class as supported class would have
> > been enough. The ImageFlavors are there to indicate what formats are
> > supported.
>
> Just reporting the ImageRawStream as a supported class is risky as AFP is not guaranteed to support
> all natively embedded all (raw) object types, only the fixed list of ones that are registered in the
> MOD:CA Registry.
The image flavors are there for that. They are what's used to determine
which image instance the image loading framework shall produce. If the
set of supported flavors matches the available image handlers, there's
no problem.
> > Essentially, that means that the interface change was unnecessary. And
> > is the AFPImageHandlerRawCCITTFax even used? It has a lower priority
> > than AFPImageHandlerRawStream.
> >
> > So it seems that actually offers up an additional opportunity to resolve
> > the whole problem. A shame I haven't taken a closer look earlier. I
> > volunteer to revert the interface change and to change the plug-ins here
> > so they still work as envisioned. That minimizes the regression testing
> > necessary. After that, I'll vote +1 for the merge.
>
> I have found an alternative solution that does not involve the method signature change in the
> PDFImageHandler interface, so you won't need to release a new plugin. I will take care of this.
Thanks. Work done twice but so be it.
Jeremias Maerki
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Adrian Cumiskey <de...@cumiskey.com>.
Jeremias,
Jeremias Maerki wrote:
>>> 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 :).
>
> Let's look at that. There are:
>
> AFPImageHandlerRawCCITTFax handling ImageRawCCITTFax.class, priority 400
> AFPImageHandlerRawStream handling ImageRawJPEG.class, ImageRawCCITTFax.class, ImageRawEPS.class, priority 100
> AFPImageHandlerRenderedImage handling ImageBuffered.class, ImageRendered.class, priority 300
>
> ImageBuffered is also a ImageRendered, so reporting the handling of
> ImageBuffered is unnecessary.
> ImageRawJPEG, ImageRawCCITTFax and ImageRawEPS all derive from
> ImageRawStream. Just reporting that class as supported class would have
> been enough. The ImageFlavors are there to indicate what formats are
> supported.
Just reporting the ImageRawStream as a supported class is risky as AFP is not guaranteed to support
all natively embedded all (raw) object types, only the fixed list of ones that are registered in the
MOD:CA Registry.
> Essentially, that means that the interface change was unnecessary. And
> is the AFPImageHandlerRawCCITTFax even used? It has a lower priority
> than AFPImageHandlerRawStream.
>
> So it seems that actually offers up an additional opportunity to resolve
> the whole problem. A shame I haven't taken a closer look earlier. I
> volunteer to revert the interface change and to change the plug-ins here
> so they still work as envisioned. That minimizes the regression testing
> necessary. After that, I'll vote +1 for the merge.
I have found an alternative solution that does not involve the method signature change in the
PDFImageHandler interface, so you won't need to release a new plugin. I will take care of this.
Adrian.
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 24.11.2008 16:11:00 Adrian Cumiskey 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/%3c20081124101443.78AE.60BA733C@jeremias-maerki.ch%3e
> >
> >
> > 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 :).
Let's look at that. There are:
AFPImageHandlerRawCCITTFax handling ImageRawCCITTFax.class, priority 400
AFPImageHandlerRawStream handling ImageRawJPEG.class, ImageRawCCITTFax.class, ImageRawEPS.class, priority 100
AFPImageHandlerRenderedImage handling ImageBuffered.class, ImageRendered.class, priority 300
ImageBuffered is also a ImageRendered, so reporting the handling of
ImageBuffered is unnecessary.
ImageRawJPEG, ImageRawCCITTFax and ImageRawEPS all derive from
ImageRawStream. Just reporting that class as supported class would have
been enough. The ImageFlavors are there to indicate what formats are
supported.
Essentially, that means that the interface change was unnecessary. And
is the AFPImageHandlerRawCCITTFax even used? It has a lower priority
than AFPImageHandlerRawStream.
So it seems that actually offers up an additional opportunity to resolve
the whole problem. A shame I haven't taken a closer look earlier. I
volunteer to revert the interface change and to change the plug-ins here
so they still work as envisioned. That minimizes the regression testing
necessary. After that, I'll vote +1 for the merge.
Jeremias Maerki
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 24.11.2008 16:50:48 Adrian Cumiskey wrote:
> 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.
Again: this is done for the renderers which are likely to become less
important (the majority even deprecated) in the future when the new IF
branch is finished. The new IF branch already contains an ImageHandler
interface which already serves all output formats. I suggest that be
reviewed and tuned for long-term service. That, together with the image
loader framework, represents a very flexible mechanism to handle and
convert all sorts of images and functionality and for all output formats.
> 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.
Partially agreed, although the AbstractFOPTextPainter is a dead end, I'm
afraid. It only works for the simple cases. To paint almost all text as
shapes, something like the current PDFTextPainter has to be developed.
> 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 <de...@cumiskey.com> 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/%3c20081124101443.78AE.60BA733C@jeremias-maerki.ch%3e
> >>>
> >>>
> >>>
> >>> 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.
> >>
> >
> >
Jeremias Maerki
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Adrian Cumiskey <de...@cumiskey.com>.
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 <de...@cumiskey.com> 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/%3c20081124101443.78AE.60BA733C@jeremias-maerki.ch%3e
>>>
>>>
>>>
>>> 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
Posted by The Web Maestro <th...@gmail.com>.
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 <de...@cumiskey.com> 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/%3c20081124101443.78AE.60BA733C@jeremias-maerki.ch%3e
>>
>>
>>
>> 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
--
<th...@gmail.com> - <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
Posted by Adrian Cumiskey <de...@cumiskey.com>.
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/%3c20081124101443.78AE.60BA733C@jeremias-maerki.ch%3e
>
>
> 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
Posted by Chris Bowditch <bo...@hotmail.com>.
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/%3c20081124101443.78AE.60BA733C@jeremias-maerki.ch%3e
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: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
Andreas Delmelle wrote:
<snip />
> OTOH, I feel compelled to mention that attempting to kill a raised,
> perfectly legitimate issue in an unreasonable way (by taking it to be
> a personal offense), may alienate some people...
That said, I would myself probably take it as a personal offence too if
I were told “I wonder if you’ve spent one second thinking about...” or
if I were accused of “after me the flood” mentality. If Adrian certainly
didn’t handle the situation perfectly, neither did Jeremias.
In the end, I go along with Chris when reminding that e-mail is a cold
form of communication, which more than any other form should encourage
/everyone/ to make an effort to remain courteous. Trying hard to
understand the other’s point of view before replying may help, too. The
thread leaves me with a whole feeling of misunderstandings.
<snip/>
Vincent
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Adrian Cumiskey <de...@cumiskey.com>.
Jeremias Maerki wrote:
> On 25.11.2008 21:55:49 Adrian Cumiskey wrote:
> <snip/>
>> OTOH, I feel compelled to mention that attempting to kill a raised,
>>> perfectly legitimate issue in an unreasonable way (by taking it to be a
>>> personal offense), may alienate some people...
>>> From a diplomatic viewpoint, not a very sound move to make right before you
>>> decide to launch a vote. :/
>>
>> I wasn't in anyway trying to kill the raised issue, I just chose the option
>> that I believed at the time would involve the least amount of change and
>> provide the quickest solution to the problem. I believe now that all
>> interested parties should feel satisfied with the concluding result to issue
>> raised.
>
> I think that's the problem: you chose, instead of discussing ideas and
> plans that may be non-trivial or controversial on the mailing list. My
> wish is that you try more to detect things like that. Sometimes it's
> just a matter of dropping a mail on the list saying you wish to change
> this and that because of X or Y. Even if noone responds (which is
> unlikely), you have at least lazy consensus.
At the time I did not see it as a big issue, but now I am more aware that something which may not
seem a like a biggie to me, may cause a big itch to someone else. So I'll try to keep this
consideration more in mind going forward.
> Apparently, my wording was too strong which was only to get you to
> listen. This is probably an expression of my inability to communicate
> what I was trying to get across. For that I apologize and I will keep
> trying to keep my tone in check.
Apology accepted, lets move on from this now and try to get back to some software development.
Adrian.
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 25.11.2008 21:55:49 Adrian Cumiskey wrote:
<snip/>
> OTOH, I feel compelled to mention that attempting to kill a raised,
> > perfectly legitimate issue in an unreasonable way (by taking it to be a
> > personal offense), may alienate some people...
> > From a diplomatic viewpoint, not a very sound move to make right before you
> > decide to launch a vote. :/
>
>
> I wasn't in anyway trying to kill the raised issue, I just chose the option
> that I believed at the time would involve the least amount of change and
> provide the quickest solution to the problem. I believe now that all
> interested parties should feel satisfied with the concluding result to issue
> raised.
I think that's the problem: you chose, instead of discussing ideas and
plans that may be non-trivial or controversial on the mailing list. My
wish is that you try more to detect things like that. Sometimes it's
just a matter of dropping a mail on the list saying you wish to change
this and that because of X or Y. Even if noone responds (which is
unlikely), you have at least lazy consensus.
Apparently, my wording was too strong which was only to get you to
listen. This is probably an expression of my inability to communicate
what I was trying to get across. For that I apologize and I will keep
trying to keep my tone in check.
Jeremias Maerki
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by The Web Maestro <th...@gmail.com>.
+1 from me!
Thanks for your hard work!
Clay
On 11/26/08, Chris Bowditch <bo...@hotmail.com> wrote:
> Adrian Cumiskey wrote:
>
> Hi Adrian,
>
>> Hi Andreas,
>>
>> 2008/11/25 Andreas Delmelle <andreas.delmelle@telenet.be
>> <ma...@telenet.be>>
>>
>> Adrian, just a small FWIW: Chris has drawn the right conclusion, I
>> think. No need to take any of the questions/remarks personal (even
>> though I understand this is difficult after the time you've spent on
>> perfecting the code in that branch).
>>
>>
>> Its not been so much perfecting, its been more a matter of trying to
>> clean up the mess that I inherited, trying to eliminate as much
>> copy/paste, hardcoded definitions as possible and reuse existing
>> functionality where possible without breaking anything. This was
>> confounded by the strict binary data structure of AFP, extensive and
>> somewhat ambiguous documentation, and generally poor availability of
>> datastream analysis tools.
>
> and your efforts are appreciated even though our questions may make us
> seem ungrateful at times :)
>
>>
>> OTOH, I feel compelled to mention that attempting to kill a raised,
>> perfectly legitimate issue in an unreasonable way (by taking it to
>> be a personal offense), may alienate some people...
>> >From a diplomatic viewpoint, not a very sound move to make right
>> before you decide to launch a vote. :/
>>
>>
>> I wasn't in anyway trying to kill the raised issue, I just chose the
>> option that I believed at the time would involve the least amount of
>> change and provide the quickest solution to the problem. I believe now
>> that all interested parties should feel satisfied with the concluding
>> result to issue raised.
>
> Yes I am now very happy and pleased to give my +1 to this vote.
>
> Thanks,
>
> Chris
>
>
>
--
Regards,
The Web Maestro
--
<th...@gmail.com> - <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
Posted by Chris Bowditch <bo...@hotmail.com>.
Adrian Cumiskey wrote:
Hi Adrian,
> Hi Andreas,
>
> 2008/11/25 Andreas Delmelle <andreas.delmelle@telenet.be
> <ma...@telenet.be>>
>
> Adrian, just a small FWIW: Chris has drawn the right conclusion, I
> think. No need to take any of the questions/remarks personal (even
> though I understand this is difficult after the time you've spent on
> perfecting the code in that branch).
>
>
> Its not been so much perfecting, its been more a matter of trying to
> clean up the mess that I inherited, trying to eliminate as much
> copy/paste, hardcoded definitions as possible and reuse existing
> functionality where possible without breaking anything. This was
> confounded by the strict binary data structure of AFP, extensive and
> somewhat ambiguous documentation, and generally poor availability of
> datastream analysis tools.
and your efforts are appreciated even though our questions may make us
seem ungrateful at times :)
>
> OTOH, I feel compelled to mention that attempting to kill a raised,
> perfectly legitimate issue in an unreasonable way (by taking it to
> be a personal offense), may alienate some people...
> >From a diplomatic viewpoint, not a very sound move to make right
> before you decide to launch a vote. :/
>
>
> I wasn't in anyway trying to kill the raised issue, I just chose the
> option that I believed at the time would involve the least amount of
> change and provide the quickest solution to the problem. I believe now
> that all interested parties should feel satisfied with the concluding
> result to issue raised.
Yes I am now very happy and pleased to give my +1 to this vote.
Thanks,
Chris
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Adrian Cumiskey <de...@cumiskey.com>.
Hi Andreas,
2008/11/25 Andreas Delmelle <an...@telenet.be>
>
> Adrian, just a small FWIW: Chris has drawn the right conclusion, I think.
> No need to take any of the questions/remarks personal (even though I
> understand this is difficult after the time you've spent on perfecting the
> code in that branch).
Its not been so much perfecting, its been more a matter of trying to clean
up the mess that I inherited, trying to eliminate as much copy/paste,
hardcoded definitions as possible and reuse existing functionality where
possible without breaking anything. This was confounded by the strict
binary data structure of AFP, extensive and somewhat ambiguous
documentation, and generally poor availability of datastream analysis tools.
OTOH, I feel compelled to mention that attempting to kill a raised,
> perfectly legitimate issue in an unreasonable way (by taking it to be a
> personal offense), may alienate some people...
> From a diplomatic viewpoint, not a very sound move to make right before you
> decide to launch a vote. :/
I wasn't in anyway trying to kill the raised issue, I just chose the option
that I believed at the time would involve the least amount of change and
provide the quickest solution to the problem. I believe now that all
interested parties should feel satisfied with the concluding result to issue
raised.
Adrian.
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Andreas Delmelle <an...@telenet.be>.
On Nov 24, 2008, at 15:08, Adrian Cumiskey wrote:
> I would like to call for a merge of the AFP branch [1] back into
> trunk.
<snip />
If the issue as discussed in the parallel thread is ironed out, I see
no reason why not.
+1 in that case.
Adrian, just a small FWIW: Chris has drawn the right conclusion, I
think. No need to take any of the questions/remarks personal (even
though I understand this is difficult after the time you've spent on
perfecting the code in that branch).
If you ever have doubts about the respect that other fop-devs have
for your work, I think everyone would agree that your font-detection
package and the FontCache are amongst the major enhancements to have
been added in the past couple of releases together. No need to worry
there. If I judge correctly, the work in the AFP branch could very
well go the same route.
OTOH, I feel compelled to mention that attempting to kill a raised,
perfectly legitimate issue in an unreasonable way (by taking it to be
a personal offense), may alienate some people...
From a diplomatic viewpoint, not a very sound move to make right
before you decide to launch a vote. :/
As the vote indicates, no offense or disrespect intended.
Thanks a lot for your continued efforts, making FOP an even better
product!
Cheers
Andreas
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Adrian Cumiskey <de...@cumiskey.com>.
Hi all,
I think all the votes are probably in now so I'll be taking care of the
merge a little later. I hope some people are able to make good use of the
new AFP features, and also the cleanups I've made make it a little easier
for others to contribute. Its been fun :).
Adrian.
2008/11/27 J.Pietschmann <j3...@yahoo.de>
> On 27.11.2008 16:33, Max Berger wrote:
>
>> The recent amount of discussion shows that your branch should be
>> integrated into trunk as soon as possible, since it touches other areas
>> as well, and these issues need to be resolved before 1.0beta.
>>
>
> I got the same impression, but I don't know anything about
> the code itself.
> So +0.5 from me too.
>
> J.Pietschmann
>
--
Adrian.
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by "J.Pietschmann" <j3...@yahoo.de>.
On 27.11.2008 16:33, Max Berger wrote:
> The recent amount of discussion shows that your branch should be
> integrated into trunk as soon as possible, since it touches other areas
> as well, and these issues need to be resolved before 1.0beta.
I got the same impression, but I don't know anything about
the code itself.
So +0.5 from me too.
J.Pietschmann
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Max Berger <ma...@berger.name>.
Adrian,
since I have not actually followed the code:
+0.5
The recent amount of discussion shows that your branch should be
integrated into trunk as soon as possible, since it touches other areas
as well, and these issues need to be resolved before 1.0beta.
Max
Vincent Hennebert schrieb:
> Hi Adrian,
>
> I don’t know much about AFP, but from the little I know I fully imagine
> that this must have been all but an easy task.
> I haven’t followed your work closely, but you seem to have put a lot of
> effort to it. Congratulations, and here’s my +1.
>
> Vincent
>
>
> 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
>>
>>
>> +1 from me.
>>
>> Adrian.
>
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Adrian,
I don’t know much about AFP, but from the little I know I fully imagine
that this must have been all but an easy task.
I haven’t followed your work closely, but you seem to have put a lot of
effort to it. Congratulations, and here’s my +1.
Vincent
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
>
>
> +1 from me.
>
> Adrian.