[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] fixing OpenJDK font rendering
From:       james.graham () oracle ! com (Jim Graham)
Date:       2011-10-12 19:56:43
Message-ID: 4E95F0FB.3030206 () oracle ! com
[Download RAW message or body]

Hi Johnson,

Please familiarize yourself with 
GraphicsConfiguration.getNormalizingTransform() and the language in the 
Graphics2D class documentation under the heading "Coordinate Spaces". 
We do have mechanisms designed to address everything you've identified 
here.  We are quite familiar with all of these concepts and even 
designed the APIs with these issues in mind over a decade ago.

The issues aren't a lack of mechanism or awareness, they are issues of 
strategy and feasibility of implementation.  And, we have had several 
(quite lengthy) discussions internally over the past few years of which 
actions we should take to start invoking these mechanisms whether by 
default or by a user/developer configurable action.  Phil, and some of 
the members of our Swing team, is/are a little more familiar with many 
of the details of the "whens" and "whys" of whether we are ready to 
start performing automatic adjustments.

 From this message it sounds like you have a good handle on the issues 
as well, and perhaps from a different perspective, so it is probably a 
good time to reevaluate our defaults.  But, the mechanism you are 
proposing does not seem to match either:

A - the mechanisms we have already created for these purposes and can 
deploy if we need to

B - the full gamut of what others might be doing with our Graphics system.

So, with that in mind, please read what I said not as "this is why we 
would never listen to you or do what you want", but more as "we know, we 
know, but to propose an actual solution you should consider these other 
cases as well and how your proposal would affect these other developers 
- then we can start a real discussion"...

			...jim

On 10/11/2011 8:40 PM, Zhongcheng Lao wrote:
> 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

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic