Closed Bug 48661 Opened 22 years ago Closed 2 years ago

ATM/Postscript fonts will not display


(Core :: Layout: Text and Fonts, defect, P3)

Windows 98





(Reporter: mredding, Assigned: jshin1987)




(Keywords: helpwanted)


(4 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (Win98; I)
BuildID:    2000080712

In my css, I specified a moderately long list of possible fonts but noticed that 
the browser was displaying Verdana - the last choice before defaulting to 
sans-serif - every time. I did a little experimenting and discovered that NONE 
of the postscript fonts on my system (via ATM Deluxe 4.0) would display, not 
even using the font face tag.

Reproducible: Always
Steps to Reproduce:
1. The browser simply won't use any postscript font specified in the CSS (or via 
font face tag, actually). 
2. You'll need ATM running, and a distinctive postscript font such as Friz 
Quadrata active on your viewing system.
3. Adjust the css so that whatever postscript font you have available is 
specified as a choice above Verdana
4. Watch it not display ;)
5. If you remove Verdana and sans-serif, it defaults to (truetype) Times New 

Actual Results:  The headings of my page were displayed in oddly large/bold 
Verdana, instead of Benguiat Gothic. Note that the original page and CSS were 
totally certified on the W3C website, and display correctly in Netscape 4.x/IE 
5.x  I have reproduced a minimal example at the url given above for you.	

Expected Results:
QA Contact: petersen → lorca
massive update for QA contact.
cc-ing some likely developers.  I don't know who owns the windows font matching
code. assigning to erik as a guess.

Still needs confirmation.  I don't have ATM.

Marking Future.  Not critical for NS6 RTM.
Assignee: clayton → erik
Component: HTML Element → Layout
Target Milestone: --- → Future
Ever confirmed: true
yokoyama and nhotta-
Do you have experiene with PostScript font? Do we need to use different value 
in the EnumFontXXX procedure to check 
add helpwanted keyword
Keywords: helpwanted
I thougth we have to use a set of ATM APIs in order to recognize the PS fonts 
in the system.  I am not quit familiar with ATM version of EnumFontXXX.
[sending this from France]

ATM is also a feature that people requested on the mathml newsgroup, and 
was again raised to me at the MathML Conference 2000.

Here is another interesting reading that I found on the general subject of
automatic font management systems:
In reponse to an earlier comment: no, you do not need to call the ATM backdoor 
APIs to access PostScript fonts. The whole point of ATM is to make PostScript 
fonts accessible through the standard Win32 APIs. However, there are some 
limitations and caveats. In particular, on Windows 95/98/ME, PostScript fonts 
show up as device fonts. Also, Win32 uses the TT_ONLY flag literally (i.e. 
PostScript fonts are not considered if TT_ONLY is specified), while the intent 
of the application is often to reject non-scalable fonts.

If you do not have ATM, you can download is for free from, in the 
Plug-ins and updates section. (What you have to pay for is ATM Deluxe, which 
includes font management.)

Hope this helps,, speaking for myself.
Added myself to the cc list, so that I can be aware of further discussions. 
I can guess the following reason may (but not sure) cause mozilla not using ATM 
1. font enum process filter out non  TT font
2. we need to look at CMAP to decide which glyph is contains in the font, ATM 
font may not have CMAP.

The font code erik work for window are mostly on

Maybe a code review first can help to spot the issue. 
Yes, the support of ATM (and other similar automatic font management systems)
would require a shift of philosophy to the present code and a redesign effort.
The informative link is instructive in
this respect. As this shift is much involved, I would suggest connecting it
with the re-work due in bug 45737.
We had a look at the code referenced in the previous entries, and here is what 
we understand.

In the FillLogFont method, line 306, the lfOutPrecision field is set to 
OUT_TT_PRECIS. We wish that this meant "scalable fonts only" (which is 
probably what was intended here), but it really means "True Type fonts only". 
This is why you don't get Type1 fonts. 

You can go around that like this:

- Call the ATM backdoor function ATMSelectObject with ATM_SELECT in the options 
argument. If this succeeds, there is a Type1 font like the one you 
want, just proceed with that font.
- Otherwise, call SelectObject as currently, you will get a TT font.

Note that ATM also has a backdoor to enumerate fonts; this will probably be 
needed to construct the font menus.

The other thing we noticed is the use of the GetFontData function, to get loca, 
cmap, name, and head tables. You probably know that Type1 fonts do not contain 
such things, and that in fact ATM does not even attempt to synthesize them 
(i.e. GetFontData is not supported for Type1 fonts). OpenType fonts can contain 
those tables; however, if an OpenType font is exposed by ATM (i.e. it contains 
Type1 outlines in a CFF table) then GetFontData will still fail. The good news 
is that we suspect that GetFontData is used only in rare cases (MathML?).
Thanks for the info.

I have some bad news, though: The cmap table is critical for Mozilla, since we
implement CSS, which has a property like this:

  font-family: Arial, "MS Gothic", sans-serif;

The implementation is supposed to go down this list for each character in the
element. If a font doesn't exist, or it doesn't contain a glyph for the current
character, then we're supposed to proceed to the next font. This means that we
need to know exactly which glyphs are present in each font. That's why we call
GetFontData(cmap) on TrueType fonts, and we have a hack for Windows raster
fonts. Can you think of a hack (or even a clean method) for PostScript fonts?
I'd like to clarify a few things about automatic font management.

Consider a graphic designer, with a library of a few thousand fonts at his 
disposal. If he does not use some form of font management, he will end up with 
all those fonts in the font folder, with a fair amount of system memory devoted 
to those fonts, and with huge font menus. This is not very nice, especially 
since he needs only a few of those fonts at any given point in time.

What you really want is two lists of fonts. One is the list of all fonts that 
could possibly be used, the other is the subset you need right now. The subset 
is what you want Windows GDI to know about, i.e. you want the EnumFont APIs to 
return just that set. By construction, Win32 will not know anything about the 
other set. So you cannot ask Win32 to tell you what's in it. You have basically 
two choices: 
 - you have other APIs to query the set of available fonts
  (ATMFontAvailable is an example)
 - you automagically add fonts to the Win32 set whenever an application asks 
   for a font that is not already there, and you query the Win32 set.
Adding a font to the Win32 set is not a free operation. Furthermore, if you 
don't have extra APIs, you have to add *all* the available fonts to be able to 
get a list of them, not a good thing.

That being said, it is important to understand that the problem at hand at 
nothing to do with automatic font management. The Type1 font is in the Win32 
set, it's just that a SelectObject with a logfont that says OUT_TT_PRECIS will 
never select a Type1 font. It does not matter how the font got in the Win32 set 
(via ATM or via FontSentry or via anybody else).

Another thing to know: there are two ATM products:
- ATM Light, which augments Windows (or MacOS) with support for Type1 fonts
- ATM Deluxe, which does font management

ATM Light is available for free from

Change summary to add ATM in front.
Summary: Postscript fonts will not display → ATM/Postscript fonts will not display
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
erik resign. reassign all his bug to ftang for now.
Assignee: erik → ftang
mark all future new as assigned after move from erik to ftang
As of December 22 2001, Mozilla 0.9.7 still cannot display ATM Postscript fonts
correctly, at least under Windows 98.


It's a side-by-side screenshot comparing Mozilla 0.9.7 and Netscape Navigator 4.08.
Any answer to comment #12? Apparently, the fundamental notion of font ordering
in CSS can be broken easily with ATM.
As my screen capture evidences, this is also a problem with Type 1 fonts on
Windows 2000 even using the latest builds of Mozilla (2002012903). Note that W2K
natively handles Type 1 fonts (no need for ATM). 

The screen capture above shows how a Helvetica Type 1 font is rendered by MS IE
but not by Mozilla. I don't have XP but would expect similar behavior.

In answer to #21: yes, Win2K (and XP as well) have native support for Type1 and 
OpenType/CFF fonts, but it's worth noting that this was done by integrating ATM 
in those OSes, almost the same code as the independent ATM 4.1 for NT 4.0.

In answer to #12: So the problem is to figure if a font contains a glyph for a 
given character. You achieve this for TrueType fonts by inspecting the cmap. 
Type1 fonts have no notion of cmap, as least not as directly as OpenType (TT or 
CFF). But one can be created as follows:

- fonts with a well-known encoding (e.g. StandardEncoding): the "character 
codes" (as defined in the PostScript world) form a well-known encoded character 
collection, and you can use a mapping to/from Unicode for those collections.

- fonts with do not use a well-known encoding: the character that is 
represented by a glyph is deduced from the glyph name. 
<> describes how to 
do that.

I think this is essentially what ATM does anyway (it must provide the 
equivalent of a cmap, called a GlyphSet I believe, to GDI). The downside of 
this approach is that you may have difficulties matching exactly the ATM code, 
and thus have unexpected behaviors.

This suggests another path if you know the set of characters you are interested 
in (by opposition to getting the full cmap). Call DrawText with a string made 
of that set of characters, in the mode where it returns the glyphIDs; then 
check which character result in glyphID 0 (notdef). This has the advantage that 
you will actually use ATM's mapping, and therefore be in sync by construction. 
It's also a method that will work regardless of the font technology.

On my system, Mozilla 0.9.9 still cannot display ATM fonts on Win 98. Hope to
see this fixed before 1.0...

(Windows 2000's native Type 1 support DOES work.)
On my system, Mozilla 1.0rc1 _STILL_ cannot display ATM fonts on Win 98.
This is on build 2002041711. Will this be fixed in 1.0 final?

On my system, Mozilla 1.0rc3 _STILL_ cannot display ATM fonts on Win 98.
This is on build 20020523. Will this be fixed in 1.0 final?

On RC3, the font "VAG Rounded Th" displays as Arial.
On my system, Mozilla 1.1 _STILL_ cannot display ATM fonts on Win 98.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826.
QA Contact: gerardok → madhur
Component: Layout → Layout: Fonts and Text
what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.
Closed: 17 years ago
Resolution: --- → WONTFIX
Mass Reassign Please excuse the spam
Assignee: ftang → nobody
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him
Resolution: WONTFIX → ---
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Firefox 1.0 displays Postscript fonts. I am on Win XP Pro SP2, with ATM 4.x. 

I don't have an older OS available, but I do still use ATM. I just viewed the 
original personal web page that I discovered the problem in; for what I had 
active on my system, it was displaying the correct font. Then I activated a 
font specified higher in the order of the CSS and hit reload. The browser 
displayed the page correctly with the different font.

Other pages I've done for work that use various postscript fonts have all been 
displaying correctly for a while, actually. Barring a subtle concern I'm 
unaware of, you can mark this one closed.
QA Contact: madhur → layout.fonts-and-text
I wonder if the problem I am having in Firefox 4 Betas 7 through 9 is related to this old issue. I wasn’t a Firefox user in the early days so I cannot compare; however, I know versions 2 and 3 have no problem (Firefox 2 had some ligature and quotation-mark issues). Attachments follow.

Both the Firefox and Windows versions here are long since obsolete, but from comment 31 it sounds like this got fixed somewhere along the way. Closing as WFM.

Closed: 17 years ago2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.