[afp-renderer-developers] Re: FOP AFP Renderer

[Manuel M. <ma...@ap...>]

On Wed, 30 Nov 2005 07:35 am, Pete Townsend wrote:
<snip/>

Pete, Joe,

thank you very much for your enthusiastic support of this endeavour. 
Really much appreciated.
 
> Manual, please let me know your SourceForge user name and I'll get
> you added with CVS access to the AFP Renderer Project. I plan to
> create a CVS branch tomorrow evening so that we can get started on
> the migration.
>
My SourceForge id is: malm66

Regarding the port let me give you a heads up on where I am at.

Everything compiles and builds although I have removed the code for the 
0.20.5 extensions.
Basic rendering of blocks and the associated text positioning seems to 
work.
Justified text seems to work.
Coloured texts and text decorations (underline, overstrike, ...) etc. 
work.
Borders, padding and background colours work but differently to the 
0.20.5 renderer. I am using PTOCA line drawing primitives to create 
those not shaded graphics areas as the 0.20.5 renderer does.
I started adding image support based on IOCA but so far only had success 
with TIFF images. Although IOCA does support jpeg natively at least the 
AFP Viewer doesn't seem to like it. And the same for storing raw 
images. It seems the decompressed bitmaps returned by the Java 
libraries are not quite what IOCA expects.

What still needs to be done = a lot:

1. Keeping the whole document in memory and writing it out at the end 
doesn't scale well for large documents. The getDataStream interfaces 
probably could be replaced by a writeDataStream(OutputStream) type 
interface and the stream could probably be written on each endPage 
call. However, there are some page out of order rendering issues 
related to markers / page numbers which may require buffering, that is 
if page n is complete but page n-1 is not we have to wait writing page 
n until all it predecessors are written.

2. Haven't done leaders yet.

3. As borders (and leaders) are created using line drawing primitives 
leader/border styles like dotted, double, ... need to be programmed

4. Haven't looked at the whole reference area orientation stuff yet. 
MO:DCA does support changes in the co-ordinate system so we probably 
need to map the CTM matrix used by FOP to describe co-ordinate 
transformations into the appropriate MO:DCA structures.

5. Sort out the image support.

6. Integrate the raster fonts including their configuration etc. into 
the overall FOP font system (probably do that after FOray font 
integration is done).

7. Port the 0.20.5 AFP FOP extensions

8. Add support for svg

There is probably more I just can't remember at the moment.

But it should give you guys an idea were I am at.

> I can also contact Terrapin to see if they would be prepared to grant
> a the fonts under an AFP license and sign a CLA. They were quite
> helpful when I contacted them before - Alternatively someone from ASF
> could try IBM (they weren't too interested when it was just me!)  for
> a small open source font library?

If we can't get fonts under ASF license we may have to do the same as 
for our hyphenation patterns - keep them in a separate repository under 
SourceForge and just point to them. Obviously they are already in the 
SourceForge afp-renderer project so there is not much else to do.

The later version of AFP does support TrueType fonts (although I assume 
most of the installed AFP equipment won't). But by adding support for 
this to the AFP Renderer we may have at least a version that works 
'out-of-the-box'.

> Regards, Pete.
>

Cheers

Manuel