Heads up:

Unfortunately, the saga continues....

The change to AWTRenderer that I recently submitted does indeed
fix problems with -awt but as a side effect, it introduces new
problems with printing.   For example, if you render a page via -awt
(with the changed code) the rendition looks fine; then, if you print
it directly from the -awt dialog (via menubar) you get some words
overlapping one another on a given line.  You get the same overlapping
by going directly to the printer via -print.

Just to keep it fun: not all fonts, nor all sizes fail.  I suspect the
results may differ by platform and printer too !

I am researching the bug parade and java groups like crazy
to find a way through this -- So far, I've learned there ~is~ a
known inconsistency (apparently since jdk 1.3.0) between
the jre's use of screen fonts vs printer fonts. One Sun bug
evaluator mentions that Swing's caching of fonts is also a

This affects fop because we does our printing via a subclass
of the awt renderer.

The simplest way to explain what is happening is this:

draw a string into a graphics2D that will be printed
then draw a rectangle using the rectangle returned 
by   <FontMetrics>.getVisibleBounds

In many cases the bounding rectangle does not match the drawn
text.  The bounding rectangle is usually shorter than the drawn text -
- the end result in fop, is that words overlap.  The mismatch is a
function of font -- and even worse -- also seems to depend
on recent font usage (jre caching?)

btw: In my testing, the actual bounding rectangle returned by
getVisibleBounds() seems to match the internal spacings derived
in and used by the fop layout engine - so this appears to be an
actual printing problem, not a metrics problem.


At 04:13 AM 5/17/02, you wrote:
>Hi all
>Great work Ralph.
>The results looks very good and I hope the next release contains your fix.
>I've and additional wish for the AWTRenderer.
>Can anyone make the 'graphic' variable protected, to enable sublasses to
>draw on it?
>In my case I have to divide between final print and test print (crisscross
>the page and draw a test string on it). At this time I have to do it twice
>(without patching original sources). Firtsly at renderPage(Page) where I
>create my own Graphics2D instance after  super.renderPage(Page) has finished
>and secondly on print with the passed in Graphics2D parameter.
>I think programmer who subclass the original know that they have to work
>with the graphics variable careful and are responsible for their own
>mistakes. Therefore I don't see a reason to hold the instance restrictively
>with private access.
>ThanX a lot (especially to ralph for the fix)
>cu Torsten
> > -----Original Message-----
> > From: Ralph LaChance [mailto:[EMAIL PROTECTED]]
> > Sent: Donnerstag, 16. Mai 2002 17:05
> > Subject: RE: Font Metrics AWT
> >
> >
> > I have found the problem and worked out its repair.
> > The modified code is attached below.
> >
> > The problem stems from a bug in java's handling of drawing of
> > AttributedStrings when a font attribute is specified.   Bug parade
> > #4650042 describes a similar problem unique to jdk 1.4, but
> > makes also suggests that there are other more general problems
> > w/ fonts and AttributedStrings.
> >
> > In our case, calling
> > drawString (string....) instead of
> > drawString (AttributedString...) solves the problem.
> >
> > The fix simply draws the text using the string version of
> > drawString and then to draw the underline (if defined)
> > separately.
> >
> > I have tested it on jre 1.3.0, jre 1.3.0_02 and jre/jdk 1.4.0 -
> > all on WinNT4/sp5
> >
> > attached is the changed code -- it only affects one method
> > in AWTRenderer.
> >
> > Will someone commit it ?
> >
> >
> >
> >
> >          ' Best,
> >          -Ralph LaChance
> >
> >
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to