63831 - bad character display with freetype

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Stanislav Brabec]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-test10 i686; en-US; m18)
Gecko/20001213
BuildID:    0000000000

If exact match for fonts+sizes+charset is not available (for example for tag
<font face="Arial, Helvetica" size="2">) on local machine and bigger replacement
font is used, the result are horizontally overfull boxes, minimal interword
spaces etc. Seems like metrics information are taken from original font size,
but larger font is used. For example see upper mentioned snapshot.


Reproducible: Always
Steps to Reproduce:
Significantly reduce available fonts on X server. Especially disable all
scalable fonts.
Open any page with font size tag.


Actual Results:  Overfull horizontal boxes, see shapshot on
ftp://ftp.penguin.cz/pub/users/utx/temp/mozilla-bad-font.gif


Expected Results:  Rational choosing font from available fonts and using metrics
of actually used font.

Comment 1

[Keyser Sose]

Reporter have you tried updating to one of the latest nightlies? Does that fix
the problem?

Comment 2

[Mark Olson]

Stanislav Brabec, could you please take a look at this again with a more recent
nightly build to confirm that it is still a problem?  None of the qa folks have
a system with a limited enough font set to reproduce this.  Thanks.

Comment 3

[Keyser Sose]

From Reporter:

The bug in font rendering is still here. I have investigated some effort
to find, which font is rendered incorrectly. So there is for example:

-freetype-arial-medium-r-normal--12-120-75-75-p-65-iso10646-1

When I have disconnected directory containing this font from font path,
rendering became correct.


So this bug should be renamed to
Bad rendering of 16-bit fonts


This font was created by freetype tools from standard Windows arial font.
I have tried to verify metrics information in this font by:
xmessage -fn -freetype-arial-medium-r-normal--12-120-75-75-p-65-iso10646-1
"<some test text>"
and the box width appears to be correct.

Notes:
- Bug doesn't depends whether X11R6 FontPath contains :unscaled or not.
- Mozilla correctly select characters dependently on charset from this
  font, only metrics is bad.


If you will need more info, I can send it.


I have updated to following:
mozilla-SeaMonkeyAll/HEAD-CVS20010106
orbit-0.5.6-CVS
gtk+-1.2.9-CVS
glibc-2.2-CVS
XFree86-4.0.2
linux-2.4.0
gcc-2.95.2

Comment 4

[Keyser Sose]

Marking NEW.

Comment 5

[Mark Olson]

Stanislav, could you please follow up using bugzilla rather than via email?
Thank you.

Also, CVS is an acceptable alternative to nightly builds.  We are simply
concerned that bugs are reported with recent versions of the code.  Thanks for
the followup.

Further comments from Stanislav Brabec via email:

The problem seems to be not limited fontset, but certain fonts. Maybe I
can help you with my notes.

You probably could be able to repeat the bug:

mkdir /usr/X11R6/lib/X11/fonts/X11_winfonts
cd /usr/X11R6/lib/X11/fonts/X11_winfonts
for i in /dosc/windows/fonts/*.ttf
do
  /usr/src/xc/extras/FreeType/contrib/ttf2bdf/ttf2bdf -r 75 $i -o `basename $i
.ttf`-75.bdf
done
for i in /dosc/windows/fonts/*.fon
do
  fnt2bdf $i
done
for i in *.bdf
do
  bdftopcf -o `basename $i .bdf`.pcf $i
done
rm *.bdf
gzip *.pcf
mkfontdir
xset +fp `pwd`

For completness: Freetype was from XFree86-4.0.1 and Windows 95.
I have created these fonts specially for Wine.

Now open mozilla and find page which asks Arial before Helvetica
(for example www.root.cz, latin-1 example was in report).


Sorry, I have only slow & expensive dial-up line and don't use night
build. I am using CVS and recompilation takes about 8 hours (if it
success). I have found this bug since pre-M18 up to CVS-2001-01-06, so I
guess it isn't a random bug.

Comment 6

[karnaze (gone)]

Reassigning to erik.

Comment 7

[Stanislav Brabec]

I have updated my bug test package:

I have placed few problematic fonts at
ftp://ftp.penguin.cz/pub/users/utx/temp/X11_winfonts.tar.gz
You can download them, add then to fontpath, restart mozilla and go to (for
example) http://www.root.cz
You can see something similar to
ftp://ftp.penguin.cz/pub/users/utx/temp/mozilla-bad-font.gif

Comment 8

[Frank Tang]

reassign to bstell. mark it as P2 moz0.9.3

Comment 9

[Frank Tang]

katakai- please work with bstell for this.

Comment 10

[kill this account]

renaming from:

  Bad rendering of 16 bit fonts

to:

  Windows Arial font renders poorly on Linux

Comment 11

[Frank Tang]

move to moz0.9.2 from nonsense moz0.9.3
bstell- can we address this on 0.9.2 time frame, do we need to? if not, move to 
future.

Comment 12

[Frank Tang]

This seems the same problem as the true type server issues. move it to moz0.9.3 
since it is not moz0.9.2 critical. 

Comment 13

[kill this account]

is this the same bug as 59915?

Comment 14

[Stanislav Brabec]

It isn't probably equal to bug 59915. I have converted TrueType to bitmaps. But
it can be bug outside mozilla in font width calculating stuff (I have used ttf2bdf).

Comment 15

[kill this account]

Stanislav: you might want to look at bug 78643 (bug 59915 was dup'd to 78643)
seems like a similar issue.

Comment 16

[kill this account]

Attachment: simple test case using a freetype-arial-iso10646-1 font

Comment 17

[kill this account]

Attachment: screen capture of the simple test case

Comment 18

[kill this account]

the text is 8 bit data being measured/rendered with a 16 bit font.

The text measuring in nsTextFrame::MeasureText line 4321 is

  "one word at a time"

but the text is being drawn as continous text in 
nsRenderingContextGTK::DrawString line 1356

I suspect that the space width calculation is wrong.

http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#4321

I changed the title from:

  Windows Arial font renders poorly on Linux

to

  Linux: wrong width for 8 bit data rendered with 16 bit font

Comment 19

[kill this account]

for the space width calculation both aTs.mWordSpacing and aTs.mSpaceWidth are 0.

width = wordLen*(aTs.mWordSpacing + aTs.mSpaceWidth);// XXX simplistic

http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#4496

Comment 20

[kill this account]

Attachment: patch; use 16 bit data with 16 bit font when measuring space char

Comment 21

[kill this account]

should I use this test:

  if ((xfont->min_byte1 == 0) && (xfont->max_byte1 == 0))
    is 8 bit

instead of this:

  if (mWesternFont->GetGDKFontIs10646())
    is 16 bit  

Comment 22

[kill this account]

Attachment: patch; test for 16 bit font instead of iso10646 font

Comment 23

[kill this account]

The basic problem here is that the existing code assumes the first font is an
8 bit font and passes in an 8 bit space character for measurement. When this
8 bit space char is passed in for measurement with a 16 bit font the result is
0 width (probably should be "mal-formed data").The line width is measured one
word at a time so the measured length has zero width spaces while the drawn
has actual width spaces leading to drawn text that extends too far.

When a 16 bit font is the first font then we need to pass in a 16 bit space 
char. These two patches, attachment 41534 [details] [diff] [review] and attachment 41551 [details] [diff] [review], use an 8 bit 
space char for an 8 bit font and a 16 bit space char for a 16 bit font.

I prefer attachment 41551 [details] [diff] [review] since the problem could occur with a 16 bit font that 
is not iso10646.

Comment 24

[Frank Tang]

I think this should be a PDT+ bug. 59915 which is dup of this is marked as PDT+,
so I mark this one as PDT+ now. 

The patch seems very reasonable and simply. 
This was mark as PDT+ once and remove because we think we cannot find the fix on
time. In other word, it is critical enough. Now we know the fix is not risky

r=ftang
ask for sr= please

Comment 25

[kill this account]

This occurs when the CSS specifies a font (the user pref cannot presently
specify a 16 bit font: bug 41721) and the system has 16 bit fonts; typically
TrueType fonts.

Since newer Linux systems have 16 bit fonts installed by default it is seen
more frequently on these systems but this can occur on older systems where
16 bit fonts have been installed.

Comment 26

[Simon Fraser [no longer active]]

sr=sfraser

Comment 27

[kill this account]

checked in to trunk and branch

Comment 28

[kill this account]

*** Bug 78643 has been marked as a duplicate of this bug. ***

Comment 29

[Boris Zbarsky [:bzbarsky]]

*** Bug 88581 has been marked as a duplicate of this bug. ***

Comment 30

[Jacek Piskozub]

Marking mostfreq at 11 dups (for completness and in case the bug is reopened)

Comment 31

[Francisco León]

Guys, i dont know if this should be in this bug, bug please take a look at
http://www.linuxhardware.org/features/01/07/13/145249.shtml

and scroll down after the quake3 arena benchmark
Text is all messed up overlapping more text
Mandrake 8, XFree 4.1, build 2001071704

Comment 32

[Keyser Sose]

*** Bug 86574 has been marked as a duplicate of this bug. ***

Comment 33

[kill this account]

*** Bug 51920 has been marked as a duplicate of this bug. ***

Comment 34

[Keyser Sose]

*** Bug 90125 has been marked as a duplicate of this bug. ***

Comment 35

[Jeremy M. Dolan]

Removed relnote for 0.9.4, as this is FIXED. The URL Francisco León posted also
seems to work fine for me, with todays 094 build in linux.

Comment 36

[kill this account]

Jeremy: just to separate some of the various problems:

This bug, bug 63831, is about incorrect widths (specifically the space
char width) when using fonts generated by a FreeType X Font Ferver.

Bug 95280 is about fonts generated by an FreeType X Font Server being
unattractive (compared to hand generated fonts).

Bug 87738 is about characters drawn from fonts generated by a FreeType X
Font Server sometimes being drawn incorrectly; eg: part of a line of text is
shifted one pixel vertically.

Bug 87055 is about bitmap scaled fonts (really ugly) (not related to FreeType) 
be selected.

Comment 37

[Chris Petersen]

*** Bug 107414 has been marked as a duplicate of this bug. ***