51920 - bad character display with freetype

Status: RESOLVED DUPLICATE of bug 63831

(SeaMonkey :: General, defect, P3)

Description

[José Carlos Monteiro]

From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.17 i686)
BuildID:    2000090121

When I use True Type fonts with Mozilla - either on XFree 3.3.6, or on XFree
4.0.1, with freetype - some characters on the screen turn into squares. Almost
every web page gets some "squared" text. Most of the text on the Mozilla dialog
boxes gets squared too.

Reproducible: Always
Steps to Reproduce:
1. Install freetype with your X-server.
2. Set some True Type fonts directory
3. Run Mozilla.

Actual Results:  By then you'll be knowing what I'm talking about.
Instead of figures and letters, you get a lot of squares.						

Expected Results:  No squares. Just proper characters.						

On XFree 3.x you had to install freetype and xfsft manually.
Since XFree 4.x, freetype comes integrated in the XFree package, and you can
define a TTF directory on /etc/X11/XFConfig just as easily as you define a Type1
fonts directory.

Comment 1

[R.K.Aa.]

freetype is just a library. There are two true-type font-servers included with
xfree86 v.4.* that both can utilize the freetype library. Which one do you use?

Comment 2

[R.K.Aa.]

Reporter: Bugzilla automagically issue e-mails when bug reports are modified,
amongst others to the reporter - in this case yourself :)
Which means that to reply: it's best if you click the link to the bug listed
towards top of the mail, and add comments in the box for "Additional Comments".

--------

Got mail from [e-mail]:

"I was using xfsft (the "freetype" module), but I got curious when you
mentioned that there were two TTF-servers, so I put XFree86 loading X-TrueType
(the "xtt" module) instead. The outcome for Mozilla was a little different,
but still not usable. With X-TrueType I get blanks instead of squares. As
before, this strange behaviour showed its effects on most Mozilla dialog-box
text, and some webpage text.

I must say that this bug is kind of recent. Up until M15 it didn't exist. Only
after M16 did it show. I know I should've reported this before, but I hoped it
was a temporary thing."

---

jcm:

I may have a solution for you.
A while back i discovered that the utility that creates fonts.scale (ttmkfdir)
will sort them in reverse. In some cases - in particular when a font contain
"charcell" characters (a special type of monotype fonts designed for
console-use) - ttmkfdir will list those first instead of last.

Many TT fonts are not complete, but for instance the so called "webfonts" from
Microsoft, have a limited set of charcell characteres embalmed in the fonts. (in
addition to limited sets of characters for various national fonts)

ttmkfdir will list these in fonts.scale with iso-****-15 first, and iso-****-1
last, and IF a charcell font exists in the font, it will even list that on top
of all the others.

The way mozilla works it that it will use the first instance found of the font.
Which - as you perhaps understand - can wind up giving some weird results.

A fix for this is basically easy:
-Reverse the contents of fonts.scale and fonts.dir
-rehash xfsft

I wrote a full walkthrough to be found at:
http://home.c2i.net/dark/linux.html#ttf
http://home.c2i.net/ldark/inux.html#fuzzy

Take care to reinstate the "font-count" digit on top of the files:
unix fontsystems expect to find a number representing amount of installed fonts
in a dir on TOP of these files, but after the reverse they will be on bottom
instead. This must be manually edited for now.


I'm not 100% sure this is what cause your problems, but your bug sounds like
xfsft doesn't find the right font to use. The links above may set you off in the
right direction.

If it works OK after some editing according to descriptions on web, report back
here so others can benefit. You may direct questions to me at home: [e-mail]

Comment 3

[R.K.Aa.]

Hmmm... a question:
When M15 was around: Were you using XFree86 v.4.* at the time?
If you upgraded later, this might be as easy as wrong permissions on files or a
dir, or possibly a missing path somewhere.

Comment 4

[José Carlos Monteiro]

> When M15 was around: Were you using XFree86 v.4.* at the time?

No. I only changed to 4.x this week, and I've been using Mozilla since M14. To
be sure, I reinstalled M15 today, and the character display was fine.

Comment 5

[Doron Rosenberg (IBM)]

where should this go?

Comment 6

[R.K.Aa.]

component: layout, and assigning to [e-mail] would be a natural choise.

But i think it's something wrong with the xfree86 v.4 setup in this case.
I have no problems displaying fonts with xfsft using xfree86 3.3.6-20.

Comment 7

[R.K.Aa.]

as an additional precaution: Is reporter 100% sure he's testing this with a
clean install? There has been changes in font handling since M15, and if you use
an old profile, settings for fontsets and more may be wildly wrong now,
incompatible with recent builds.

Comment 8

[José Carlos Monteiro]

> Reverse the contents of fonts.scale and fonts.dir

I did as you suggested, I reversed the contents of fonts.scale and fonts.dir,
and it worked! The character display now is fine. Thanks!
But, I think Mozilla shouldn't depend on this ttmkfdir issue, in order to work
properly.


> Is reporter 100% sure he's testing this with a clean install?

Yes, I'm 100% sure.

Comment 9

[Doron Rosenberg (IBM)]

is this bug now a worksforme, as the problem is not with mozilla?

Comment 10

[Akkana Peck]

What a bummer.  Here I was thinking that XF86 4.0 might be the easy solution for
users plagued by bug 46415, but it sounds like that will just introduce new
problems which users will have to work around.

Comment 11

[Erik van der Poel]

This sounds like a dup of bug 46974.

Comment 12

[R.K.Aa.]

Erik: This is the exact same phenomena that caused bug 39553, which you later
set invalid.

We discussed it at some length there and in mail, and i sent you the URL's to
the fix i described on web. I still disagree with the conlusion that was made;
That moz should strictly confirm to the order in which X list fonts. You told it
was a decision caused by...err...something like peer pressure by orthodox unix
users in the newsgroups.

They are wrong in this case, however, and *I* am right :) Unix users aren't much
used to ttf fonts at all, and i doubt they have any idea what mishap the anarchy
of X can lead to.

In addition: Since fonts.scale files are ultimately supposed to be edited by
hand, this means that X is victim of whatever whim an individual user had at the
time the file was created. There are tools to aid - yes - but some of the most
widespread utilities aren't so good it hurts.

IMHO i still think that aiding the font-sorting is a Very Good Idea; Moz should
NOT just swallow whatever private chaos X feeds it.

The help-stuff i have written on web is now partly included in LDP's Font
Deuglification HOWTO, the rest is linked to, and I'm invited to co-author it.
Guess i ought to...there is Much Confusion out there.

Comment 13

[Doron Rosenberg (IBM)]

akkana - so, do you have a fix for this as well perhaps?

Comment 14

[Akkana Peck]

No -- I'm not even using TT fonts, just had been hoping that they might be the
solution to bug 46415 (see my comments in that bug for the non-TT workaround I'm
currently using).

I tend to agree with R.K.Aa that it would be better if Mozilla applied some
intelligence, since most installed packages (whether TT or not) seem to end up
installing something that will cause Mozilla not to work right, and even if
that's a problem with the fonts or with the way the packages are set up, it
won't look like that to the user: all they'll see is "When I use Mozilla on
linux, I can't read most pages, so I'm sticking with some other browser, or
using IE on Windows."  At the very least, we should relnote it and link to
R.K.Aa's excellent pages.

Comment 15

[Frank Tang]

[e-mail] - is this a dup of 46974
Does this problem got fix with the fix in 46974 ?
reassign to bstell and mark it as Future untill more info.

Comment 16

[Raja Harinath]

There are still some problems after using R.K.Aa's trick.  I've attached a
screenshot which shows problems with font metrics of TrueType fonts, when
using xfsft with XFree86 3.3.x.  The same font server, when used with
Netscape 4.7 doesn't exhibit any problems with font metrics.

Comment 17

[Raja Harinath]

Attachment: Problems with font metrics using TrueType fonts

Comment 18

[Frank Tang]

future it. This is caused by bogus information X sent to mozilla. 

Comment 19

[kill this account]

I believe this is a dup of bug 63831.

*** This bug has been marked as a duplicate of 63831 ***

Comment 20

[kill this account]

if this is not correct please reopen this bug.