I've tried the Lato-Regular.ttf (taken from here: https://github.com/google/fonts/blob/master/ofl/lato/Lato-Regular.ttf ) and it works just fine for me. I've tested it on different JDK versions (6, 8, 9, 11 and 13) and different L&F (Metal and WebLaF) under Windows OS - behavior seems to be exactly the same across all tests - caret is properly positioned on the text in JTextField
with both short and long texts at any index in that text.
So I'll need more details about cases when you see the issue:
MetalLookAndFeel
?
Yep, exactly the same code I've used in my test class:
public class FontTest
{
public static void main ( final String[] args )
{
SwingUtilities.invokeLater ( new Runnable ()
{
@Override
public void run ()
{
try
{
UIManager.setLookAndFeel ( WebLookAndFeel.class.getCanonicalName () );
// UIManager.setLookAndFeel ( MetalLookAndFeel.class.getCanonicalName () );
final Font font = Font.createFont (
Font.TRUETYPE_FONT,
FontTest.class.getResourceAsStream ( "Lato-Regular.ttf" )
).deriveFont ( 16f );
final JFrame frame = new JFrame ();
frame.setLayout ( new FlowLayout () );
final JTextField textField = new JTextField ( 50 );
textField.setFont ( font );
frame.add ( textField );
frame.setSize ( 800, 600 );
frame.setLocationRelativeTo ( null );
frame.setDefaultCloseOperation ( WindowConstants.EXIT_ON_CLOSE );
frame.setVisible ( true );
}
catch ( final Exception e )
{
e.printStackTrace ();
}
}
} );
}
}
I recommend you to try this small example and see if the same issue occurs or not, once with WebLaF and once with the MetalLookAndFeel
.
If it doesn't appear on this example - it might have something to do with other settings in your application.
If it does - then it could be a Java issue on Mac OS, especially if it appears for you on both L&Fs.
I'd say it's a 50/50, it might be caused by hidpi display, but on hidpi I would expect caret in text field to be visually offset by a fixed amount of pixels. The fact that offset increases with larger index means that there is a difference in caret position calculation and font rendering - caret position calculation either uses old font or has some deeper issues.
If it's the same on MetalLookAndFeel
that means it's just a general Java issue, potentially with particular font (or all non-system/custom fonts?) - hard to tell really.
After a quick search on the matter I found this issue: https://bugs.openjdk.java.net/browse/JDK-8014069
It does seem to be resolved long ago though, but it sure does resemble your description of the problem.
Overall - I can't really do anything about font-related issues like this one because both font rendering and font-related calculations aren't done by L&F code and are simply retrieved from public APIs (like FontMetrics
for instance). There could definitely be cases where WebLaF is at fault, but that would usually be reproducible against other L&Fs and would mostly cause the same issues across different OS versions.
What I could recommend doing - try the same example with newer Java versions (9+) and see if the same issue appears there. If newer Java version fixes it - it might be worth switching your application over to newer version if it is possible.
Alternatively - the issue seem to be caused by custom font's size being different from the default font size of the component. Maybe it would work correctly if you use the same font size as the component has by default for your custom font. That's just an idea for a possible workaround.
Also if the issue is still there for you on latest Java 8 updates or even newer Java versions - it might be worth submitting a JDK bug report. I've found quite a few JDK bugs over the years and submitted most of them. Some have been fixed since and some unfortunately are still not resolved, so that could take a long while. Also fixes for reported bugs will most probably only be available on newer Java versions.
@kovadam69 Right now - only if you use some 3rd-party solution or make one yourself. WebLaF currently provides close to none features on top of the basic JTable
, so functionality-wise WebTable
is pretty much the same as JTable
with just a few convenience methods added on top.
We did have a similar task for one of our internal projects - to make a useable multi-line table header - but I wasn't the one working on it and the final solution was quite sloppy and only worked for that particular case, so it didn't make it into WebLaF in the end.
I do plan to eventually expand JTable
to support multi-line header, cells merging, better sorting and some other features I really want to see myself, but it all requires quite an extensive rework of the basic table implementation (both UI and component), so that will most probably be a completely separate new component - something like WebExTable
- and it will take a substantial amount of time to add, which I probably won' have this year.
There are already quite a few issues added for JTable
: https://github.com/mgarin/weblaf/issues?q=is%3Aissue+is%3Aopen+table
I'll make a summary issue now that will list all the planned improvements that are split into separate issues and which you can track.
@kovadam69
If you meant 1.3.0 snapshot - it have been purely experimental and I wouldn't recommend using it.
Currently latest version is 1.2.13, and latest snapshot is 1.2.14.
There have been some important changes done to WebStyledLabel
in one of 1.2.14 commits: mgarin/weblaf@0a39e8c
They might have affected the table title rendering, but I'll have to double-check that.
Judging by the screenshots - table header size calculations remained the same, but label doesn't fit into the available width anymore.
Can you give that specific title text or does this issue appear on any text?
Is this text containing HTML by any chance?
If it is an HTML with <br>
tag, can you try using {br}
(since renderer is a WebStyledLabel
this should work) instead to see if it fixes the issue?
WebLookAndFeel.install();
final WebMemoryBar memoryBar = new WebMemoryBar ();
memoryBar.setPreferredWidth ( 200 );
WebPanel panel = new WebPanel();
panel.setPreferredSize(400, 28);
WebStyledLabel label = new WebStyledLabel();
label.setWrap(TextWrap.word);
label.setText("Asdfasdf 12345678-12345678-12345667 AA123456781234556767");
label.setBoldFont();
panel.add(label);
TestFrame frame = TestFrame.show(5, false, panel, memoryBar);
AbstractContentLayout.layoutContent
method. It gets the correct bounds of 427x77, but at the call to final ContentLayoutData layoutData = layoutContent ( c, d, bounds );
it gets back a smaller rectangle. It happens in IconTextLayout
for some reason it reduces the size...
Thanks for code example, I'll look into that.
It is really weird though, maybe the issue is tied to the particular wrapping method or something else very specific.
I have thoroughly tested WebStyledLabel
changes when they were pushed and it didn't seem to have such glaring problems.
One more thing - what Java version are you using for the test?
@kovadam69
Just a small update - I've passed this issue to my colleague who made the recent changes, he will look into it once he has a bit more free time. There are certainly some issues with internal size calculations. It's been a wack-a-mole game for a while with the styled label layouting code as there are just too many cases (especially edge cases) which it needs to account for and the code itself is a bloody mess. Fixing one issue in that part almost always caused a few new ones, just like this time, so we'll need to be very careful.
So as I mentioned earlier - I recommend using more stable public v1.2.13 release for now, at least until v1.2.14 is patched up and finally released.
@bgmoon
Theoretically you can use WebLaF inside existing UI designers like JFormDesigner, but practically there is an issue - WebLaF has to be initialized to work properly and unfortunately, as far as I know, none of the existing designers support that. And overall - I was developing WebLaF with mostly coding convenience in mind as I haven't really ever used UI designers as a tool to create UI code for any real-life projects. I do want to make WebLaF usable within UI designers without initialization but that will require some work and it is a bit further on the todo list.
WebLaF is not affiliated with JetBrains anyhow and isn't a plugin for any of their IDEs - it's just a standalone L&F library for Swing framework on Java, so I'm not sure how it can be available on JetBrains store (or marketplace? whichever you meant).
These are official artifacts published by me: https://search.maven.org/search?q=g:com.weblookandfeel
Other ones that may be available on Maven might simply be published by other WebLaF users and may be compiled from modified sources.
That video is from a very old demo that was available before the major styling revamp in WebLaF (pre-1.2.9 versions). Not sure what you meant under image cropping, but the image gallery component is still available and it's component class is called WebImageGallery
. It haven't been added into new demo though because new demo only contains fully revamped and "cleaned up" components. It is still functional, but it will receive a rework in the future to be more customizable via new styling system.
And about the warnings - I recommend reading this wiki article: https://github.com/mgarin/weblaf/wiki/Java-9-and-higher
It should explain why those happen and how to configure your projects to avoid them.
@mikehearn
In runtime - currently no, but as a temporary solution I've added public static fields in WebLookAndFeel
class that you can change to adjust global or specific component fonts, here are some examples:
WebLookAndFeel.globalControlFont // global font for ControlType.CONTROL
WebLookAndFeel.buttonFont // specific font for button components
WebLookAndFeel.checkBoxFont // specific font for check box components
There are a few issues with adjusting fonts in runtime, so that would still require some work to be done, but ultimately that's the goal of #331 and #352 issues