I'm not sure I understand the whole problem, yet (symptoms and all), but
I agree that the multiplicator doesn't look right. What confuses me is
that you mention configuration of custom fonts in userconfig.xml. This is
currently not implemented in FOP Trunk. Still, even when using default
fonts like "serif" I can currently see problems like text overflowing
the content area.

I think the bigger problem here is that the Java2D/AWT renderer of FOP
Trunk is not as mature, yet, as the PDF and PS renderers. Even simple
things like justifying text doesn't work. If you could help us improve
the Java2D renderer, that would be great. I might eventually get to
improving it but probably not in the next few weeks.

Anyway, thank you for making us aware of this issue. The width factory
seems to be in there since the very beginning:

That was during JDK 1.2 times. Java2D and AWT have improved a lot since.
Maybe the problem that lead to this factor is simply to apparent anymore
today in the current Java versions. If the output looks good, then IMO
the factor can be removed.

On 07.04.2006 19:07:51 Chris Dail wrote:
> I found a bit of an issue with the AWT Renderer when using font metrics.
> The test was originally set up using the TIFF renderer and FOP 0.20.5. I
> have looked into the code and found the same problem in the FOP 0.20.5
> branch and the FOP 1.0 branch.
> The problem I am seeing is that sometimes lines that are supposed to be
> justified across the page have the last word wrapped to the next line. I
> am using the Arial font by setting it in the userconfig.xml. The Arial
> font is the standard one that comes with windows and I have generated
> metrics for this font. Note that the problem does not occur if you do
> not map the Arial font. The text with the problem is using the Arial
> font.
> For example, in a document flow, some lines would have one word from the
> line
> flow
> on to the next line much like the previous line. If the same .fo is
> renderered as a
> PDF document, the entire line appears on one line with no wrapping.
> I traced through to find out where the problem was. In the
> org.apache.fop.render.awt.AWTFontMetrics class on line 233 the following
> fudge factor is applied to character widths of space and below. The code
> reads as follows:
>         // The following was left in based on this comment from the past
> (may be vestigial)
>         // the output seems to look a little better if the
>         // space is rendered larger than given by
>         // the FontMetrics object
>         if (i <=32) {
>           dWidth = dWidth * 1.4;
>         }
> Line 195 in the org.apache.fop.render.java2d.Java2DFontMetrics has the
> same issue with the following code:
>         // the output seems to look a little better if the
>         // space is rendered larger than given by
>         // the FontMetrics object
>         if (i <= 32) {
>             w = (int)(1.4 * fmt.charWidth(i) * FONT_FACTOR);
>         } else {
>             w = (int)(fmt.charWidth(i) * FONT_FACTOR);
>         }
> If this dWidth * 1.4 is removed, the document renders correctly. After
> trying this, I went back to the original and the space character did
> seem to be too wide.
> My question is what was the reason for multiplying the width by 1.4 for
> the space characters and lower? I believe this should not be done but am
> not sure of the impact if I do remove it. I think this should be filed
> as a bug.
> Thanks for your help
> Chris Dail
> Whitehill Technologies

Jeremias Maerki

Reply via email to