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

[Manuel M. <mm...@ar...>]

On Wed, 4 Jan 2006 04:23 am, Joe Schmetzer wrote:
> On Tue, 2006-01-03 at 20:09 +0800, Manuel Mall wrote:
> > just an update on the situation.
> >
<snip/>
> > 2. Since I checked the code into CVS I have done more work on it
> > and its looking pretty good now in terms of feature support. This
> > includes all the reference orientation stuff, image support,
> > leaders, border styles (not perfect but ok). Even reinstated the
> > first of the extensions (overlay's).
>
> Fantastic! I would be interested to see your changes checked into
> version control. I set up a workspace with the FOP_ALPHA branch of
> the AFP Renderer, along with the trunk from FOP. I found that the
> renderer branch no longer compiled against FOP trunk. I started
> fixing some of the immediate compile errors, but ran out of time in
> the end (blame Christmas, New Year, and various children's birthday
> parties). I realise that it probably would have worked against the
> fop-0_90 branch, but I was interested to see how stable the fop trunk
> was (there are still renderer API changes, as it turned out).

I just checked in the latest version of the renderer into the FOP_ALPHA 
branch. Unless I have accidentally omitted files it should compile 
against the current fop trunk version.

Please note that I have modified the code in prepration of its planned 
integration into the ASF repository. These changes included updating 
the Copyright header to the year 2006, to remove all author tags, and 
to change indentation to 4 characters.

>
> > 3. Had very good results with using the FOP "built-in" font metrics
> > for the standard PDF serif, sans-serif and monospace fonts and
> > mapping those to the appropriate IBM font file names (both the
> > raster and outline versions). The AFP Viewer is perfectly happy
> > with that and renders those documents very accurately. This means
> > the AFP renderer works "out-of-the-box" without having to install
> > IBM fonts on the platform used to generate the AFP file.
>
> That's probably a fairly elegant approach, in the end. I'm still
> fairly unhappy with the font mapping configuration that is required
> for the AFP Renderer, as it is. Anything that improves the
> "out-of-the-box" experience can probably very measurably affect the
> usability of the renderer.

I have attached a sample config file I am using which shows how the font 
mapping is done. This config file is very different to the AFP Renderer 
for 0.20.5 because it integrates the AFP Renderer font configuration 
into the standard fop trunk configuration.

>
> Possibly another strategy we could take would be to pre-process the
> metrics for a number of the most popular commercial fonts, and check
> the results into version control. This could conceivably mean that no
> font configuration would be needed at all, at least for the fonts we
> include.
>

Yes, that is certainly an option. To do that we would need a tool 
similar to the TTF and PFMReader applications that generates a standard 
FOP font metrics file from an AFP font file. As there is already a 
reader for these font files that should not be too difficult to do.

> > Cheers and Happy New Year
>
> Ditto. Thanks for all the hard work!

Manuel