Bug 29604

Created attachment 8357 [details]
screenshot

I'm told the output window actually generates (derives) a monospaced
font and a double-wide font from whatever font it is set to use -
it's probably getting some font it's not expecting.  It's based
on the terminalemulator library (dump/ansi/whatever terminal
emulation in java) which needs this.

Tell me a little more about what you did for customization (I'm
actually curious how you turned on antialiasing in Explorer) -
without knowing how you did it, there's no way to reproduce it.

when I was posting the screenshot, it was with made for 3.4 release. i
turned on antialiasing by using SmoothMetal Look&Feel, which is just a
metal l&f with anti-aliasing enforced. search the net for it if you
want to take a closer look.

with the release of Merak (3.4.1) my subjective feeling is font
antialiasing was turned on (menus, explorer windows, etc) by default.
still, the problem persists with the output window.

on my linux box (2.4.18-8) with JDK 1.4.1_01-b01 I created symbolic
links in $JAVA_HOME/fonts dir to ttf font files installed elsewhere in
the system. the runtime just picks up the fonts as if they were
located physically in the dir and I can see them in any application in
Font chooser dialog.

the problem with output window is there's no way to customise the font
for it particularly, unlike any other window in IDE - it simply
doesn't have the option button for font chooser. thus, whichever font
the terminal module opts to choose, I'm left with it.

hope this sheds some light on the issue.

regards,
Andrew

Thanks for the prompt response!  I don't know how far we want
to go in supporting foreign fonts (in this sense, by swapping
out the defalt JRE fonts, you created your own problem) - but
I agree, in theory it should work.  At the least, the OW could
try first to find a font specified for it by the look and feel,
and take it from there.

In order to reproduce your problem, precisely what fonts did
you substitute in the standard font mappings, and where can
I find them?

Those are standard microsoft fonts: arial, verdana, and courier new. I
guess every Linux Netbeans user would like to use them, as they were
specifically crafted for low-res on-screen display.

I'm attaching a modified font.properties file from my JDK. It really
seems to me that the output window uses the hardcoded font name, thus
bypassing JDK mapping (just a wild guess ;).

Created attachment 8646 [details]
JDK font mappings file

you can get hold of the pack (and install it automatically) from this
link:

http://freshmeat.net/search/?q=microsoft+fonts&section=projects&x=0&y=0

choose either the 2nd or 3rd found link, I used both, I guess.

Let's see if I can shed some light on this.

The OW being a terminalemulator lives in a gridded row/column
world and as such requires monospaced fonts to work.
I don't know of any way to enforce this other than taking
the font that the client of the Term widget specifies an
using the size and style and creating a "Monospaced" based on that.

Additionally, certain locales have characters that are double
or triple-wide. Japanese is one of them. So Term handles these
by calculating the _cell_ width of each character based on the 
glyph width. The way this works is that the pixel width of the ascii
characters is used as the standard cell width. Then all other
characters pixel width is rounded up to an integer multiple
of the standard cell width. These widths aren't explicitly associated
with te fonts or glyphs but rather are used to space them properly.

From the screenshot it seems that Monospaced was mapped to some
thing that wasn't really fixed-width and then the double-width
mechanism kicked in and started spacing characters in funny ways.

I was on the right way...

What I was doing with my font.properties file was just fine - map
courier new as the default monospace font (in Win that is done for you
from the start). Again, the font was visible to the system. It was
only that monospace couldn't be mapped to courier. After playing with
the properties file for another day (how many times did I do that, I
wonder? :), I finally found the solution.

You see, the description line for fonts in *nix is quite complicated
and no wonder there was a bug sitting.

So, the working lines were similar to that one (with other properties
changed, like bold, italic, etc):

monospaced.0=-monotype-courier new-medium-r-normal--*-%d-*-*-m-*-koi8-r

In case somebody will browse the issue, pay attention to all the
dashes and stars and their count. the last 2 options are encodings and
don't make the day if you have everything in your system.

Again, thanx a lot for your qualified assistance. I treated this issue
more like a feature request, than a bug, but didn't think javaterm was
a bit tricky to play with.

Could this feature be put in the NB 4.0 wish list?

Um, what "feature" now it is you want?

:) it's still the same, provide the option to customise output window
font.

it was quite a surprise for me it wasn't possible keeping in mind the
great flexibility and customisation spread of Netbeans Platform.

so, if it is given some low priority in the future releases TODO list,
that will make me happy, and many guys out there too (remember not all
of *nix users have root privileges to modify the font mapping, as I do).

Best regards,
Andrew
;)

Would be nice, but I'm afraid it would be a big "call generator"
as they say. I"m not sure that there is a way to ensure that a font
is fixed-width and reject it or find a suitable alternative
automatically. You'd think that going through all glyphs and checking
their size would work. It might for european locales but other locales 
might have a gazillion glyphs and there is no API to get the 
logical to physical-set mapping so you don't even know what ranges of
'char' have glyphs associated with them!

We could punt on checking and let the user choose anyway.
What will happen then is that Term will go into it's wide-char mode
which will have two effects:
	- it will be 2-4 times slower because rounding the width and
          placing the glyphs one by one is a whole lot slower than
	  placing a whole string. Check MyFontMetrics's multiCell
	  property to see the effect.
	- you will get output like you've seen. narrow characters
	  will take up one cell, wide ones two cells, or if we 
	  patch things up a bit all of them will take up two cells
	  and it won't look good.
Both of these will get people to file bugs and complain, and
"call support". 

Agreed with Ivan - verifying.

The recent 3.5.1 spin of NB was intended to fix various bugs
having to do with the chinese? locale. It might be worthwhile
running through that locale and paying special attention to the OW
to double-check that it does well.

see also 45174, 55455, 63751.
the issue is now three years old, can't be *that* complicated to fix, and you
"resolve" the issue with a 'WONTFIX'.
are you guys just incredibly overworked, or do you just not have even half a
clue about what developers want in an IDE??

see also 45174, 55455, 63751.
the issue is now three years old, can't be *that* complicated to fix, and you
"resolve" the issue with a 'WONTFIX'.
are you guys just incredibly overworked, or do you just not have even half a
clue about what developers want in an IDE??

I tend to agree that making the font size adjustable is a good idea.  Ideally 
don't do anything in the options dialog, but have some items on the popup 
menu, and a keyboard shortcut (Ctrl-+?) for this, and possibly also allow 
shift-mousewheel.  Shouldn't be terribly difficult to implement.

In the meantime, as a workaround, run with
-fontsize 18

or something such, and it will change all fonts in NetBeans to a larger size, 
including the output window.

not for 5.0

It's **not** just the size of the font that's the concern.

It's the **font-family**.

It's 2005 now.  Most of us who aren't dragging our knuckles along the ground
anymore have progressed way beyond vi and emacs, and actually expect an IDE to
"look like a bought one" even if it's free (thanks for Netbeans being free btw).

Monospaced fonts are ugly, and in the console window especially, I want to use
**proportional** fonts, so that I don't have to scroll left and right all of the
time, simply because you want to allocate as many pixels width for an 'i' as for
a 'w'.

Somehow I get the feeling that this issue (and the 3 or 4 others on the same
topic) are  going to be unresolved for *another* 3 years... I hope I'm wrong.

Dave.

FWIW ...
The termulator was created in replacement of a List based output widget.
It was done the way it was in anticipation of being used as a component
of the native IDE which has a fair amount of need for classic termulator
operation. (Not everyone enjoys peering an tweaking the mouse to capture
that narrow '.' or ':' or 'i')

Later, various considerations, including the fixed-width-font limitation
prompted Tim to write a new output widget, the output2 package/module. At
that time the termulator was taken out of the mainstream IDE and
I think that's why this RFE was closed.

Created attachment 28751 [details]
Quick and dirty patch to set font face from command line

I've attached the quick and dirty patch I sent to Dave, which adds the ability 
to set font face with a command line switch.  Bear in mind this breaks 
selection if you use a proportional font (what you see selected isn't what is 
selected).  Unless we have the ability to provide custom *fixed* font metrics 
for proportional fonts and use them that way, I don't think it's a good idea 
at all to try to support them in general - it would mean rewriting 80% of the 
output window, mainly deleting all optimizations in it, with the main result 
being that it would have poorer performance and scale badly.  There is no 
reasonable way around that - large amounts of proportional text simply does 
not scale - this is why word processors paginate.

Created attachment 28752 [details]
Adds increase/decrease font size actions

The attached patch adds increase and decrease font size actions to the popup 
menu in the output window;  they can also be accessed by Ctrl = and Ctrl - 
(think photoshop zoom controls);  you can also just use Shift+mouse wheel to 
adjust the font size.  

The only thing missing is persisting the value across sessions.  Oh to have a 
reasonable nb impl of the preferences API :-/

I left in the ability to specify font face from the command line, but it 
shouldn't be considered supported.

"Cannot change font size in output window" appears remarkably often in list of
reasons why people uninstall NB. If this is not unreasonably hard to do, we
should do it. And make sure it is easily discoverable.

output[1] had an output setting entry in Options.
output2 doesn't. 
Surely it can be brought back?

Why not use the attached patch?

I don't think putting the setting in the options dialog is a great idea.  If we
wanted to be clever we might inherit the global editor font size.

At any rate, if there are popup menu actions in the output window to adjust the
font size, that will be much more discoverable than any options setting.

Hate to sound like a broken record, but you guys seem in danger of missing the
real issue again - so, to reiterate comments I made last year - 

please don't just allow font size to be configurable - making the
**font-family** configurable is just as important (specifically - developers
such as myself want to use *proportional* fonts like Tahoma on windows.  

I've been using a patched org-netbeans-core-output2.jar from NB 4.1 to the
latest 6.0 M1 (thanks again for this Tim) and the output window runs fine in
Tahoma proprtional font.

Please can you make fonts fully configurable through the GUI at some point.

thanks,

Dave

-

Understood that it's not just the font size, but you
also have to consider that proportional width fonts for
an output window conflict with other requirements like
speed and scalability in the face of large volume of output
as well as satisfying UNIX io for output and debuggging.
It being the 21st century notwithstanding.

Allow me to push for a middle ground.
Somewhere in the comments someone said that all the 
fixed width fonts are ugly. I've been unhappy
about this myself for about 10 years as Java seems 
unable to provide small-point-size fixed width fonts that
are decent on all platforms.

So, will the following do:
- provide an entry in Options to control IO stuff.
- it will have a font-chooser
- the font chooser will only allow you to chose families that
  are fixed width. I'm banking that this will at least allow one to
  choose fonts other than the default MONOSPACED which perhaps
  would be more palatable at small point-size.
- If no such good fixed-width fonts are avaiable we redouble
  our efforts and get Java to do something about this.

why not just allow individual users to make the decision as to whether they want
to trade-off performance against a more readable output??

not allowing proportional fonts - 
1. makes the output window inconsistent with the entirety of the rest of the
IDE, and 2. allows much less data to be viewed forcing users to scroll
horizontally for long lines (proportiional fonts fit many more characters per line)

I think we had this conversation - the answer is that proportional fonts don't
scale (this is why word processors paginate), it would mean a heroic engineering
effort rewriting the output window with the end result that it's performance
would be worse.  Please consider that there is a very real problem here.  It's
not a question of just turning on proportional fonts - you are happy with the
patch I gave you because you are not doing a lot of select/copy/paste in the
output window - or you would notice that what gets copied to the clipboard is
*not* what appears selected when running with proportional fonts.  The entire
buffering strategy of the output window is built on the assumption that you can
assume all characters are of the same width.  That is why you can have 400Mb of
output in the output window, text wrap it and scroll up and down all you want
without a single performance hiccup.  Try doing that with a standard Swing
editor kit and simply click somewhere and wait several minutes for the caret to
appear - why?  It's iterating 400Mb of text to count tab characters and
character widths!

It might be possible to fake out Java2D so that you could use a proportional
font with hacked metrics (probably a trick or two with GlyphVector) so that all
characters appear to be the same width.  That would get you the nice looking
fonts, but not the proportional spacing.  Doing proportional fonts and scaling
to large volumes of output without pagination or keeping massive indexes is
simply physically impossible - if I could flap my arms and fly I would.  Dave, I
realize you don't have the problem of huge volumes of output.  But there are
people who do.

I realise that *some* developers want and need the very nice scalability that
you've built into the output window, but I don't think that you realize that
perhaps just as many developers *don't* need this output buffer scalability, and
don't care about cut/copy/paste from the output window, and just want their
output to be readable, and use the same fonts as the entire rest of the editor.

I'm not asking you to re-engineer the output component so that you can have
scalability *and proportional fonts.  I just think users should get the choice.

If you think that a lot of developers would unwittingly run into problems with
scalability, cut/copy/paste, and any other issues when switching to a
proportional font, then you're also admitting that a significatn number of
developers would *prefer* to use a proportional font of their choosing.

At the very least, how about providing a non-default, optional, netbeans module
that can be downloaded to replace the default monospaced output window, which
could be well documented with all of the caveats that you mention.  At least
then users would have the option to have a less functional but also less ugly
output window.

And I don't just ask for the sake of developers using netbeans as an IDE, but
also for developers like myself who are building software for more general
consumption on top of the netbeans platform.  End users tolerate ugly GUIs even
less that developers do.

Also note issue 87536 which requests this change for i18n reasons.  It seems the original intent of this bug has drifted in the comments; I don't want a 
proportionally spaced font, but I do want a customizable fixed-width font.  The default on Mac (Courier) is very difficult to read.

I applied the patch to add the nb.output.font property to NetBeans 6.  It does not work fully; the original font is used until you click inside the output pane, 
then it changes to the custom font.  It seems perhaps the output2 object is being lazily instantiated, but I have not investigated.

Reassigning to new module owner Tomas Holy.

Issue 43165 is more general...

*** This issue has been marked as a duplicate of 43165 ***