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)

Product:
Core
Component:
Layout
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: avi, Assigned: sfraser_bugs)

References

Details

Attachments

(1 file)

Problems with font metrics with TrueType fonts
125.22 KB, image/png
Details 
      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: nsBranch → nsbranch
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: nsbranch → nsbranch-
Fixed by the fix for bug 100700 on trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 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: