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 Freetype? 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 > > -phil. > > 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 ;) > > > > ... > > > >> [2] > >> http://www.limasoftware.net/neugens/downloads/stuff/font2dbug/possible_fix.png > > > > So, I can confirm that this also fixes my NetBeans bug. > > > > I created a bug entry: > > > > https://bugs.openjdk.java.net/show_bug.cgi?id=100134 > > > > webrev at > > > > http://cr.openjdk.java.net/~neugens/100134/webrev.00/ > > > > Cheers, > > Mario >