Closed Bug 22031 Opened 25 years ago Closed 24 years ago

'MS Sans Serif' (+ other bitmap fonts) don't work on WinNT

Categories

(Core :: CSS Parsing and Computation, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: 3jrgm, Assigned: erik)

References

()

Details

(Keywords: css1, fonts, platform-parity, Whiteboard: [nsbeta2+] fix checked in)

Attachments

(3 files)

Mozilla 1999121508 on WinNT does not recognize 'MS Sans Serif', either
as <FONT FACE='MS Sans Serif'></FONT> or as "font-family: 'MS Sans
Serif'". Navigator 4.7 on the same machine does display properly using
this font. Couldn't find a DUPL. Guessing 'Style System'. Attaching minimum
test case.

Properties for \winnt\fonts\sserife.fon are Version: 4.10.1684,
``MS Sans Serif font 8,10,12,14,18,24 (VGA)''
QA Contact: chrisd → petersen
Assignee: pierre → dcone
Summary: 'MS Sans Serif' not recognized on WinNT → [PP] 'MS Sans Serif' not recognized on WinNT
It seems to only happen with that particular font. If you change "MS Sans Serif"
to "Impact" or "Courier New Italic", it works.

It's probably a problem in nsDeviceContextWin.cpp for which there is no clear
owner. Reassigned to dcone who certainly can help.
Summary: [PP] 'MS Sans Serif' not recognized on WinNT → [PP] 'MS Sans Serif' (+ other fonts) not recognized on WinNT
I noticed also that Verdana wasn't working. And then I tried the most
common fonts used in web pages -- the _most_ common display: Courier,
Courier New, Times New Roman, Arial, Helvetica (plus Impact which is
less common).

 But Tahoma, Verdana, and Georgia don't display in addition to 'MS Sans
Serif'. I didn't test every font [partially since I don't know what
some of them are supposed to look like anyways ;)]
Doh. I don't have Helvetica, but I got a sans-serif font, but I assume this is
an intentional kludge.
Status: NEW → ASSIGNED
Target Milestone: M14
*** Bug 24003 has been marked as a duplicate of this bug. ***
Keywords: css1
Assignee: dcone → erik
Status: ASSIGNED → NEW
Georgia, Tahoma and Verdana work for me on NT4. MS Sans Serif does not work
because it is not a TrueType font. This is a limitation of the current Windows
GFX code that I wrote.
Status: NEW → ASSIGNED
Target Milestone: M14 → M16
Keywords: pp
Moving all M16s to M17. Please make comments if you disagree.
Target Milestone: M16 → M17
Summary: [PP] 'MS Sans Serif' (+ other fonts) not recognized on WinNT → 'MS Sans Serif' (+ other fonts) not recognized on WinNT
Not limited to NT; also fails to use requested MS Sans Serif on Win98.  Many
sites are using this font since it is compact and legible at smaller sizes; cf
http://www.cnet.com/
Erik -- here's the min. test case I've been using for this bug:

<title>bug24003</title>
<span style="background-color:yellow"><a 
href="bug24003.html">Next...</a></span><br><br>

<TABLE BORDER=1>
  <TR>
    <TD>
      <FONT FACE="geneva, ms sans serif">
        <A HREF="foo">text here</a>      
      </FONT>
    </TD>
  </tr>
</TABLE>
My guess is raster fonts (versus TrueType fonts) don't work (yet). Another issue
is when both types of fonts are present with the same name. My pet problem is
the "Symbol" font which is normally installed on Windows PCs as both a raster
font and a TrueType font. It appears that Windows is "mapping" the raster not
the vector font and...the raster font is not yet supported in Mozilla.

I really need the symbol font for my website which displays calculus problems
and at this point I can only tell users "don't use Netscape 5, try 4.x or
(shudder) Internet Explorer."

At the least, how about a look into getting the font mapper to load the TrueType
font when it is available rather than letting Winders pick it for you.


Roger, please take a look at the previous comment in this bug report. It talks
about the bitmap and TrueType versions of Symbol. I believe you dealt with that
at one point. Did you actually check anything in for that? Thanks!
Yes, erik, I checked a change to give precedence to TT fonts.

The selection involves LOGFONT.lfOutPrecision. To alter the font mapping
algorithm, the values of lfOutPrecision that are of interest are:

OUT_TT_PRECIS 
   Instructs the font mapper to choose a TrueType font when
   the system contains multiple fonts with the same name. 

OUT_TT_ONLY_PRECIS 
  Instructs the font mapper to choose from only TrueType fonts.
  If there are no TrueType fonts installed in the system, the 
  font mapper returns to default behavior.

I was having the very same problem described above, and I changed the
font code in nsFontMetricsWin::FillLogFont() to use OUT_TT_PRECIS; this
fixed the problem.

As a matter of fact, the documentation says "if an operating system contains
a font named Symbol in raster and TrueType form, specifying OUT_TT_PRECIS
forces the font mapper to choose the TrueType version. Specifying 
OUT_TT_ONLY_PRECIS forces the font mapper to choose a TrueType font, 
even if it must substitute a TrueType font of another name."

It is rather curious that MarkCarson@hawaii.rr.com is still having
the problem. We can still try OUT_TT_ONLY_PRECIS which "specifies that only 
TrueType fonts should be considered for the exact matching. None of the other 
types of physical fonts are considered. This filter is useful for an application 
that wants to guarantee that the realized font is a TrueType font."
Erik and Roger, thanks for looking into this bug. I see the "logFont-
>lfOutPrecision   = OUT_TT_PRECIS;" statement on line 191 of the checked in 
code. Just a thought here, but is the Symbol font considered to be a different 
character set versus just a font face? If so the previous line (190) which 
reads "logFont->lfCharSet = DEFAULT_CHARSET;" may the problem. Your thoughts?
FillLogFont() is primarily used to enumerate available TT fonts.
There is another place where the SYMBOL_CHARSET is detected an used
to override the default charset (when actually loading the font,
see lines 1045-1058, and lines 1493-1497.)

BTW, on which platform/version are you seeing the problem.
My problem with the Symbol font is on Windows NT 4.0 (both server and 
workstation). I have seen this problem for many months (M12, M13, M14) and it 
continues through the nightly build of 16-MAR-2000. The system is usually run 
the nightly build against has the raster font "Symbol" (symbole.fon), the 
TrueType font "Symbol" (symbol.ttf), and a TrueType font which I believe 
is called "Symbol Proportional".
*** Bug 28535 has been marked as a duplicate of this bug. ***
*** Bug 32321 has been marked as a duplicate of this bug. ***
Erik, may I suggest raising the priority on that bug? I put M15 after checking 
your bug list.
Target Milestone: M17 → M15
Pierre, I'd like to understand why you'd like to raise the priority. Is it
because CNET use MS Sans Serif?

I know what I need to do to resolve this bug. Currently, the font engine relies
on TrueType "cmap" tables to figure out which glyphs are present. Since bitmap
fonts don't have cmap tables, it's hard to tell (programmatically) which glyphs
are there. A quick look using charmap on Win95 shows that most of the Windows
extensions of ISO-8859-1 (i.e. 0x80 - 0x9F) are missing in MS Sans Serif. This
includes the euro, trademark, ellipsis, mdash, some smart quotes, etc. However,
all of the ISO-8859-1 glyphs are there. So I suppose I could look at the results
returned by Windows's font enumerator to see which Windows charset is supported
by bitmap fonts, and then assume that even if it says ANSI_CHARSET, that it
isn't really complete, and only contains ISO-8859-1. Then the font switching
machinery can continue its search, moving on to fonts that *do* contain those
glyphs. We would probably end up with TrueType fonts for those glyphs. Oh well,
there isn't much else that we can do about deficient fonts now, is there?

I assert that this is merely a *bug*, as opposed to a *feature*, and since I am
still in the feature implementation mode as we head towards the M16 feature
completion date, I am setting the target to M17. If anybody wants to have this
fixed sooner than that, they can fix it themselves, based on the info I have
provided above.
Target Milestone: M15 → M17
Yep, I rose the priority because of CNet. ICQ has the same problem (maybe even 
worse - I wrote the webmaster about it).

You graciously lent your time on font issues during quite some time and it's been 
very much appreciated but, of course, if you no longer have the oppportunity to 
work on it, please reassign to the usual suspects: dcone or kmcclusk.
I'm going to close bug 33127 as dup of this one. It has a nice testcase at the 
following url: http://www.mozilla.org/quality/browser/bft/bft_image_trans.html

Interestingly enough, this page is one of the very first demo pages used in 
Gecko. It doesn't work anymore because it uses Symbol.
*** Bug 33127 has been marked as a duplicate of this bug. ***
I marked bug 33127 INVALID, because if the document asks for the text "Opaque",
the browser is supposed to render that with glyphs that resemble that English
word, rather than some Greek gibberish from the Symbol font. Bug 33127 is not
related to this bug.
Bug 31538 shows that the problem occurs even with fonts that exist only as 
TrueType fonts, which means that your explanation from 2000-01-17 19:41 isn't 
valid. We should raise the priority on this problem.
The current font selection code relies on Unicode points. There is no (yet) a 
rendering based on direct glyph indices. This may explain why the <FONT FACE="">
are not working as in old versions of Nav. For example, if the document
contains <font face="symbol">a</font>, then GFX will render "a" instead of the
glyph whose index is the numeric value "a".

MarkCarson@hawaii.rr.com, do you see something when you try this
little document:

<head><title>Symbol</title></head>
<body>
alpha: &#x03B1;
beta:  &#x03B2;
</body>
Reply to question from rbs@maths.uq.edu.au dated 2000-03-25 01:01:

Your test HTML document (which used Unicode values for Symbol glyphs) DOES work 
correctly in Mozilla nightly build 2000032308. Also Internet Explorer 5 displays 
this unicode correctly. Unfortunately, Navigator 4.7 does NOT. 

<RANT>
I appreciate that unicode is a better way to express the symbol and a move 
forward for browsers, however.....because Navigator 4.x still does not support 
this encoding, I once again have to create 2 versions of web pages which need 
the Symbol font, or I write conditional code into ASP and JSP (which also makes 
every one of these pages dynamic versus static pages with associated 
performance penalty). I surely support the level of compliance aimed for via 
unicode, but backward compatability is essential to not break existing pages 
which "work" with previous versions of Navigator. I could see it if the position 
was to not be compatible with older versions of IE, but to orphan existing 
Navigator pages will alienate content creators who are currently loyal to 
Netscape and look forward to a smooth migration to Mozilla. Ponder for a moment 
the slow acceptance of Windows 2000 server because of its lack of backward 
compatiblity and interoperability with Windows NT 4 and 9x. Does the Mozilla 
effort really want to get aboard that kind of sinking ship? I hope not.
</RANT>

Also I have to cop to a bug in my example HTML code. The "default example" row 
also has SYMBOL specified and it should not, so it displays whatever face as the 
following row which is the "SYMBOL example" row. My humble apologies. Pierre, 
can you correct the code by removing the "FACE" attribute in the FONT tag on the  
offending row?

-- Mark Carson 0205/25-MAR-2000
So GFX is behaving as expected (i.e., by design). And the problem reduces down
to yet another difference when the NavQuirk mode is enabled. Under this mode,
GFX should interpret chars as glyph indices. This is something that Erik, and
Pierre can now decide what to do about. If this is done, many of the <font face>
"bugs" could go away. (The fact that bitmap fonts are not yet supported is a
separate issue.)
I'd agree with that and commented about it in bug 33258.
Bug 6585 has also other options (in addition to this NavQuirks mode) to 
make the rendering less monolithic. BTW, the char* functions that are in
nsRenderingContextWin.cpp seem to be the functions that were in use at
the time of the demo. These functions are still there but are not called
anymore from layout.
Summary: 'MS Sans Serif' (+ other fonts) not recognized on WinNT → 'MS Sans Serif' (+ other bitmap fonts) don't work on WinNT
Keywords: nsbeta2
Nominating for nsbeta2 because we will be using CSS system fonts in HTML buttons
(in html.css) and Windows sets the default system fonts to MS Sans Serif, which
is a bitmap font that does not work in Mozilla yet. As Pierre mentioned in this
bug report, MS Sans Serif is also used on CNet and ICQ.
Native-looking skins also depend on this capability. It would be a greatly 
appreciated fix.
[nsbeta2+]
Whiteboard: [nsbeta2+]
Blocks: 33312
Blocks: 11285
Adding '4xp' and 'fonts' keywords.

Keywords: 4xp, fonts
Whiteboard: [nsbeta2+] → [nsbeta2+] have fix, review pending
who need to review the code ?
I reviewed it, it looks good and works
Whiteboard: [nsbeta2+] have fix, review pending → [nsbeta2+] fix reviewed, waiting for open tree
Blocks: 44806
Erik, classic skin is ready to use this whenever you check in the fix.
Checked in the fix.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+] fix reviewed, waiting for open tree → [nsbeta2+] fix checked in
John,

This appears to be fixed in the July 17th build under Win 98. Could you please
verify bug in the latest build too.
Verified as fixed in 2000-07-19-10 Win32 build.
Status: RESOLVED → VERIFIED
Does not work in Build 2000072408
Windows NT 4.0 Workstation
Installed fonts: 
TT "Symbol", Raster "Symbol 8,10,12,14...", TT "Symbol Proportional"
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
What do you see that is not working? What was your expectation?
I cannot see anything wrong with the current version. We do use "MS San Serif" 
font from the 1st test cases if it installed in the system. We do not use the 
glyph from Symbol to rendert ASCII or other non Symbol characters, but that is 
the right thing. Mark this bug FIXED again.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Mark Carson: for more info about the Symbol font, see bug 33258 and bug 31538.
Marking fixed in the July 26th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: