Mailing-List: contact fop-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xmlgraphics.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AWT Renderer FontMetrics Bug and Analysis
Date: Mon, 10 Apr 2006 08:43:53 -0300
Message-ID: <B66212ECFA57E747AB97EA53B1D37FE039019C@s-wh004.whitehill.net>
Thread-Topic: AWT Renderer FontMetrics Bug and Analysis
Thread-Index: AcZb1D0FZiHBuB3TR1uRgjIP9FaqHgAvYHSg
From: "Chris Dail" <CDail@whitehilltech.com>
To: <fop-dev@xmlgraphics.apache.org>

Sorry for the confusion around the custom fonts in userconfig.xml. The
testing I was doing was all with FOP 0.20.5. I mentioned that I the
problem also existed in the 1.0 branch. I did not test it with 1.0 but
examined the equivalent code of the in 0.20.5 and 1.0 that seemed to
cause my problem in 0.20.5.

I mentioned the userconfig and custom fonts because that was the only
way I was able to produce the problem (in 0.20.5). I'm glad you were
able to reproduce it using the defaults in the trunk. The output from
the new code looks good so I am going to continue using it without the
multiplicator.

Thanks for the help

Chris

-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]=20
Sent: Sunday, April 09, 2006 9:50 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: AWT Renderer FontMetrics Bug and Analysis

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:
http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/src/org/apache/f
op/render/awt/AWTFontMetrics.java?rev=3D193823&view=3Dmarkup

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=20
> 0.20.5 branch and the FOP 1.0 branch.
>=20
> The problem I am seeing is that sometimes lines that are supposed to=20
> be justified across the page have the last word wrapped to the next=20
> line. I am using the Arial font by setting it in the userconfig.xml.=20
> The Arial font is the standard one that comes with windows and I have=20
> generated metrics for this font. Note that the problem does not occur=20
> if you do not map the Arial font. The text with the problem is using=20
> the Arial font.
>=20
> For example, in a document flow, some lines would have one word from=20
> the line flow on to the next line much like the previous line. If the=20
> same .fo is renderered as a PDF document, the entire line appears on=20
> one line with no wrapping.
>=20
> I traced through to find out where the problem was. In the=20
> org.apache.fop.render.awt.AWTFontMetrics class on line 233 the=20
> following fudge factor is applied to character widths of space and=20
> below. The code reads as follows:
>=20
>         // The following was left in based on this comment from the=20
> past (may be vestigial)
>        =20
>         // the output seems to look a little better if the
>         // space is rendered larger than given by
>         // the FontMetrics object
>        =20
>         if (i <=3D32) {
>           dWidth =3D dWidth * 1.4;
>         }
>=20
> Line 195 in the org.apache.fop.render.java2d.Java2DFontMetrics has the

> same issue with the following code:
>=20
>         // the output seems to look a little better if the
>         // space is rendered larger than given by
>         // the FontMetrics object
>         if (i <=3D 32) {
>             w =3D (int)(1.4 * fmt.charWidth(i) * FONT_FACTOR);
>         } else {
>             w =3D (int)(fmt.charWidth(i) * FONT_FACTOR);
>         }
>=20
> 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=20
> seem to be too wide.
>=20
> My question is what was the reason for multiplying the width by 1.4=20
> for the space characters and lower? I believe this should not be done=20
> but am not sure of the impact if I do remove it. I think this should=20
> be filed as a bug.
>=20
> Thanks for your help
>=20
> Chris Dail
> Whitehill Technologies


Jeremias Maerki