[OpenJDK 2D-Dev] Font rendering issue
Phil.Race at Sun.COM
Tue Mar 23 20:10:49 UTC 2010
It could be the hinting that Mario referred to. There are some
notes (not by me) that the T2K values produced in JDK 1.4 when
hinting was available were more correct than previously - when
there was no hinting.
But Swing wanted values that looked right for some common cases
and 1.0 was excessive. I really can't remember exactly what
cases after 9 years. And I don't have the cycles to dig up
and repeat this now.
So all I can say is that looking at what freetype's results
are and adjusting for whether or not its using hinting is
probably what's needed.
Perhaps if Swing placed the mnemonics based on the underline
offset of the font it would be better .. but I think Swing
may just use the "height" of the font as the height of the
component and taking into account that underline offset
would add more runtime work and metrics churn now. And
of course that offset wasn't available in 1.1 days where
Swing started out.
On 3/23/2010 12:51 PM, Roman Kennke wrote:
> Phil, is it possible that these rounding effects are different in T2K
> vs. FT? In this case, the rounding should probably be done in the font
> backends altogether. However, I doubt I fully understand what exactly is
> going on here. My understanding is that we need to round at least up to
> the next full integer, because if height is reported as e.g. 13.1, and
> we do normal float->int conversion, this would be treated as 13.0, i.e.
> at least for some glyphs layout will end up too small. Infact, this
> would even be true if height was reported as 13.9. In my understanding,
> what needs to be done is to 'ceil' the value up to the next full integer
> here. But the comment you reference below seems to indicate otherwise.
> ceil() would have the same effect as using 1.0 as rounding value, but as
> you said, you found that 0.95 is better for some reason. I wonder why?
> Wouldn't this result in bad behaviour in some rare cases, e.g. for fonts
> that have a very small (or none) leading? OTOH, choosing the value a
> little higher (1.0) does what kind of damage? Adding one pixel too much
> for some fonts? Is this so bad?
> I also wonder why this doesn't happen with other applications that use
> Mario, it would be helpful if you made this a smaller testcase. It would
> probably render some difficult glyphs (gq_, etc) with clipping set to
> the font's reported height in different font sizes. And it should set a
> specific font, not simply use what's Swing's default, because those
> differ on FT vs. T2K. This way we could compare the FT vs. the T2K
> implementation. Maybe this gives some hints what goes wrong.
>> So a freetype specific fix is preferable here.
> The rounding should always be done when the value needs to be converted
> to int IMO, not earlier (i.e. in the freetype driving code). However,
> right now the rounding is in shared code. If we need different rounding
> values for FT vs. T2K, we need to pull this stuff into the FontScaler,
> which might be a lot of work. I took a look at how convoluted this font
> metrics code is, my god, what a mess! ;-) We have at least 6 different
> *Metrics classes, most of which seem to only carry values to another, it
> looks quite messy. Also, there's stuff like X11FontMetrics, which looks
> as if it's dead code.
> Thanks, Roman
>> On 3/23/2010 8:28 AM, Mario Torre wrote:
>>> Il giorno lun, 22/03/2010 alle 23.27 +0100, Mario Torre ha scritto:
>>>> I started tracking this because anything I write something with an
>>>> underscore in NetBeans I don't see the underscore, and that drives me
>>>> crazy (ok, it also affect JamaicaVM, but I fixed it because I type my
>>>> code in NetBeans ;)
>>> So, I can confirm that this also fixes my NetBeans bug.
>>> I created a bug entry:
>>> webrev at
More information about the 2d-dev