Does anyone know of an existing solution for font glyph fallthrough in Java? For example, our designers have decided that Calibri is the font that mostly fits our needs, but if I specify Calibri, it can naturally not render characters that do not have a matching glyph in that font. In that case, I would need it to fall through to a second specified font, and if all else fails - use one of Java's logical fonts.
Has anyone come up with a solution for this, which can be plugged into existing Swing components without having to write custom Swing components for the entire project?
This is a very old project already, and building custom graphical components is not a feasible solution.
This isn't a code-based solution and probably won't be of much help, since it requires each user to install a file locally, but just in case...
You can add fallback fonts in a special directory within the JRE installation. From the Java documentation:
Users can add a physical font as a fallback font to logical fonts used in Java 2D rendering by installing it in the lib/fonts/fallback directory within the JRE.
Related
I am trying to find a java look&feel that can be used in NetBeans (I'm currently usign version 14) to have a "what you see is what you get" result
As I said here: netbeans design missing bold, I was using the Metal l&f, both in NetBeans (by launching it with the "--laf javax.swing.plaf.metal.MetalLookAndFeel" parameter) and in the code
But lately it doesn't work as it used to: in NetBeans the varoius graphical objects (labels etc...) have a "normal" font, but when i run the project, they have a bold font, which makes them larger and ruins their positioning. Thus I can't create a good graphical interface anymore, because I have lost the "what you see is what you get" effect
I have also tried different l&f, for example Nimbus. With it, I can solve my problem: NetBeans correctly shows the graphical objects as expected. But imho Nimbus has a big lack: non-editable obects (for example text fields) are showed identical as editable ones! (the Metal l&f instead makes a good work at this)
I'm searching for a l&f that can correctly be displayed by NetBeans, and that can differentiate between editable and non-editable objects. Can you point me out any?
Try com.sun.java.swing.plaf.windows.WindowsLookAndFeel.
You need not to put startup options in NetBeans, check look and feels Tools / Options / Apperance menu.
Another workaround would be making all non-editable widgets to be disabled - setEnabled(false).
I have written a Java Desktop Application that runs in Windows, Mac OS X, Ubuntu and Open Suse. I am having issues with is positioning thing differently in Linux.
I developed the application with NetBeans using the designer, it looks as I would expect in Windows and Mac OS X, but in the Linux distros certain label controls have shifted into different positions.
Is there a common reason for this?
Perhaps Linux uses a different font. One where letters have a different width.
You could try to explicitely set a specific font for your Look&Feel. It should be a font which is installed on all of your target platforms.
The most probable thing is that you use different Look and Feel for every platform. If you're developing in Windows you do layouts to fit for Window style only. But Linux has different L&F with different margins and font for GUI components. Metal style (basic for Linux) and its descendants (Nimbus and GTK+) have larger default system font and heights for components. I think, that must be a reason why you have shiftings.
The way to fix that is to check program looking in both platforms. I'd suggest to develop in Metal style because Windows has smaller fonts, as result, everything which fits in Metal will fit in Windows.
I'm assuming you developed the thing on Windows or Mac, that's why it looks "as expected". Can you compiling/running the code in your IDE on Linux and see how it looks?
My guess is that one of the implementations of the containers is flawed. I saw this sometimes when I did cross-development and mostly did trial-and-error modifications to fix it (by changing to use other classes). It also helped to have one developer working in Windows and another in Linux, so that we would easily spot and fix problem areas.
I changed the Layout style from 'Free Design' to 'Absolute'
I have some Swing code (written in 1.6 for 1.6) that specifically sets the font in a text area to Courier, but on some Windows systems, this shows up as Arial (the system default?) instead. Does that mean a font is missing from the system? What is the behavior Java has when it can't find a font it is looking for? Does it complain? Does it log it somewhere? Does it immediately resort to using the system default? Is the behavior different between 1.4/1.5/1.6 versions of the JVM?
Has anyone else ever run into this? I was very surprised to have something different from what I HARDCODED into the application show up in the UI - and only on some systems. The core issue is that I need a monospaced font style for this particular case, and Arial is not monospaced. Is there some way to specify a fallback if a certain font is not found? Something like:
if font is available use "Courier"
else use "monospaced"
???
You should first check if "Courier" is among the results of GraphicsEnvironment.getAvailableFontFamilyNames()
I don't know any built-in mechanism in Java for "if-unavailable-fallback-to" behavior.
According to this article1 the only monospaced TrueType fonts shipped by Microsoft are Courier New and Lucida Sans Typewriter.
It might expect you to specify "Courier New" for Courier. I don't have a Windows system, so I can't verify this.
[EDIT] this happend on OSX with Java 1.5! (but may also happen on Windows!)
It seems japanese users of my Java Swing program cannot write japanese symbols in JTextFields. Actually they can write them but do not see them. They only see blocks which somehow indicates I think that the font does not support these symbols.
I set my own font for various reasons ("Lucida Sans", Font.PLAIN, 12) - which I wouldn't like to change. My questions are:
would the JTextFields show japanese Symbols without me setting this Font?
could I detect which Locale's are fully supported by my Font and only set it in those cases but leave the standard Java font for all other cases like Locale.Japan?
do you have any other suggestions?
Thank you for your help!
would the JTextFields show japanese Symbols without me setting this Font?
Most likely since the JRE will choose the default.
could I detect which Locale's are fully supported by my Font and only set it in those cases but leave the standard Java font for all other cases like Locale.Japan?
Yes, in theory, although easier would be to test if this font can display a locale specific character using the the canDisplay(char) method in Font. If it don't, you may switch to the default.
do you have any other suggestions?
Here's a link on this topic that may help
Do you have a link for your product?
For this very reason, my internationalized application sets its font depending on the locale. To answer your questions:
This probably depends on which version of Windows is being used. Is this the US edition with Japanese fonts installed, or is this the version sold in Japan? I don't know the exact answer to your question, but I expect that the answer is, "It depends."
I don't know of any standard way to do this. I have found a wonderful utility for investigating this kind of thing: BabelMap. This will tell you exactly what characters are supported by any given font.
Other suggestions: Set your font depending on Locale, at least for select Locales.
I extend org.eclipse.swt.widgets.Composite and create many widgets on it, (labels, table, text etc). The problem I am facing is that the labels' text is getting truncated on linux while it appears fine on windows. When I change the linux's font to gothic the truncation is little less but still there. Is there way to homogenize the windows and linux display. What could be the best font to use in linux in such a case.
More likely it is related to this eclipse bug which I just lobbied to have re-opened: https://bugs.eclipse.org/bugs/show_bug.cgi?id=151322
It sounds like you are using absolute positioning instead of dynamic layouts. (If this isn't the case, perhaps you could post code demonstrating the problem). Using a dynamic layout should ensure that controls are resized to accommodate their contents. (They're also great if you ever translate a product, because then you don't have to rejig every dialog for every language.)
To complete McDowel's answer, there is also a bug related to the way Linux check for wrapping label:
It is fixed since 3.4M7.
Even though it may not be related to your case, it would be useful to know which version of eclipse you are using and if you can reproduce your bug with the latest ones (like a 3.5M6)