Community
Participate
Working Groups
build I20040519 JavaEditor draws squiggle underline over the string (a.k.a red see). This problem is been caused by SWT. It was introduced when we added italic font support. Here is the situation: The application set a font in the StyledText. Internally StyledText will create 3 more fonts: boldFont, italicFont, boldItalicFont. In order to line up normal, bold, italic, and boldItalic segments of text in the same line StyledText need to compute the max baseline amongs all those fonts. Usually these font have same (or very similar) metrics, but sometimes they are not (example: default font in Solaris). I believe the code that draws the squiggle is getting the normal font from the StyledText, getting its metrics, compute the baseline (ascent+descent), and draws the squiggle at y + baseline. Since this baseline can be less than the maxBaseline it possible that the siggle will be drawn over the text instead of the real baseline where the strings where drawn. Right now we have two solutions: 1) The app code will need to create all the fonts and do the same styledtext is doing. 2) We add getBaseline() to StyledText and app code start to using it instead of getting the line metrics.
StyledText#getBaseline() API added.
The SWT StyledText API change has PMC approval for inclusion in 3.0 M9.
which build will contain this?
Carolyn says it will appear in the 20:00 EDT build.
We adopted the new API for I200405210800. Just one remark: we used gc.getFont().getFontMetric().getHeight() - 1 to draw the squiggly line i.e. always at the bottom. Would using StyledText.getLineHeight() instead also have fixed the problem?
"gc.getFont().getFontMetric().getHeight() - 1" it means you don't draw at the baseline. Height is the ascent+descent+leading. You draw at the bottom of the string. The baseline is ascent+leading. I set the font of the JavaEditor to Tahoma 36 and it seems that the bottom of the squiggle is at lineY + lineHeight. IMO, the top of the squiggle should be at lineY + baseline.
Up to now we actually drew it at the bottom using the code I described. The questions are: - why did this cause the squiggly lines to appear in the text on Solaris - is StyledText.getLineHeight() better than gc.getFont().getFontMetric().getHeight() which we used i.e. if we would have simply replaced this with StyledText.getLineHeight() would this have fixed the problem (still at the bottom though)? We now draw it at the baseline. I simply want to understand why it drew the into the string using gc.getFont().getFontMetric().getHeight() -1 and whether it would have worked using StyledText.getLineHeight(). We use getHeight at several other places and those might be affected then as well.
Created attachment 10942 [details] Picture Top image: the bottom of the squiggle drawn at y + lineHeight Bottom image: the top of the squiggle drawn at y + baseline
- gc.getFont().getFontMetric().getHeight() returns the height of the normal font only. - styledText.getLineHeight() returns the max height of all the fonts used by the styledtext. Yes, you could fix this by using styledText.getLineHeight(). It failed because some OS don't have a lot of fonts so when styledtext create a bold or italic version of the normal font it's possible that these fonts won't have the same height (example: the system don't have a courier-bold-10 so it returns a courier-bold-12) this would cause styledtext to draw its strings a few pixels down so it can line up bold/italic/normal text at the same baseline. Since the squiggle don't know that the text was moved down a few pixels it ends up drawing on the wrong place, potencially over the text.
I guess we should then revisit our code and replace gc.getFont().getFontMetric().getHeight() with StyledText.getLineHeight() where possible, right?
Yes, that would be good.
created bug 63423 for this
Seems to me we could have called getLineHeight() to draw the squiggles in the same place as we used to. Strictly speaking, getBaseline() returns the correct place for them but getLineHeight() would implement approximately the 3.0 behavior. Depending on what Felipe and SSQ think, we could *consider* removing the API.
I don't think so. Sometimes we need to know the line height in order to e.g. draw an icon in the middle of the line or draw the line number ruler.
