There are three related problems reported in this bug

1. TextComponent.print() is supposed to re-lay out for the printer.
It does this if the text is printed through SwingUtilities2 text methods
but it does not do so if the "i18n" property is set.

Looking at TextLayoutStrategy it gets an FRC for the Container
which I would expect to be updated for the printing case when
the FRC is different. That does not happen so the text is laid
out for the screeen.

Run the attached test case STP1.java and press "Print"
It will print two pages the first *before* setting the i18n property,
the second afterwards. Clearly the text is not laid out for the
printer. The line lengths differ between the two printed pages
and the i18n one looks worse (on paper that is) and the lengths
are clearly for screen resolution.

2. In addition the line spacing differs between the two cases.
Since the test case permanently sets the i18n property on the
component you can see this affects screen layout too. Go back
to the on-screen display and insert a character to cause the
screen text to re-lay out. It jumps vertically as the new
line height is different. So this affects on screen display
*and* printing.

3. Since the FRC is always the screen one then part of the
reason the printed text does not look good is for the
reasons described in bug 6488219. The majority of cases
affected by that bug can be fixed separately but the case that
goes through the code path in TextLayoutStrategy needs
to be fixed as part of this bug.
ie. as part of this fix, apply the same technique so
that when printing but *NOT* using TextComponent.print(),
then the TextLayout still needs to have printer resolution
advances but be justified to the screen width.