-
Bug
-
Resolution: Fixed
-
P4
-
1.4.2, 5.0
-
beta
-
generic, x86
-
generic, solaris_10
-
Verified
Solaris 10 x86 and AMD64 has borrowed some Xserver stuff from Linux and
there is a change in behaviour with the X server DPI
- the xserver now attempts to estimate the DPI based on monitor type
Previously Xsun would always report 90dpi whatever the real resolution
- the X11 font scaler now uses the reported DPI in scaling an XLFD which
specifies a point size unconstrained by DPI
Previously it would assume 72 DPI (yes that's inconsistent with what
the Xserver was reporting)
So the results is that any app which uses an XLFD like :
-monotype-arial-regular-r-normal--*-120-*-*-p-*-iso8859-1
expecting a 12 pt font at 72 DPI is now going to get it scaled
acc. to whatever the Xserver DPI is - and the horizontal and vertical
resolutions sometimes differ too and the font scaler applies both.
My experiments indicate that on S10 x86 and S10 amd64 both the X.org
AND the Xsun xservers exhibit this new behaviour.
The problem can easily be missed if your calculated DPI is close
enough to 72 DPI that its hard to spot the difference.
But a user with a W1100Z noticed this problem "out of the box"
The particular problem was observed with JDK's AWT/Motif
This is made more obvious because the Java2D/Swing fonts (which bypass
the Xserver) aren't affected - so "12pt" means two different things
in the same JRE, depending on whether X or Java2D does the font rendering.
What is wanted here by JDK is the old behaviour to be consistent
with AWT since JDK 1.1
But you don't need JDK to see it : just try "xfontsel".
Given that Xservers on Linux will do the same, its hard to see how
we can fix the problem at the Xserver.
Its also hard to see how we can fix all JDK font properties files
and implementations. It would be a massive and extremely risk effort.
Its very unclear to me what would happen to the font matching
in all these cases if the above XLFD became :
-monotype-arial-regular-r-normal--12-*-72-72-p-*-iso8859-1
java 2d in JDK 1.5 does in fact fill in the "72-72" resolutions
when trying to get PCF bitmaps for some CJK fonts. This turned out
to be a problem as they were available at only 75 dpi and the
Xserver decided that was not a match. In other words specifying
resolution does not play well with bitmap fonts.
So it may have to be :
-monotype-arial-regular-r-normal--12-*-*-*-p-*-iso8859-1
I am not sure why this was not used instead of points from
the beginning but its asking for regressions to change to this
in update release patches.
###@###.### 2005-04-13 18:57:00 GMT
there is a change in behaviour with the X server DPI
- the xserver now attempts to estimate the DPI based on monitor type
Previously Xsun would always report 90dpi whatever the real resolution
- the X11 font scaler now uses the reported DPI in scaling an XLFD which
specifies a point size unconstrained by DPI
Previously it would assume 72 DPI (yes that's inconsistent with what
the Xserver was reporting)
So the results is that any app which uses an XLFD like :
-monotype-arial-regular-r-normal--*-120-*-*-p-*-iso8859-1
expecting a 12 pt font at 72 DPI is now going to get it scaled
acc. to whatever the Xserver DPI is - and the horizontal and vertical
resolutions sometimes differ too and the font scaler applies both.
My experiments indicate that on S10 x86 and S10 amd64 both the X.org
AND the Xsun xservers exhibit this new behaviour.
The problem can easily be missed if your calculated DPI is close
enough to 72 DPI that its hard to spot the difference.
But a user with a W1100Z noticed this problem "out of the box"
The particular problem was observed with JDK's AWT/Motif
This is made more obvious because the Java2D/Swing fonts (which bypass
the Xserver) aren't affected - so "12pt" means two different things
in the same JRE, depending on whether X or Java2D does the font rendering.
What is wanted here by JDK is the old behaviour to be consistent
with AWT since JDK 1.1
But you don't need JDK to see it : just try "xfontsel".
Given that Xservers on Linux will do the same, its hard to see how
we can fix the problem at the Xserver.
Its also hard to see how we can fix all JDK font properties files
and implementations. It would be a massive and extremely risk effort.
Its very unclear to me what would happen to the font matching
in all these cases if the above XLFD became :
-monotype-arial-regular-r-normal--12-*-72-72-p-*-iso8859-1
java 2d in JDK 1.5 does in fact fill in the "72-72" resolutions
when trying to get PCF bitmaps for some CJK fonts. This turned out
to be a problem as they were available at only 75 dpi and the
Xserver decided that was not a match. In other words specifying
resolution does not play well with bitmap fonts.
So it may have to be :
-monotype-arial-regular-r-normal--12-*-*-*-p-*-iso8859-1
I am not sure why this was not used instead of points from
the beginning but its asking for regressions to change to this
in update release patches.
###@###.### 2005-04-13 18:57:00 GMT