Created attachment 20110 [details]
screenshot on Mac

Created attachment 20111 [details]
screenshot on WinXP

probably an issue with NodeRenderer?

reassigning

*** Issue 58951 has been marked as a duplicate of this issue. ***

Hatake,

is this still an issue with nb4.1 ?

I suggest raising this to p2 - it seems that if strings are chopped
that is serious issue for usability.

ken.frank@sun.com

yes. I can reproduce this on 4.1 release

the problem is in the htmlrenderer. working on it.

a temporary workaround is to run netbeans with this switch:
-J-Dnb.useSwingHtmlRendering=true

Note the workaround will cause some performance problems - Swing HTML rendering is slow.

I'd be curious to know if the problem is additive - if the string is longer, is more of the last character 
cut off?

My guess would be some kind of rounding error with mac os FontMetrics (known problematic).  The 
total width comes from FontMetrics.stringWidth() in HtmlRenderer._renderPlainString()).  

Out of curiosity, it would be interesting to see if passing all the text as HTML fixes it - 
HtmleRenderer._renderHtml() will calculate each character independently and doesn't round.  Milos:  If 
you can reproduce the bug, possibly try changing Node.getHtmlDisplayName() to return 
getDisplayName() always (don't commit this) and see if it fixes the bug.  If there is a discrepancy 
between the return values of _renderPlainString() and _renderHtmlString(), you've probably got a usable 
test case to send to apple.  

What you can probably do as a semi permanent workaround is to add a few pixels to the return value of 
HtmlLabelUI.getPreferredSize().width if os == mac && locale == whatever.  The good news is the bug is 
in the return value of _renderPlainString(), which is much less complex than _renderHtml.

Hope that helps...

Thanks Tim.

I just came to the same conclusion. the FontMetrics.stringWidth() method is the
culprit here. I managed to workaround the problem by setting the width to (1 +
1/6) * oiginal width. But.. then it does so for english test as well. and
doesn't work for long strings, so this heuristics is too simplistic.

another problem I just figured is that the editor's tab control displayer
behaves the same and needs to be adjusted as well.

I'll try your suggestions. The html rendering probably also doesn't work because
the bold/italic text is also rendered incorrectly.

Hmm - one potential bug that's in there already:  The preferred width of HtmlLabelUI comes from 
_renderPlainString - but the result is converted into an int to put it into a Dimension object.  Then it's 
passed back in as the w argument to _renderPlainString() - so we're losing the decimal part.

However, I don't think that's the whole problem, since clearly we're losing more than one pixel off the 
end.

Hmm, looking at HtmlRenderer.renderPlainString() some more, I like it less - the decimal math isn't 
clean.  We pass in an int w param.  If the return value to calculate the size was > w (it almost always will 
be) it is going to fall back to clipped painting - and even set the clip bounds (see the code involving an 
Area).  

Try adding a few pixels to the return value of HtmlLabelUI.textWidth - it should fix it and be relatively 
harmless.

Maybe check the locale (or if using HTML, note if any characters are > 128 - I think that works even in 
java-land), and only do it then, but add String.length() pixels?  Probably it's a per-character rounding 
error, so it's just a compendium of off-by-1's.

fixed in trunk. (will appear in daily build from 8/Jul/2005)

for macosx instead of calling FontMetrics.getStringBounds, call the
FontMetrics.stringWidth. even though the javadoc suggests that getStringBounds
gives better results, on macosx 1.4.2+1.5, it cuts off part of text in japanese
and chinese.

please test extensively and let me know if the workaround introduced doesn't
break anything else.

Did you file a bug with apple on this?  If not, please do and note the number here .

no, I haven't. I've tried to put together a simple testcase but I didn't manage
to get the *right* results from it. probably something in the way we use it.

makes no sense to file without a reproducible testcase.

for your verification, as per last entry, send me names of product jar files
that have these labels/msgs/tooltips and I'll send you a pseudo localized ones
so you can run it in your mac in ja locale.

ken.frank@sun.com

If you have a testcase showing that the results from FontMetrics.stringWidth and 
FontMetrics.getStringBounds() are different, that's what I meant as a test case - both results can't be 
right, and we can leave it up to Apple to figure out which one should be fixed (but we can give them a 
hint :-).  

So a simple app + JUnit test that would try to paint some string and fail if the result of the two methods 
was different would probably be perfect (and Apple tends to fix things faster if we give them a test 
case).

kfrank: I have a english->japanese/chinese dictionary, so I actually tried with
project names/file names etc. these should be in principle the same as the
localized hardcoded strings.

I wonder what is the localization schedule and if we should put this patch
(after being tested) into 4.1 codebase. How important is this issue to you guys?

tboudreau: That's exactly what I did tim. I've created a j2se project with
sample code, but the values returned there are the same, not different. but in
our codebase these differ. So I was not able to reproduce the problem we have in
a simplified environment.  Not sure it's  relacated to the code, encoding or
something else.

4.1 ml nb is virtually done and its not supposed to have
no non p1 type of code changes anyway, from my understanding.

I don't know if this is impt enough to require a patch vs
just being in the next nb

maybe one consideration is - if window is resized, does all the mbyte
then show, or not even then ?

Hatake, can you give opinion of l10n on this - needing fixing for some
4.1 patch vs being fixed in next nb ?

ken.frank@sun.com

> maybe one consideration is - if window is resized, does all the mbyte
> then show, or not even then ?

as far as I know, it's unrelated to window size. So resizing won't help.

| >> maybe one consideration is - if window is resized, does all the mbyte
| >> then show, or not even then ?
|
| as far as I know, it's unrelated to window size. So resizing won't help.

Yes. resising won't help in this case.


| Hatake, can you give opinion of l10n on this - needing fixing for some
| 4.1 patch vs being fixed in next nb ?

Please fix this in next nb release, 4.2 ? (not in 4.1 and any patches..)
As for 4.1 release, I have added workaround information to Japanese
release notes. So user can avoid this issue on Mac :-)

In your test environment, was antialiasing turned on?

| In your test environment, was antialiasing turned on?

Yes. It seems that choppped Japanese strings is smoothed.

Created attachment 23060 [details]
attempted, but failing simplified testcase

Tim: I've attached the testcase, please take a look at it maybe I'm missing
something obvious.

BTW: antialiasing was the first thing that I commented out when trying to figure
out the problem in HtmlRenderer. It didn't make a difference.

I see this in resolved state but from last comments below it seems that
it might not be (comment about simple test case failed)  or that maybe the
workaround is still needed ?



is the turning on of anti aliasing required by user ?

is the fix now to do the workaround or is it actual fix ?

(We see the issue in creator on mac now so if its actual fix, we can
try to see if the fix can get info current creator release)

ken.frank@sun.com
10/03/2005

well, it's a workaround for something I believe to be apple's jdk bug. I cannot
prove it though, because I don't have a simplified (out of box, outside of
netbeans) testcase.

We need to port this fix to our code base.  Can you point me your integrations?

Thanks.

hatakyon,
could you be so kind to verify this issue in NB 5.0 RC2 ? Thanks in advance. 

Verified the fix on 5.0 ml daily builds in JA locale - 0226 version.