since I have not actually followed the code:


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.


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
>> ( to view the
>> output.
>> [1]
>> +1 from me.
>> Adrian.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to