Closed Bug 58104 Opened 24 years ago Closed 23 years ago

ATM font smoothing of PostScript fonts makes windows open up blank, empty

Categories

(Core :: Layout, defect, P2)

PowerPC
Mac System 9.x
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: avi, Assigned: sfraser_bugs)

References

Details

Attachments

(1 file)

No description provided.
Aargh. I hate IE.... Yeah, I'm using IE, since this bug makes Mozilla useless to me. This is probably going to be the worst bug report I've ever written, probably so bad that I'd throw it out if it were addressed to me. But _please_ tell me that I'm not going insane. I have the latest build of Moz--"Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/ 20001026" that I just downloaded from the FTP server. Open a window. Notice that things work--you can control-click to get contextual menus, select About and get an about window, etc. Now go do any browsing. I'm reproducing this by just loading http://www.apple.com/ once. Then try do to stuff. Click the "Tabs" popup in the sidebar--get a blank box instead of a menu. Control-click to get a contextual menu. Blank box. Open a new window. Blank box. Preferences are trashed, registry files deleted. No help. This is 100% reproducible for me on my Yikes G4/350. Surely someone else is seeing this?
One last note for now. It's apparently just a drawing problem. If you try to click an item in the empty window, such as selecting where "Back" would be on the contextual menu, or clicking where the OK button would be in the preferences dialog, or tapping the return key when a blank dialog appears, the correct action takes place.
>Preferences are trashed, registry files deleted. Eeek. I meant to say that _I_ erased those files to see if they were somehow corrupted. Not Mozilla.
Asa, can you confirm or deny this? Thanks, /be
Assignee: waterson → asa
I've seen nothing like this with today's mozilla trunk Mac build 102608.
Hmmm. Whittling the extension collection down to "Mac OS 9.0 Base" in CC makes things work. Let me try to nail who's responsible, and then we can see if it's their bug or Mozilla's...
CC sez... ATM and Helvetica... :-( It looks like a bogus font. I don't get why Mozilla cares, but it's not its fault. Sorry for the panic.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
I'm sorry for piling so much onto this, but this is getting weirder and weirder for me. I've verified this on a different machine. The item in question is a Helvetica font. Not the TrueType one that comes with the Mac OS, but the Adobe Postscript one. When you have it installed, windows come up blank in Mozilla. I initially dismissed it as font corruption, but no other application has a problem, nor does either ATM or InDesign have problems rendering it. Can anyone else reproduce this? You can get a hold of the font by installing Acrobat Reader 3 (4 no longer installs Helvetica, just Arial [yuck!]). If not, let me know and I'll get you a copy. Something weird must be happening in Mozilla...
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
adding sfraser@netscape.com and pinkerton@netscape.com. Do you all think this could be related to the problems seen in bugs like bug 42289 or bug 32327.
Asa, in re to your comment about this being like bug 42289, I went into the ATM control panel and turned off font smoothing ("Smooth Font Edges on Screen"). And windows start working again. This causes two questions: One, why does having Helvetica trigger the problem while no other font causes a similar problem? And two, what the heck is ATM doing?
This sounds like the / in folder path bug.
Ignore my last comment. This sounds like we have an incompatibility with ATM. cc the font rendering folks. I recall an earlier bug that described an incompatibility with SmoothType, but I can't find it now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
someone else should own this. I'm only good for testing, not fixing. :)
--> rendering
Assignee: asa → dcone
Simon, re the SmoothType incompatibility, that's the bug 42289. But this makes me think. Now we know of two different CPs that smooth fonts and make Mozilla freak. Now, Greg fixed SmoothType, but did he fix a bug in ST, or did he install a workaround?
(Sorry about the attachment. It was meant for Bug#51920)
You know more about this than I do..
Assignee: dcone → sfraser
updated summary
Summary: Windows open up blank, empty → ATM font smoothing makes windows open up blank, empty
This may be the bug reported by Bill Connell on 11/15/2000 at http://www.macintouch.com/netscape6.html: The font was displaying too large for my taste, but when trying to change that, i found the Big Problem(tm). The Big Problem is that if i opened ANY window other than the main browser window - a 2nd browser window, the preferences window, the IM setup window, theme window - it would display as completely empty (white). It acted like there was content there, because the cursor would change over text boxes, and i could hit the default (presumably OK) to dismiss the window, but i couldn't see anything of what was there. And, of course, i couldn't change any preferences or even see what was available.
Keywords: nsmac2
I have reported this kind of bug maybe a year ago, but wasn't able to attribute it to Adobe Type Manager. Now, however, that I installed Netscape 6, I found that the blank-new-window problem was still not resolved. Disabling "FontSmoothing" in Adobe Type Manager (I tested this issue with 4.5 Deluxe, 4.6 Deluxe, and 4.6.1 Light on Mac OS 9.0.4) resolves the problem, but that renders operating mainly with PostScript fonts useless as they don't draw well. Many Adobe applications install ATM Light by default, so I imagine others are experiencing this bug as well. This does not happen in any other application to my knowledge. I know that this is not the place to submit Netscape 6 bugs, but I checked if this is an issue with the latest Mozilla build (in which this problem has always caused me to remove it from my hard drive as it rendered the browser useless) from November 22, 2000 (Build ID: 2000112208). The issue exists in the same way (in regards to my experience) in Mozilla as in Netscape 6 Final. New windows, inlcluding preference windows and dialog boxes, pop up lists, and other new Mozilla-initiated GUI elements do not show any content--they are blank--while the rest of the system work fine. I checked my fonts for corrupt resources as well as done the usual system trouble-shooting without any success. Also, I tried ATM Light 4.6.1 on a clean install of Mac OS 9.0.4 (OS 9 + the Mac OS 9 Update + all other available Apple updates). The problem occured under those conditions also.
suggesting a fix milestone.
Keywords: mozilla0.9
Status: NEW → ASSIGNED
Keywords: mozilla0.9
Target Milestone: --- → mozilla0.9
*** Bug 63067 has been marked as a duplicate of this bug. ***
Good description of this bug in duplicate bug 63067.
setting nsbeta1 keyword for 6.5
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
Move to layout, QA to Chris Petersen. I can't repro this using the free ATM light download, and setting my browsing fonts to some free PostScript fonts that I downloaded. Everything works fine. I'm on Mac OS 9.1.
Component: XP Miscellany → Layout
QA Contact: brendan → petersen
Ooops, just spoke too soon. I do see blank windows. Not the first or second, but after I brought up a dialog. Next time I ran, the second browser window was blank. This is bad.
Priority: P3 → P2
Ok, I see this problem too. Downloaded ATM light and specfied a postscript font as default. Second window is completely blank. Tested on Mac 2001011208 build under OS 9.0.4.
If I turn off double buffering in the view manager, this problem does not occur. So it seems that ATM is messing with our offscreen to onscreen CopyBits.
That's rather curious. Although ATM patches out a whole bunch of traps, CopyBits isn't one of them: ~ATM™ A8F6 0106C210 PowerPC PowerPC DrawPicture A901 0106DD10 PowerPC PowerPC FMSwapFont A902 0107B6A0 PowerPC PowerPC RealFont A882 0107B6D0 PowerPC PowerPC StdText A8EB 0107B740 PowerPC PowerPC StdBits A8FD 010DF596 680x0 680x0 PrGlue A001 00F179D0 680x0 PowerPC Close A9DC 00F1C4E0 680x0 PowerPC TEKey A9D6 00F1C520 680x0 PowerPC TECut A9DB 00F5CC90 680x0 PowerPC TEPaste A9D7 01002B00 680x0 PowerPC TEDelete A9DE 01002B30 680x0 PowerPC TEInsert A83D 010DF7CC 680x0 680x0 TEDispatch A902 010D89C0 PowerPC PPC&68K RealFont A900 010D8A10 PowerPC PPC&68K GetFNum A9A1 010D8A60 PPC&68K PPC&68K GetNamedResource A820 010D8AB0 PPC&68K PPC&68K Get1NamedResource A9A0 010D8B10 PPC&68K PPC&68K GetResource A81F 010D8B60 PPC&68K PPC&68K Get1Resource A99D 010D8BB0 PPC&68K PPC&68K GetIndResource A80E 010D8C00 PPC&68K PPC&68K Get1IndResource A8FF 010D8C50 PowerPC PPC&68K GetFName A996 010D8CA0 PowerPC PPC&68K RsrcZoneInit A99A 010D8CF0 PowerPC PPC&68K CloseResFile A9AB 010D8D40 PowerPC PPC&68K AddResource A9AD 010D8D90 PowerPC PPC&68K RemoveResource A81A 010DCBC0 680x0 PPC&68K HOpenResFile A997 010DCC10 PPC&68K PPC&68K OpenResFile A00C 010DCC60 PPC&68K PPC&68K GetFileInfo A99C 010DCCB0 PowerPC PPC&68K CountResources A20A 010DCD10 680x0 PPC&68K OpenRF A9A2 010DCD70 PPC&68K PPC&68K LoadResource A260 010DCDC0 680x0 PPC&68K Unknown Trap A9A3 010DCE10 PowerPC PPC&68K ReleaseResource A9A8 010DCE60 PPC&68K PPC&68K GetResInfo AB1D 0046EB2C 680x0 PPCDisp QDExtensions * AB1D 012C8BD6 PPCDisp 680x0 QDExtensions Simon, you've got this happening to you. Those CopyBits calls that are failing look completely normal?
I haven't debugged far enough to say that the CopyBits is failing somehow. Perhaps drawing into the offscreen GWorld is failing (though why drawing of lines etc would also be affected by ATM I don't know). Why, also, does the first window work OK? Thought: maybe ATM gets confused when there are two windows sharing the same offscreen buffer? (since, I think, we share the same GWorld for offscreen drawing between all windows). So does the bug only occur when you have > 1 window open?
Any takers for this bug?
To steve
Assignee: sfraser → sdagley
Status: ASSIGNED → NEW
I just guess StdBits is the primitive trap to CopyBits, so ATM patches CopyBits in some way. Anyway, while I was browsing the latest display bugs on the Mac, it seems that GrafPort management is quite bad generally, and CopyBits is a complex routine so can be especially picky about having a valid GrafPort or GWorld.
what do you mean by "GrafPort management is quite bad generally?"
He means that we're sloppy with our GetPort/SetPorts, evidenced by the fact that we draw over the windows of other apps sometimes. (I was seeing the progress bar draw through Finder windows consistently last night at home).
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Off to 0.9.3.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
This bug recieved note on MacFixIt.com on June 14th, relating to Netscape 6.1p1 although the user did not know why all his windows were opening up empty. I believe this is a major issue that is keeping Mac users from using Mozilla, since many Mac users use ATM.
I agree. I'm a Mozilla fan, and it's one of my targets for Web development, in the hope that it'll soon be robust enough that I can recommend it. One of the puzzling gotchas that has kept me from making such a recommendation was the fact that I kept getting these blank windows on my wife's Mac. Well, now I know what the problem is and what to do about it, but I imagine that most Mac ATM users will stick with some other browser if they're told they have to disable font smoothing in order to use Mozilla. Simon Fraser mentioned that this problem does not occur if double buffering is turned off. Is there a way to do this without rebuilding?
Depends on: 12985
Abobe released ATM Light for Mac OS 4.6.2 last week. They haven't updated this program for months and months, so I thought maybe they'd be addressing this problem from their end. Alas... No. There is no change with the latest ATM Light. I tested it with yesterday's trunk build running Mac OS 9.1. I really think the incompatibility of ATM Light font smoothing and Mozilla should be noted in the release notes, particularly in new 0.9.2 notes posted yesterday. This bug caused me a lot of consternation like it did for the original poster.
Can we nsBranch this puppy?
Severity: major → critical
Keywords: nsBranch
Whiteboard: [nsbeta1+]
There's another solution. WebFree, the venerable anti-advertising program for Macs, also interferes with the Mozilla browser. If you're running WebFree, disable it and the browser will work fine. Of course, that means more ads.... Bob
Also, something I noticed while trying to see if there's a workaround... If you have font smoothing off when you start Mozilla, Moz works fine. (Expected) If you have font smoothing on, when you start Moz, no chrome in new windows. (Not expected, but the focus of this bug.) If you start with font smoothing off, but later turn it on and back off (even if you aren't using Moz at the moment. it just has to be running) no chrome again. The same behavior as if you start with font smoothing on and turn it off later. Is it just me who sees this? I'm using ATM Light 4.6 (Deluxe conflicts with other software installed) with MacOS 9.04 and 192MB RAM on a G4 Cube 450. This occurs with VM on or off. I'm currently using build 2001071008. I don't think there's much else I can include to identify the problem... Unfortunately, the only boxen I have with MacsBug are too old to run Mozilla, and I've been forbidden from installing it on here. ;) *WHAT* is ATM doing to the system to cause this? And do we chalk this up as a Mozilla or an ATM bug? Or is it still too early to tell? Also, did the Helvetica though branch out into something useful? I don't currently have Suitcase loading Helvetica, so it'd be interesting if it's something general with certain fonts... All I know is that I'd love to have this fixed. It's really annoying to have to keep opening and closing ATM in order to use Mozilla. So, I end up in IE far too often.
Matt, there was a mention this morning on MacFixIt that Adobe Type Reunion may be causing some of the problems ATM is being blamed for. Could you check and see if the workaround suggested in the article has any effect on your system?
It's definitely not ATR's fault since I have neither it nor ATM Deluxe installed. (They conflict with Suitcase among other things installed.) If I run into anything more substantial than "I see it too, and this doesn't help", I'll be sure to let everyone know. I'm still trying to get MacsBug onto this machine, but it looks like I'm fighting a losing battle. "At least we'll know why IE crashes" doesn't seem to be a good enough reason... ;)
OK. I now have some fairly credible evidence that ATM has a hand in this... While quitting, I got a type 3 error. This left me with a slightly screwed up display. (I couldn't quite place it at the time... Sorry...) I was going to turn on font smoothing again and reboot since *something* didn't look right. I had left the ATM control panel open while surfing, since I forgot to close it after turning off font smoothing, which is my habit. So, I turn font smoothing back on. Boom. ATM crashes. Click OK and the screen goes everywhere except the menu bar and the App Switcher palette. Is this a starting point in tracking it down? Right about now I wish my girlfriend wasn't so afraid of MacsBug. BTW, it's even odder if you cause the ATM control panel to crash with a Mozilla window taking up the screen... Just did that accidentally... I now wish I could give this bug a few more votes... :/
Matt, thanks for the additional feedback. I've tracked down the name of an engineer at Adobe familiar with ATM and I'm hoping he'll have some ideas on the problem. Can I contact you directly if we need a guinea pig? Please send me e- mail with contact info if that'd be ok.
sdagley, I emailed you on the 12th saying I'm willing, never got around to putting it into the bug. If you need to contact me, just use the email address I submit with. Any luck in recent builds? I have Macsbug on here now... :)
Are you people aware; at least on Mac Platform that Font smoothing can be turned on in Appearance Manager Since OS 8.5. So some ATM Technology is built in to the system. Also, Its seems that ATM and Font smoothing has been around longer than Mozilla/N6. What Font smoothing is, is a form of antialiasing. So the problem is rooted in Mozilla/N6 because, ATM predates Mozilla/N6
At least under MacOS 9.0.4, which is the version I'm using, font smoothing in the AM is far inferior than ATM's. For example, set your font in NotePad to a Postscript font at say, 18 point with ATM's font smoothing on. Now turn it off in ATM and use the Appearance Manager's. Notice all the jaggies? Imagine that on a system like the one I'm on where about 80% of the fonts are PostScript fonts... If there ends up just being a release note saying "Please turn off ATM's font smoothing before running Mozilla", you'll lose the market segment that the Macintosh is known for: The artists. And just because a program has been out a number of years does not mean that it is bug-free. (Look at Microsoft Windows or the Linux Kernel. Or even the Mac OS itself. Just convenient things that have been out a while...) It may just be a bug that rarely exhibits itself. For all we know, it may be a bug that has made countless programmers feel inferior with their coding, not knowing that they were doing things fine... But yes, it may be a Mozilla bug. But it also could be ATM's fault. It's too early to tell for sure, but they definitely don't co-exist well at the moment.
the problem is i use the OS font smoothing on a daily basis with no problems. something else is amiss.
Here are my comments for bug 58104. I haven't registered yet unto bugzilla because I'm tracking only one bug in the system since a long time back: bug 58104. Please note that this is the only bug that will keep me out of Mozilla (Netscape 6) until it is resolved. The real issue here are "antialiased PostScript fonts". Mozilla will dispay "no chrome in new windows" each time that there are antialiased PostScript fonts in use in a web page. The only way to antialias a PostScript font is to use ATM Light or Deluxe AND turn on antialiasing. Apple Appearance Manager will antialias ONLY TrueType fonts. NOW, WHY THIS BEHAVIOR DOES NOT SHOW ON ALL SYSTEMS The base font for NetscapeCommunicator 4.x and Mozilla is Helvetica (and sometimes Times). In the past Helvetica and Times were always shipping in PostScript in the MacOS. But now these same fonts are now shipped in TrueType format. BREAKS So if a user have replaced all the TrueType fonts with their PostScript conterpart, Mozilla will break in trying to display these antialias fonts (by ATM). Typically those user are working in the graphic industry where it's usual for them to delete the TruType versions of the fonts to use only the PostScript ones. USUALLY the PostScript version of Helvetica is used here. NO PROBLEM A user that does not have PostScript fonts installed won't need ATM. Eventough, if he have ATM, it won't be enabled because it will work only with PostScript fonts. Those users typically use the Appearence Manager to turn on antialiasing on TrueType fonts showing no problem at all with Mozilla. USUALLY the TrueType version of Helvetica is used here. CONCLUSION This issue is related to Antialiased PostScript fonts (by ATM) showing "no chrome in new [Mozilla] windows". ATM smoothing a PostScript font : "no chrome in new windows" Appearance Manager smoothing a TrueType font : "no problem at all" ATM is installed but only TrueType fonts are smoothed by the Appearance Manager : no problem at all" ATM is installed by the user changes the Mozilla pref to use a TrueType fonts for defaults fonts : "no problem at all", until a web page ask for a specific font name that is PostScript, hence : "no chrome in new windows". Early build of very old milestones did not have problems with ATM smoothing a PostScript font. Since I do not tests builds regularly, I wasn't able to track down when this bad behavior showed up. This bug does affect a lot of Macintosh users, a lot of them already using IE on a daily basis. I'd be willing to test out new Mozilla builds anytime.
an awesome analysis! thank you so much for tracking this down. now that we know the problem, we can set about fixing it.
Summary: ATM font smoothing makes windows open up blank, empty → ATM font smoothing of PostScript fonts makes windows open up blank, empty
jrblier's summary of the bug is excellent and matches my observations perfectly. However, one small point needs clarification. Wherever it says "windows open up blank" this should be taken to mean "any new rectangle containing text". This includes new browser windows, pref dialogs, select box dropdowns, contextual menus, tooltips in the button bar, and title tags on images. Anything that was not already open will now be blank. Conversely, the original browser window continues to display correctly, including the antialiased postscript that caused the problem!
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Blocks: 93858
*** Bug 93858 has been marked as a duplicate of this bug. ***
No longer blocks: 93858
hmm... Is it just me or has this bug practically disappeared? I don't remember changing anything locally, but I cannot reproduce this bug anymore. As I said before, this is a major show-stopping bug for a significant portion of the Mac audience. If it has resolved somehow, that would be GREAT. Anyone check anything in RE: this bug? I didn't see anything. I also don't know precisely when it was fixed. I stopped downloading nightlies till about a week ago due to this bug making Moz useless to me. Now it's gone and I'm happy. Anyone still see it?
Nothing specifically got fixed here.
Following the comments from Matt Lewandowsky (_Lewellyn) 2001-08-20 19:29, I tried the latest Mozilla build (2001-08-22). Unfortunatly, the problem is still present. See my comments and those made by Frankie 2001-07-18 07:01. - Jacques
Keywords: nsBranchnsbranch
Ahh.... So I see... I guess I had changed my browser fonts to TrueType to work around this and had forgotten that I had done so. I was wondering why things didn't look "quite right" in regards to fonts... That's just what happens when you don't use a piece of software for a while. Guess I'll either stick with TrueType or IE for now. Neither option is particularly appealing, but... Also, I haven't heard back from sdagley in response to my email to his note on 7-12-2001. It would be nice to put this to rest.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Per comments from sdagley, Pierre would be a better owner for this. Pierre?
Assignee: sdagley → pierre
how far away might we be from a fix?
We are a long way from a fix. No-one has investigated this bug.
This bug is fixed by the "minimal Gfx patch" in bug 100700.
Assignee: pierre → sfraser
Please, create us a custom build for the MacOS 9 with the attachment provided in bug 100700. I will be able to test this customized build as soon as I can get my hand on it. In the event that the patch corrects the bug, I will be able to test out any nightly build incorporating the patch. Thanks, - Jacques R. Blier
No longer depends on: 12985
Blocks: 12985
simon, if bug 100700 would fix this, should we nsbranch- this one ?
Status: NEW → ASSIGNED
nsbranch- ing.
Keywords: nsbranchnsbranch-
Fixed by the fix for bug 100700 on trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
Please, change the status for this bug to Verified. I've tested it with 2001101117 Macintosh Build. Now I will be able to use more often the Macintosh version and file bugs. Thanks for the great work.
Marking verified in the Oct 20 OS X and OS 9 branch 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: