This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 56464 - Highlighting row overrides error underline
Summary: Highlighting row overrides error underline
Alias: None
Product: editor
Classification: Unclassified
Component: Painting & Printing (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Miloslav Metelka
: 75371 92254 112174 (view as bug list)
Depends on: 121357
  Show dependency tree
Reported: 2005-03-15 15:03 UTC by Milan Kubec
Modified: 2009-10-16 17:03 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

screenshot (3.30 KB, image/png)
2005-03-15 15:03 UTC, Milan Kubec
screenshot2 (3.30 KB, image/png)
2005-03-15 15:04 UTC, Milan Kubec
Screenshot (17.44 KB, image/png)
2009-05-06 10:32 UTC, akiliyevich
the issue under Linux illustration (5.52 KB, image/png)
2009-09-27 16:12 UTC, anli
another current-row issue illustartion (1.86 KB, image/png)
2009-10-04 23:40 UTC, anli

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Kubec 2005-03-15 15:03:31 UTC
[dev-200503141900, JDK 1.5.0_02]

See attached screenshots, they show how error underline is not partially painted
when user moves row highlight over the error underline. Happens only when moving
caret from top to bottom.
Comment 1 Milan Kubec 2005-03-15 15:03:48 UTC
Created attachment 20848 [details]
Comment 2 Milan Kubec 2005-03-15 15:04:17 UTC
Created attachment 20849 [details]
Comment 3 Vitezslav Stejskal 2007-01-10 23:03:20 UTC
*** Issue 75371 has been marked as a duplicate of this issue. ***
Comment 4 Vitezslav Stejskal 2007-01-10 23:07:46 UTC
*** Issue 92254 has been marked as a duplicate of this issue. ***
Comment 5 cahrens 2007-01-11 14:58:50 UTC
When I run with 1.6, I am seeing problems with both wavy underlines and 
regular underlines on Windows. I think the issue is that the following methods 
return different values in 1.6 vs. 1.5--

fmcInfo.getUnderlineOffset(graphics) (with size 13 Monospaced font on Windows 
XP, .8 with 1.5 JVM and 3.1 with 1.6 JVM)

fmcInfo.getUnderlineThickness(graphics) (1.2 with 1.5 JVM, .55 with 1.6 JVM).

Thus the following code in DrawGraphics's flush method draws the lines lower 
than before:

graphics.fillRect(startX, startY + (int)(fmcInfo.getUnderlineOffset(graphics) 
+ lineAscent + 1.5), x - startX, (int)(fmcInfo.getUnderlineThickness(graphics) 
+ 0.5));

I found a Sun bug report that may explain the font metric differences: 

Why was 1.5 added initially?  Should these values be changed with the 1.6 JVM?
Comment 6 Miloslav Metelka 2007-01-12 14:35:46 UTC
I have removed the extra 1.5 already from the trunk. It's in

1.25	2006-09-06 09:14:08 +0000 mmetelka
Removed extra shift for underline.

I'll check the current state.
Comment 7 Miloslav Metelka 2007-01-12 19:38:32 UTC
The problem is still there. The wavy underline affects three vertical pixels and
it appears that the lowest one is part of the next line already.
If the lower line needs to be repainted it clears the lowest pixels of the
There are several solutions possible:
1) Make the line just two pixels high.
2) Move the line one pixel higher. It may be dangerous if the font would be too
small then it might collide with the baseline of the font and it would affect
3) When rendering a line check if the above line has a wavy underline and render
it. This would be the most difficult solution affecting performance as well.
Comment 8 cahrens 2007-03-21 22:19:56 UTC
To get around the wavy-underline problem, I tried option #1 (make line 2 
pixels high).  We actually like it better here.  From DrawGraphics,

int[] wf = {0, 0, -1, -1};  // CLA changed to only be 2 pixels, see NetBeans 

Note that you also have a problem for small fonts with 1.6 where the solid 
underline is not shown at all.  This is because  (int)
(fmcInfo.getUnderlineThickness(graphics) + 0.5) always does the floor, and 
with 1.6 fmcInfo.getUnderlineThickness(graphics) can return < .5 for small 
fonts.  Thus I have also made the following change:

(int)Math.round(fmcInfo.getUnderlineThickness(graphics) + 0.5)  // CLA added 
Math.round or else it is zero for small fonts
Comment 9 Vitezslav Stejskal 2007-03-21 22:40:42 UTC
The solid line underline problem was reported as another IZ# and I recollect
fixing it. So, it should be working fine in dev builds now. Or are you saying
that the solid underline gets ereased by the caret row highlight as well?

BTW, for the future, it is better to attach a diff with your adjustments,
something like 'cvs diff -uN ...' or use the Versioning->Export Patch for...
functionality in Netbeans. That way we can simply apply your patch instead of
trying to guess what and where exactly you changed. Thank you.
Comment 10 cahrens 2007-03-22 13:19:59 UTC
Sorry, I should have mentioned that we are using the 5.0 version of NetBeans.  
I did check that the 5.5 version was the same (we are in the process of 
upgrading), but I did not check the source code under development.

I'll try to make my proposed code changes more useful, but it is challenging 
because we are always at least one release behind.  Thus I can't verify the 
fixes that I propose in the version of NetBeans under development (we heavily 
edit the NetBeans source code, so it takes us about a month to change versions 
of NetBeans, and we can't invest that sort of time for releases under 
Comment 11 Vitezslav Stejskal 2007-03-22 22:38:23 UTC
No, no, don't wait for upgrade and don't upgrade just to be able to send diffs.
It's perfectly ok to send a diff from 5.0, 5.5 or whatever version you're
currently using, just tell us what it is. The diff is likely to work in 6.0 too
and if your changes conflict with ours we will sort it out somehow. Thanks.
Comment 12 cahrens 2007-05-11 14:47:08 UTC
I should mention that the Math.round I proposed on Mar 21 actually causes a 
problem on the Mac (10.4.9 with the newest 1.5 JVM) with font size 12, 
monospaced.  The was the problem I was trying to address:

Note that you also have a problem for small fonts with 1.6 where the solid 
underline is not shown at all.  This is because  (int)
(fmcInfo.getUnderlineThickness(graphics) + 0.5) always does the floor, and 
with 1.6 fmcInfo.getUnderlineThickness(graphics) can return < .5 for small 
fonts.  Thus I have also made the following change:

(int)Math.round(fmcInfo.getUnderlineThickness(graphics) + 0.5)  // CLA added 
Math.round or else it is zero for small fonts

On the Mac with that particular font, the underline ends up being 2 pixels 
thick and it leaves behind some repaint crud because it is too low.  Thus I 
have changed our code to use Math.max instead:

(int)Math.max(1, fmcInfo.getUnderlineThickness(graphics) + 0.5)  // CLA added 
Math.max or else it is zero for small fonts

Hope you guys are at JavaOne and having a good time!
Comment 13 Jiri Prox 2007-08-08 07:54:00 UTC
*** Issue 112174 has been marked as a duplicate of this issue. ***
Comment 14 Vitezslav Stejskal 2007-09-14 11:58:07 UTC
Both problems should be fixed now. This last revision only changes the waveunderline height, the strikethrough and
underline thickness was fixed in some other issue using 1pt as the minimum thickness. Thanks for the patches.

Checking in;
/cvs/editor/libsrc/org/netbeans/editor/,v  <--
new revision: 1.32; previous revision: 1.31
Comment 15 Vitezslav Stejskal 2007-11-05 13:25:00 UTC
Moving to the ui category.
Comment 16 akiliyevich 2009-05-06 10:30:49 UTC
The same problem in Windows, on current version of Netbeans 6.5.

Underline disappear when moving caret from current line to the following one (see the following screenshot).
Underline is painted 1 pixel lower then required.

The problem appears with most fonts (include standard Monospaced 12), except 'Lucida Console', 'Arial' and some other.

The problem is not appear in Linux or MAC.
Comment 17 akiliyevich 2009-05-06 10:32:05 UTC
Created attachment 81623 [details]
Comment 18 Vitezslav Stejskal 2009-05-06 12:33:40 UTC
Does changing the font size help? Can somebody with Win box please confirm the problem? Thanks
Comment 19 Jiri Prox 2009-08-18 14:11:49 UTC
I can confirm this, it is reproducible with latest trunk build
Comment 20 anli 2009-09-27 16:12:04 UTC
Created attachment 88404 [details]
the issue under Linux illustration
Comment 21 anli 2009-09-27 16:14:27 UTC
Under Linux the issue also takes place (png is attached) for current NB trunk. DejaVu Sans Mono font is un use.
Comment 22 anli 2009-10-04 23:39:07 UTC
Another problem related to current-row highlighting - right part of italized symbols is truncated. I'll attach an example.

Again, it is current NB trunk, Linux, DejaVu Sans Mono font are in use. I have tried another monospaced fonts with the
same "effects" also.

Any hope?
Comment 23 anli 2009-10-04 23:40:25 UTC
Created attachment 88809 [details]
another current-row issue illustartion
Comment 24 Vitezslav Stejskal 2009-10-05 12:08:34 UTC
There is always hope :-).
Comment 25 Miloslav Metelka 2009-10-07 13:19:27 UTC
The problem is likely that font's underline offset plus our 1.5 pixel shift constant (some fonts return underline offset to be the same as the lower edge of 
the letters) is greater than font's descent.
I have retested the relation between '_' and underline line for the default font sizes on Linux and Mac (mentioned in the patch) and IMHO the extra shift 
could be 0.5 instead of 1.5 so I've changed that.
To jiriprox: Jirko, could you please test on Windows and with that "DejaVu Sans Mono" font? Thanks.

As a last resort (if we would have to get back to 1.5) I could check that the (underlineOffset + 1.5) < fontDescent and if not then force y = fontDescent - 1 
and height = 1.
Comment 26 Quality Engineering 2009-10-09 23:06:47 UTC
Integrated into 'main-golden', will be available in build *200910091401* on (upload may still be in progress)
User: Miloslav Metelka <>
Log: #56464 - Highlighting row overrides error underline - underline line shift constant changed from 1.5 to 0.5
Comment 27 anli 2009-10-10 15:17:07 UTC
For me the issue still exists (I have reported here examples for Linux). As for undelining decoration - all is fine now,
thanks! But:

1. as for underline char '_' - it isn't shadowed by following current line only with spacing set to ~1.3 and above (i.e.
very sparse text flow). With spacing, say, 1.2 '_' is shadowed. Saying about spacing I mean an appropriate element in
the userdir/config/Editors/Preferences/org-netbeans-modules-editor-settings-CustomPreferences.xml file.

2. current row highlighting still eats right part of wide italized symbols - I have attached example png earlier.

Comment 28 anli 2009-10-10 15:42:13 UTC
BTW, with spacing 1.2 such symbols like 'g', 'p','y' are also affected by next highlighted row - their bottom part is
slightly truncated.
Comment 29 Miloslav Metelka 2009-10-14 14:37:30 UTC
The "appropriate element" means "line-height-correction"?
The problem is that we can hardly find a solution that would work with all the fonts available. If I do no correction then the LineMetrics.getUnderlineOffset() 
would do what I've mentioned above. With the current correction factor it does not work for your particular font.
I will fix the italics problem.
Comment 30 anli 2009-10-14 15:04:47 UTC
Yes, I'm saying about "line-height-correction".

Is it possible to list fonts intended to work? DejaVu, I (probably wrong) think, is the most spreaded font under Linux
among sans mono ones.

(if we forget about technical details and try to "feel with eyes" only, it seems (for my eyes) current row highlighting
must be shifted down *in a whole* wrt the current row)
Comment 31 Miloslav Metelka 2009-10-14 17:20:10 UTC
The culprit of the italics rendering problem is the graphics.fillRect() at DrawGraphics:744 which clears the background
beneath the rendered fragment of text. The italicised font returns the same measurements (at least on linux for e.g.
monospaced:18) but e.g. the "w" char is rendered so that it spans the space which should normally be occupied by the
adjacent character. There's a Font.getItalicAngle() but anyway it would be rather difficult to fix it with the present
DrawEngine etc. infrastructure but I will definitely consider this usecase when implementing issue 121357.
Comment 32 anli 2009-10-14 17:33:09 UTC
Miloslav, at any case all these bugs... microbes are not show stoppers. 
Probably it may be handy just to close this issue at all, as far as they
are already taken in your mind wrt issue 121357 :-)
Comment 33 Miloslav Metelka 2009-10-16 17:03:48 UTC
Ok marking as fixed.

> (if we forget about technical details and try to "feel with eyes" only, it seems (for my eyes) current row highlighting must be shifted down *in a whole* wrt 
the current row)

I understand your concern but it's according to the rendering guidelines - we add a font's ascent to the base y coordinate to get the font's baseline and (ascent 
+ descent) gives the line height. In terms of issue 121357 I could possibly add another hidden tuning parameter that would allow to shift the baseline slightly 
up so that the underline is not at the last pixel of the line's background highlighting.