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
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).
In these modern times, Eclipse's rounded and/or swooshing tabs are beginning to look a little bit quaint.
I was hoping that a suitably placed:
swt-corner-radius : 0px
in my default.css would do the trick, but I can't seem to affect the main editor tabs no matter what I try.
Anyone know how I should go about achieving this (or even if it's possible?). I'm building an RCP app based on Eclipse Kepler.
Setting
swt-simple: true;
Gets rid of the 'swoosh" (sloping edge).
The standard tab renderer always draws the top left and right corners with a small curve. If you want to replace that you would need to write your own tab renderer - which you can specify using something like:
swt-tab-renderer: url('bundleclass://plugin id/package.TabRendering');
but this is quite tricky!
Finally you can always set the outline colors to match the background so they don't show - like this:
Eclipse 4.16 (officially released in 2020-06) supports setting square editor tabs by setting the corner radius to 0:
swt-corner-radius : 0px;
Note that using any small value below 6px will effectively result in square tabs as well.
Here's how it looks visually:
See the platform announcement for more information and bug 538740 for the technical implementation details.
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.
The title pretty much sums it up - its the easiest thing in the
world in C++ and Windows, but Java seems to struggle with this issue.
I would like to stay away from solutions involving loading bitmaps of fonts, and instead try go for a native truetype font loader, if possible. Kerning and antialiasing is quite important in my application.
JOGL has a class, TextRenderer, which should do what you want. It accepts a Java "Font" object, and I think you can specify any ttf file for such objects. It does also support antialiasing, I'm not sure what kerning is but probably that too. :)
Unfortunately the JOGL docs are currently... missing. Dunno where they went, hopefully they'll be back soon (in a day or two). Otherwise I would link you to the documentation for the class. Sorry!
Use the JOGL/Java 2D bridge: render the font on a texture.
Check out "Java 2D and JOGL"[1]
[1]: http://weblogs.java.net/blog/campbell/archive/2007/01/java_2d_and_jog.html ""
Another thing you can do (e.g. if you want full lighting functionality for the text) is construct a GlyphVector from the font and string and use a GLUtessellator to render it as a set of triangles.
JOGL is pretty good. I've used Processing (processing.org) before that renders nice text. Yes, C++ and OpenGL under Windows does seem easy as the Font management is different (Linux and MacOSX = Much harder to do text with OpenGL I've found)