Curly braces in beginning+end of value disappear in JTable cells when using WebLaF

[mvmn]

It seems when I set WebLaF as Look&Feel the curly braces inside JTable cells disappear - if they are in the beginning or in the end of cell value.

Here is an example:

I'm on macOS 10.15.6 using JDK 1.8.0_111

Source code for this example:

public class Test {

    public static void main(String args[]) {
        //
        SwingUtilities.invokeLater(() -> {
            WebLookAndFeel.install(WebDarkSkin.class);

            JTable tbl = new JTable(new Object[][] { new Object[] { "{\"Hello\":\"world\"}", "Stuff", "{{{test}}}" } },
                    new Object[] { "1", "2", "3" });
            JFrame frame = new JFrame();
            frame.add(tbl);
            frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
            frame.pack();
            frame.setVisible(true);
        });
    }
}

[mvmn]

Without WebLaF:

[mvmn]

WebLaf default skin:

Bottom of the text is also clearly cut off

[mgarin]

This isn't exactly a bug, but it might look like one for sure. The reason why this happens (braces disappearing) is that default renderer that WebLaF uses for trees, lists & tables is based on WebStyledLabel component and not JLabel. And WebStyledLabel has a custom syntax for styling text which involves braces, you can check it's description here: https://github.com/mgarin/weblaf/wiki/How-to-use-WebStyledLabel#styled-text-syntax

Currently the only way to disable this behavior would is to provide a custom renderer that isn't based on the WebStyledLabel. This certainly isn't a great solution and I agree that this is a problem, but I'll need to find a solution for this that can allow using the existing renderers, but also easily switch between syntax parsing and plain text modes.

Also not "eating" the braces if there are no extra syntax settings provided might resolve most cases including yours (but it doesn't resolve all possible cases).

[mgarin]

Regarding the text being cut off - this depends on the Font. Row height is fixed in JTable and it's probably 16px in both of the cases you've shown, but Font is different because of different L&F usage.

Under Mac OS X WebLaF tries to retrieve native font (you can check NativeFonts class), but it might differ from other L&Fs, including system one. It might also depend on Java version used.

Overall - there is no good solution I can implement for this right now because Font may differ wildly between systems and the JTable row height is a fixed setting that doesn't rely on the Font and might even be changed in JTable by developer in the first place. On top of that table renderer style/border will affect text fitting or not fitting into the cell as well.

There are a few ways you can work around this:

1. Use table.setOptimizeRowHeight ( true ); method available in WebTable - it will automatically adjust row height according to current table renderer's preferred height. This way you will never need to worry about having inconsistent row height.

2. If you aren't using WebTable you can still use TableRowHeightOptimizer with any JTable:

   new TableRowHeightOptimizer ( this ).install ( table );

3. Use custom row height for your JTable, something like 18~20px might be enough:

   table.setRowHeight ( 20 );

Obviously 3rd solution is pretty bad as it still doesn't guarantee that text/content will fit into row height, so I recommend either of the other two. You can also use TableRowHeightOptimizer even if you're not using WebLookAndFeel as all it does - calculate preferred height of the table renderer for a few values and uses it as JTable row height.

[mvmn]

Clear, thanks

[mgarin]

I'll keep this open and think of some way to avoid this issue and add possible enhancements.

[mgarin]

I have added a small restriction in syntax parsing so both of the cases you've shown should now be ignored by the syntax parser since they don't contain any actual styles (in the braces). It will shortly be available in snapshot version and will soon also be available in v1.2.14 update.

I'm not yet sure how to properly solve cases when you are providing text containing actual style syntax (for instance {sample:b} text) - those would still get parsed and visually styled. But not to mix everything together - I've created a separate enhancement issue for that: #654