I'm making a unicode Sinhala-English translator. When I print a Sinhala unicode letter with font size < 100, the letter is not correctly rendered. But when I use font size > 100, all letters are rendered smoothly. I can't find why this happening. On the other hand, all Sinhala unicode fonts do the same & it's not a bug of the font that I used. An Example is shown here.
Please help me.
I'm not aware that Java uses its own font rendering on Windows 7. So it should be a Windows bug but if that was the case, you'd see the problem in all Windows apps - but you see it only in Java.
You may want to try the Java 2D API. For example render the font with 140px and scale the Graphics2D by 0.5 to get 70px fonts.
[Old answer]
You're not saying which OS but my guess is that this is on Linux. If that's the case, then it might be because of "font hinting" in FreeType.
Basically, if a font becomes "too small" to render, the true type file can contain "render hints." In your example, you can see that the large font has smooth edges but the small example is more square-edged. You can see the pixels; anti-aliasing should prevent that.
So my guess is that you're a victim of the Font Hinting patent. The patent in question has expired last year. Try to find a newer version of "freetype" for your system.
Related
I've run into a problem that has me really scratching my head when dealing with Swing objects in java (and JFX as well, but I'll worry about that later...).
Here is the code that I am using to open fonts in my program. It's pretty standard.
public static Font getFontFromFile(String filePath) throws FontFormatException, IOException {
File fontFile = new File(filePath);
return Font.createFont(Font.TRUETYPE_FONT, fontFile);
}
My problem is that when I actually go to use these fonts, ligatures within them are not respected. One of the core features of my program allows users to load custom fonts, many of which have specialized ligatures. These are not being respected, and I'm not sure what I am doing wrong. If the user types two characters that should reduce to a single ligature, the second character just appears normally, with no transformation taking place. When I load the fonts into any other program or text editor I'm seeing the ligatures be respected exactly as I would anticipate.
I've stripped down code where I'm actually setting the font in a few places to the absolute bare bones and I'm seeing the (wrong) behavior even in places where I'm doing something as simple as:
jTextField.setFont(myFont);
Is there some setting on import that I am missing? Or that needs to be globally flipped on the 2D graphics object? Any assistance would be really appreciated. Thanks,
FOUND IT.
Ok. So. This one was frustrating, as I had been correctly setting the TextAttributes, while loading fonts via a method which is plagued by a long standing bug... Ligatures are supposed to be represented in JTextField and JTextArea objects, but under certain circumstances, they will not be. There are two things to keep in mind.
There is an old bug (https://bugs.openjdk.java.net/browse/JDK-8139741) which prevents ligatures from being respected when using the pattern
// BROKEN PATTERN
Font myFont = new Font(<FONT_FAMILY_NAME>, Font.PLAIN, 72);
Instead, the font ligatures will only be respected if it is loaded from a binary location:
// WORKING PATTERN
File myFontFile = new File(<FILE_LOCATION>);
Font fixed = Font.createFont(Font.TRUETYPE_FONT, myFontFile);
Once the font is loaded from binary, ligatures must be set via TextAttributes like so:
Map attributes = fixed.getAttributes();
attributes.put(TextAttribute.LIGATURES, TextAttribute.LIGATURES_ON);
fixed = fixed.deriveFont(attributes);
When loading fonts directly from the OS, I've taken to finding the actual font file on the system and loading it as a binary. It's cumbersome, but it functions.
At least with respect to Java2D, I read this - see Figure 4-13 as suggesting that Java will simply take the list of code points provided and render the glyph for each without combining to make ligatures.
Back before JavaFX 2, there used to be a boolean ligatures property on javafx.scene.text.Font that claimed to control whether ligatures were used, but that doesn't appear to be there anymore.
Historically (it's been at least 7 years) I've had to parse TT/OT fonts for ligatures and do the combining manually (and sometimes even pair kerning).
Since both System.setProperty("prism.lcdtext", "false") and System.setProperty("prism.lcdtext", "true") are unsatisfactory (the former appears downy whereas the latter appears colorful at the letter edges even though the text color is black; on my LCD it looks even uglier than reported here: https://bugs.openjdk.java.net/browse/JDK-8131923),
I prefer to turn off anti-aliasing entirely.
The setting SceneAntialiasing.DISABLED seems not to affect my buttons/lists/dropdowns/... (I guess it is meant for drawing only).
How can I turn off anti-aliasing completely? I would like to use a font similar to those of Windows 2000 and the first version of Win XP, which work without anti-aliasing (and besides save space because they can be scaled down more than have-to-be-smoothed fonts).
[UPDATE] Screenshot added (as requested)
The right window is generated by my ScalaFX app. Pure plain standard code, no setting applied.
(Playing with System.setProperty("prism.lcdtext", "false") and System.setProperty("prism.text", "t2k") gives me slightly better, but still unsatisfactory results.)
See the enlarged 'W' and its many colors, which stems from the first button in the right window (JavaFX): for demanding users, this is intolerable. And please compare the smoothness of the monospace texts (left: Ubuntu, right: JavaFX).
I'm having a bit of trouble with the indent guideline placement in netbeans. I can't remember when the problem started, but it's extremely distracting. The guide lines just cut directly through lines of code instead of preceding the indented blocks of code.
*note - Auto format does not fix this (Alt + Shift + F)
Problem solved
The problem was the font. For some reason when I change the font from calibri to monospaced the indent lines are back to normal. imgur link (font pictured is actually Inconsolota, no picture of calibri to monospaced)
I decided to do a little more digging and found out that mono-spaced actually varies depending on which OS is being used(courier in windows). Monospaced fonts keep all characters within the same proportions. So I'm guessing that calibri is a variable-width font(described in the wiki link). Netbeans must not adjust it's indent spacing to account for the changes in the font proportions. This causes the indent lines to look out of place, when actually the letter spacing is what throws the spacing out. I hope this information becomes useful to new users like myself. Unless you prefer the distracting lines and the squashed look, make sure the font in netbeans is a monospaced font. I recently started using Inconsolata in my editor and it's really grown on me. It looks better with Anti-A enabled in the editor so here is how to enable the feature.
cheers
-shwig
I am writing a game using libgdx, and I borrowed the skin.json (and related files) from a tutorial.
The font being used (default) was scaling in an ugly manner on denser screens, so I generated by own very large font - and in the game itself, I scale it to a reasonable size (basically I use BitmapFont.scale). The font I'm now using is 3 times as large as the previous one.
I changed the reference to which font to use in the skin.json file, and as a result, all my buttons, titles and other things have a massive font being shown.
Is there a way of scaling the font in the .json file? Or anywhere else in the code? Skin doesn't have a setFont() functionality, so I can't create a scaled BitmapFont and assign it)
Libgdx changed this back in April 2015 so that the set answer doesn't work anymore. Took a little bit to find the answer, so I thought I'd leave it here for others since this answer pops up first in Google.
this.getSkin().getFont("default-font").getData().setScale(0.33f,0.33f);
Documentation says that any gets will return a handle to the actual object. So changes will persist.
So I changed the font in skin.json to point to my new font.
Then I used this code
this.getSkin().getFont("default-font").setScale(0.33f, 0.33f);
To scale the 'default-font' (as defined in the skin.json) to the scale I wanted (in my case its 0.33f)
As of 2017 i had to use
skin.getFont("default-font").getData().setScale(0.5f);
for future users.
I have seen http://docs.oracle.com/javase/1.5.0/docs/api/java/awt/font/GlyphVector.html but I don't know how you would use it to display a glyph on the screen. Lets say you want to print glyph number 1042 (likely to be different in each font and unlikely (but possible) to be the same as Unicode 1042) to the screen. How do you go from the number to the character on screen? Is GlyphVector the way to go or is there a better method?
That GlyphVector class is not available on Android. There don’t seem to be any public API calls in Android graphics that allow access to font glyphs without going through the Unicode encoding.
Your obvious option would seem to be direct parsing of the TrueType font file. Perhaps find some library somewhere that has been ported to Android, or could be so ported (Freetype?).