131437 - Weird FreeType font spacing

Status: RESOLVED INVALID

(Core :: Internationalization, defect)

Description

[tenthumbs]

This fell out of bug 130661.

The attached image is a montage of various screenshots of mozilla and 
ftstring from FreeType 2.0.9. All the text is anti-aliased. Note that 
the default mozilla freetype settings (no hinting) render the text 
quite differently. The best looking text for me is hinting but no 
autohinting. Note that mozilla and ftstring render the text almost 
identically although ftstring does seem to do a better job.

There is also the issue of apparent darkening in the unhinted rendering 
but I guess that should be another bug.

Comment 1

[tenthumbs]

Attachment: screenshot montage

Text is nominally 14pt Verdana regular.

Comment 2

[tenthumbs]

s/apparent darkening/apparent boldening/

Comment 3

[kill this account]

could you try applying the patch in bug 130661 and see if that
has an affect?

Comment 4

[tenthumbs]

I don't really have to time to compile mozilla at the moment but I 
doubt 130661 is relevant, that's why I filed this bug. The only font 
directory mozilla sees has only normal weight fonts. I also checked 
that each font file has only one face in it.

I did some more testing and it seems that only proportional fonts are
affected. Look at the mozilla screenshots in the upcoming attachment.  
The unhinted/hinted layouts are significantly different for
proportional fonts but the same for the fixed width ones.

For Verdana, I tried the ftstring utility. Those screenshots show
little difference. I also selected the test strings alone from the
images and cropped out any surrounding white space as a measure of the
bounding box for the entire string. I get

            unhinted  | hint, no autohint
         --------------------------------
 mozilla |   491x17   |     509x15
         |            |
ftstring |   516x17   |     509x15

Obviously, there's some horizontal spacing problem in the unhinted 
case.

Comment 5

[tenthumbs]

Attachment: screenshots.zip

Zip file with various screenshots.

Comment 6

[kill this account]

Attachment: ftstring-anti.png

Comment 7

[kill this account]

Attachment: ftstring-hint-anti.png

Comment 8

[kill this account]

Attachment: moz-anti.png

Comment 9

[kill this account]

Attachment: moz-hint-anti.png

Comment 10

[kill this account]

1st: thanks for the detailed report. It definitely helps, :).

I see that for the string "@ABCDE..." the 'C' for moz is one pixel smaller
(there are probably other spots that differ but I'm just point out the first
one).

I note that the advance width for the first 3 chars is correct then the 4th
char is one short. This makes me think it could be a rounding error for the 
advance width.

Comment 11

[kill this account]

Attachment: round instead of truncate

would you try this patch?

Comment 12

[kill this account]

I will probably need to work on this make it round correctly for negative
numbers.

Comment 13

[tenthumbs]

I really meant it when I said I didn't have time to compile mozilla. 
It's either compile mozilla or produce these wonderful bug reports. :-)

Wouldn't an inline function be better than a macro? Something like

inline int FT16_16ToReg (int x)
{
  return (x + ((x<0) ? -0x7fff : 0x7fff)) >> 16;
}

BTW, if negative numbers are really possible then you need to fix 
FT_FLOOR as well, although you don't appear to use it right now.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:m_kato, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 15

[Greg Tatum [:gregtatum]]

Closing old bugs as invalid.