Renaud Richardet wrote (in Bugzilla):

>            Summary: [Patch] current AWTRenderer
>            Product: Fop
>            Version: 1.0dev


> = Points I would like to discuss (see the corresponding FIXME 
> in the code) =
> Fonts: I must be missing something with the font-mechanism: 
> the rendered text in the AWTRenderer is smaller that the one 
> of PDFRenderer. What I need is a way to get a java.awt.Font 
> from an area. 
> Is the class FontSetup implemented correctly? Do I have to 
> worry about multibyte-stuff?
> I could investigate the whole mechanism, but a hint would 
> certainly speed my work.

Here are some things that may help:

1. FOray has factored the FOP font logic into a separate module, cleaned it
up significantly, and made some modest improvements. A few weeks ago, I
aXSL-ized it as well, which means that it is written to a (theoretically)
independent interface:

I say "theoretically" because the aXSL interface was simply extracted from
the FOray code, and FOray is almost certainly the only aXSL implementation
available ATM. The point is that someone *could* write another aXSL
implementation that would work seamlessly with FOP. The only cost would be
the instantiation of the brand X FontServer implementation instead of the
FOray FontServer implementation.

I think there is general support within FOP to implement the FOray/aXSL font
work in the FOP 1.0 code, but so far no one has actually taken the time to
do it. If you get into messing with fonts at all, I highly recommend that
FOray be implemented before doing anything else. I will be happy to support
efforts to that end.

2. The java awt Font-related classes don't give access to the underlying
font file. This causes problems for the PDF renderer, which needs to be able
to embed fonts in its output. Within FOray, the major distinction within the
fonts is whether they are FreeStanding or System (awt) fonts. Embedding
requires FreeStanding. AWT Renderer requires System fonts. There is some
hope of merging the two at some time in the future, by using
java.awt.Font.createFont method to create the AWT font from the
application's (i.e. FOP/Folio/FOray) font registration system. However Java
1.3 & 1.4 only support TrueType fonts in this method, and 1.5 only adds
support for Type1, so there are some built-in limitations. (FOrayFont
doesn't support OpenType either, but it is very feasible to add that

3. There are no doubt substantial improvements that can be made to the way
aXSL/FOray handle the System font issue. I would be glad for someone who
actually uses this aspect of the font system (I don't) to comment on it and
suggest improvements.

With the above as some background, I'll try to answer your questions:

> the rendered text in the AWTRenderer is smaller that the one 
> of PDFRenderer.

Some possibilities are 1) because of the dichotomy of the registration and
selection of the fonts, you can actually be using different fonts for layout
and rendering, 2) to the extent that the AWT renderer uses AWT to do the
layout/rendering, there are bound to be differences between that and the way
FOP does it. I wouldn't have expected font sizes to be a big issue, so maybe
there is something else at work here as well.

> What I need is a way to get a java.awt.Font  from an area. 

The aXSL Font interface java.awt.Font getAWTFont(FontConsumer consumer, int
fontSize) method. If the font is a System font, it will return the AWT font
to you. The trick for you then is to be able to get the aXSL font instance
out of the FOP FOTree or AreaTree. I'll defer to the FOP developers to tell
you how to get that done.

> Is the class FontSetup implemented correctly?

It depends upon what you mean by "correctly". Like so many other things in
FOP, it kind of works, but is very difficult to improve because of the
underlying design. It is what evolved into the FontServer class in aXSL and
FOray. Much of its data is static, which causes problems when running
multiple documents in multiple threads (fixed in FOray). That may not be an
issue for an AWT renderer, but is an issue when trying to develop a general
solution that will also work for other renderers.

IMO, the whole font subsystem had evolved into an unmanageable mess that
needed a serious cleanup. However, that really is just an opinion.

> Do I have to worry about multibyte-stuff?

For screen display and java printing, I don't think so, since that is all
handled by AWT.

> I could investigate the whole mechanism, but a hint would 
> certainly speed my work.

I am a FOP outsider these days, so maybe one of the committers can add some
more insight.

> I implemented a simple .bmp rendering ( It 
> only supports 8-bit and 24-bit uncompressed windows bitmap 
> images. I found this code on the net. I know you had problems 
> with licences and I don't want to raise an issue here. I did 
> this implementation more for myself than anything. If there's 
> a better way to render .bmp (JAI?), let me know. Otherwise, I 
> could try to convince the author to donate the code in 
> conterpart of some fine chocolate :)

FOP 0.20.5 handles BMP images OK. Looking at the FOP trunk code right now,
there is a BmpImage class in package "image" and a BMPReader class in
image.analyzer, so I am not sure what you mean here.

Victor Mote

Reply via email to