Closed Bug 48661 Opened 20 years ago Closed 4 months ago
ATM/Postscript fonts will not display
71.77 KB, image/gif
346.89 KB, image/png
196.29 KB, image/png
621.44 KB, image/png
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 Roman 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:
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
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
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.
link to adobe technotes http://partners.adobe.com/asn/developer/technotes.html#atm
[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: http://www.qualitype.com/api-info.htm
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 www.adobe.com, in the Plug-ins and updates section. (What you have to pay for is ATM Deluxe, which includes font management.) Hope this helps, email@example.com, 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 fonts- 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 http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsFontMetricsWin.cpp 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 http://www.qualitype.com/api-info.htm 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 www.adobe.com.
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
Status: ASSIGNED → NEW
mark all future new as assigned after move from erik to ftang
Status: NEW → ASSIGNED
As of December 22 2001, Mozilla 0.9.7 still cannot display ATM Postscript fonts correctly, at least under Windows 98. See http://javajack.dynup.net/moz/mozfontbug.jpg 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. Mike
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. <http://partners.adobe.com/asn/developer/type/unicodegn.html> 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. Eric.
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 15 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
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
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.
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.
Status: NEW → RESOLVED
Closed: 15 years ago → 4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.