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.
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?
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 email@example.com: "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: firstname.lastname@example.org
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.
> 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.
Target Milestone: --- → M16
where should this go?
component: layout, and assigning to email@example.com 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.
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.
> 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.
Target Milestone: M16 → M18
is this bug now a worksforme, as the problem is not with mozilla?
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.
Assignee: asa → erik
This sounds like a dup of bug 46974.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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.
akkana - so, do you have a fix for this as well perhaps?
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.
firstname.lastname@example.org - 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.
Assignee: erik → bstell
Status: ASSIGNED → NEW
Target Milestone: M18 → Future
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.
future it. This is caused by bogus information X sent to mozilla.
Target Milestone: mozilla0.9.2 → Future
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
if this is not correct please reopen this bug.
You need to log in before you can comment on or make changes to this bug.