How can I render CJK characters properly in JBTable?

In a tool window of my plugin, I'm finding that certain CJK characters aren't rendering properly in JBTable cells even though they render properly in other aspects of the UI such as an EditorTextField and a ConsoleView.  Here's an example:

As you can see, the first set of values which contain CJK characters are rendered fine in the EditorTextField, JBTable, and ConsoleView, but the second set of values end up being represented as boxes in the second row of the JBTable while they're rendered fine elsewhere.

For what it's worth, I'm using the same font as the editor (queried using EditorColorsManager.getInstance().getGlobalScheme().getEditorFontName/Size()) in the JBTable so that it has access to the full range of characters.

It's definitely a rendering issue only because if I highlight the bottom-right cell and copy/paste the value into the editor or console, it shows up properly.

Any idea how I can get these values to render properly across the board?  Thanks much in advance!

11 comments
Comment actions Permalink

Try to use the same font for editor and other UI. Does it help?

Appeareance & Behaviour -> Appeareance

Editor -> Colors & Fonts -> Fonts

0
Comment actions Permalink

Thanks, Denis.  Unfortunately that doesn't help.  I'm doing that now by using EditorColorsManager.getInstance().getGlobalScheme().getEditorFontName()/Size() and using that for the font in the table and its cell renderers.  Before I did that, the CJK characters displayed successfully in the first row wouldn't render properly and that fixed it.  However, it seems that there's still a class of CJK characters that don't render properly as demonstrated in the second row.  Is there some other way I can do this more comprehensively perhaps?

0
Comment actions Permalink

We will take a look at this

0
Comment actions Permalink

Thanks, Denis.  I also logged an issue in support:

https://intellij-support.jetbrains.com/hc/en-us/requests/831212

Feel free to rationalize that against anything in YouTrack, etc., as makes sense.

One additional piece of information from trying to debug this a bit over the weekend...this renders properly on OS X but not one Windows or Linux.  It's the exact same code which just sets the font of a JBTable according to the editor font name/size.

And for convenience, a CJK string that renders properly is "见/見" while one that does not render properly is "한국어 키보드".  Hopefully that helps to accelerate your debugging of this issue.  Please let me know if there's a better place to track progress on this.

Regards,

Scott

0
Comment actions Permalink

Editor has font fallback mechanism - when user-chosen font cannot display some character, other font will be used. Swing text components don't have that. The only solutions currently are either using font that is known to support characters in question, or trying to use Java's logical fonts - Dialog, DialogInput, Monospaced, Serif or SansSerif - they are 'composite' fonts and have some sort of fallback mechanism as well internally.

0
Comment actions Permalink

Thanks for the update, Dmitry.  So in other words, when I see those characters rendering properly in the editor and console views, it's not a single font being used for all characters but rather the configured font when possible and fallback fonts for glyphs that aren't available on the configured font, correct?  And in the JBTable, it's just using the single font which renders the placeholder for unsupported characters/glyphs?  By default it's using Monospaced since that's the default editor font on Windows (can't remember what it is on Linux).  Unfortunately Monospaced doesn't seem to support these characters.  I've tried DialogInput which doesn't also support them.  Any thoughts on a font that might properly support these characters?  For what it's worth, I have heard from the user that a Korean font does support them, but of course it may not render other things properly and ideally I'm looking for a holistic solution if possible.

Thanks again!

0
Comment actions Permalink

You've described it correctly (with some platform-dependent caveats, but on Windows it's like that).

I don't think I know a font that I can recommend in this case - as you say, a specific Korean font most definitely won't support other languages (maybe not even Latin). And unfortunately, even though we're also affected by this problem, we still don't have a good solution at the moment.

But if Monospaced (or some other Java logical font) doesn't support Korean, potentially that can be fixed by extending the list of fonts Monospaced is 'constituted of'. If you could raise a ticket here with details (OS version, info from About screen, sample text which is not displayed), we can try reporting it to JDK developers, or try fixing it ourselves in JDK build we bundle with our IDEs.

0
Comment actions Permalink

Dmitry, is the logic used to render into the console view using fallback fonts available in the source?  If so, would you mind providing a code pointer?  Since you guys are able to show this in other views, perhaps I could create a table cell renderer uses the same approach when rendering text into my table based on the capabilities of the default font and a list of backup fonts.

0
Comment actions Permalink

I just did a little prototype of a table cell renderer based on EditorTextComponent.  It works and renders all of the characters properly, but the cell is rendered very tall with the row highlighted according to settings.  Digging in a bit, it looks like perhaps EditorImpl.drawTablessString() is perhaps the code that renders text using a primary font and fallback fonts if necessary.  I may try to create a simpler cell renderer that uses the same approach for rendering its text but doesn't carry along the full weight of an editor text component.  If you get a chance, would you mind verifying that I'm looking in the right place?

0
Comment actions Permalink

Maybe com.intellij.ui.EditorTextFieldCellRenderer can help you.

If you're looking for the actual code that does font fallback - it's in com.intellij.openapi.editor.impl.ComplementaryFontsRegistry.

0
Comment actions Permalink

That is EXACTLY what I needed!  Works perfectly!  Thanks, Dmitry.

0

Please sign in to leave a comment.