[OpenJDK 2D-Dev] fixing OpenJDK font rendering

[Zhongcheng Lao]

2011/10/12 Jim Graham <james.graham at oracle.com>:
> Hi Johnson,
>
> Here is my big question...
>
> On 10/11/2011 12:01 AM, Zhongcheng Lao wrote:
>>
>> Hi, Jim
>>
>> It's never a good idea to scale fonts in L&F to conform system DPI
>> setting.
>>
>> - Johnson
>
> Why is that?
>
> Isn't it a property of the L&F how the font sizes will track (or not track)
> the screen DPI?  It's a nice feature for the fonts to scale up with the DPI
> when it keeps them readable on extreme cases of hi-DPI, but some users may
> actually not want that to happen and they may express that desire
> differently among the different L&Fs.

The L&F could scale the font, but it doesn't mean there is no need to
have a DPI equivelent property (DPI or scale factor) in Java2D and let
all things be done in L&F.
If you take a good investigation into other platforms, there is always
a such property exists explicitly or implicity.
On Windows & GTK, it is in the Display Properties and can be changed by user;
On Mac OS X, the concept of DPI do exist though it's 72dpi by default
and Apple keeps hiding the setting from users (DPI could adjusted by
Quartz Debug though it's not public yet since 10.5).
iOS also introduces scale factor in its graphics environment which is
similar to Graphics2D#scale.
The fonts (and all things on the graphic context) will be scaled
automatically if the value is larger than 1.0f, typically a Retina
display (2.0f and a very high DPI).

The platform DPI setting affects font size in pixels implicity, so you
don't need to worry about the font isn't get scaled
- It couldn't happen as platform DPI is designed for such a case.
If the user want to work in Hi-DPI, all things should be scaled
automatically since the display would probably shrink them.
It should not be the work left to app to deal with.

Yes, L&Fs could do the scale on their own.
But having some fonts scaled and others left unscaled is a huge
mistake to match system DPI setting.
The DPI setting isn't designed for that way.
If I'm working in a higher DPI environment, the GTK L&F becomes a
problem that stops me from using it.

The apps won't be a mess in most time since most layout managers will
do the right calculation on component boundaries when the fonts get
scaled.
Scaling all fonts won't be such a big problem as native app on Windows
- Win32 API don't have layout manager.
In general, not all font options of Swing components can be configured
to in an application, nor it's nessacery.
All these experience becomes not true in Java because Java2D leaves
all the works to be done in L&F and app level.
The app should always calculate font scale on its own and take very
carefully so they will not be too small, especially for
non-L&F-default fonts.
You must be aware those fonts L&F has scaled and those hasn't scaled.

So L&F should be the one providing different style of user interfaces
only, not taking the place of the real DPI.
If L&F says some fonts should be bigger than others for a more
beautiful look, it can.
But all fonts should also be scaled for a higher DPI compatibility.
The GTK and Windows L&F currently do covers the issue that Java2D
doesn't have a real DPI.

>
> Also, a L&F may have some text that it wants to scale via the DPI of the
> screen and others (say logos, or full-screen text, or large animated
> strings) that it does not want to scale.  Typically the only text it does
> want to scale are the smaller fonts that are meant for presenting
> information.
>
> Also, graphics objects are both handed to a L&F object and also to the
> client program who may have carefully decided that they want text that is 48
> pixels tall (yes, pixels, and they do *NOT* want that to be automatically
> adjusted because it isn't necessarily meant for "reading" and 48 pixels is
> tall enough that they aren't worried about 96 vs 72 DPI) and if you decide
> that, for the sake of the L&F, you will automatically scale any font request
> on a given Graphics then you may piss off the custom code in some of the
> Canvas objects.
>
> Given that the font family choices and the relative sizing of the various
> fonts are up to the L&F, I think DPI adjustments are also in their
> ballpark...

I think you get the wrong idea of system DPI.
Higher DPI usually comes with a high pixel density display.
If you don't scale the fonts and keep them in a fixed pixel size, it
will kill people.
People adjust that value to tell the system "I want bigger sizes in pixels",
so don't go against it in most apps.
If a certain app think it would be better to control all sizes in
pixels on its interface,
it could ignore the system DPI (set it to a fixed value like 72dpi by
the platform-provided API for per-app DPI configuration) and scale on
its own to do the same thing.
The platform-provided DPI setting exists there.
You can choose whatever you like.
It's what a platform should do, to provide flexibility for apps on top of it.

The best solution for a L&F to conform system DPI setting is to set
DPI it wants to apply through platform-provided API.
At least, make it possible to do that.

- Johnson