I think Eclipse doesn't use JEditorPane but own component. GUI editors has monospaced fonts to provide equal width/height for each char and one fixed height for all lines. That's much easier than handle multiple font sizes in the same row.
I have had limited success with character font sizes 20 and below. Above 20 introduces a scaling issue that I hadn't noticed before, mostly because I didn't test that thinking that non of my customers would ever want a font size that big. Above 20 the GlyphPainter1 does some strange scaling and also prervaricates on the text line height. It appears that I can strike a compromise by limiting the font sizes the customer can choose.
I am using a combination of methods in the line height analysis:
VERTICAL_LINE_METRICS lm = new VERTICAL_LINE_METRICS(vMetric); //get current metric as default
LabelView lv = (LabelView)child;
float fHeight = lv.getPreferredSpan(View.Y_AXIS);
GlyphPainter gp = lv.getGlyphPainter();
lm.Ascent = (int)gp.getAscent(lv); //Intentionally truncate float value.
lm.Descent = (int)gp.getDescent(lv); //Intentionally truncate float value.
lm.Preferred = (int)fHeight;
The VERTICAL_LINE_METRICS is a structure to hold the three line height metric values. If I detect the i18n state then I use the shim function code below. I size the List cell to the preferred height from getPreferredSpan(View.Y_AXIS) and shim the text area to that size.
Style style = oPane.getLogicalStyle();
int iADiff = vRomanRef.Ascent - vMetric.Ascent;
int iDDiff = vRomanRef.Descent - vMetric.Descent;
int iDelta = 0;
if ((iADiff + iDDiff) > 0) iDelta = vMetric.Preferred - vMetric.height(); //Preferred may be greater than actual.
if (iDelta > 0) iDDiff -= iDelta;
So far, testing indicates that it works. I haven't tested it on multiple displays or other operating systems yet. I am not real confident that it will be robust since it is a Kluge. It is a shame that I have to use this Hack approach but I really couldn't find anything that helped. Maybe in some future release of Java someone will consider implementing a Font.getLineHeight() method that follows what is on the screen.
For anyone who reads this discussion thread, the proposed fix does not work. Testing with other font families demonstrated that the proposed code does not shim the displayed region correctly. Ultimately, the correct approach may turn out to be using a monospaced font. When I have time I will investigate this and post back an update.