Under Windows 7/8, the property dialog for a JTextArea indicates Tahoma 11 Plain font but this is not explicitly set in the generated GUI code.
Attempts to set alternate fonts and point sizes succeed with explicit calls in the generated GUI code.
Attempts to explicitly set Tahoma 11 Plain because the builder removes the call to jTextArea.setFont(new java.awt.Font("Tahoma", 0, 11)); and (incorrectly) relies on the L&F defaults.
The GUI builder should explicitly set a font appropriate to the OS.
Something real odd going on here...
A day later after several reboots and a move to a different work location, I find that the self same JTextArea I had problems with yesterday now reports Monospaced 13 plain as the default when I look at the property editor.
But - when I look at the GUI code, there is no call to .setFont(new java.awt.Font("Monospaced", 0, 13));
I think the issue here is that the property editor should reflect <default> when no font is set (on any Component) and should offer a selection of fonts via the current dialog - which should then be written to code.
There is indeed a problem in the GUI builder that it does not allow to "force" setting of a font property in case it matches the actual default font -- because it might not be default in runtime. It's already reported in bug 136260 I think.
For most (all other) properties it makes sense not to generate code for default values, but the fonts (maybe also colors) would deserve this option since the desired value may match the actual default in the IDE only incidentally.
A simple workaround: just write the code setting the font manually, e.g. just after the initComponents() call in the code editor.
*** This bug has been marked as a duplicate of bug 136260 ***