🚀 go-pugleaf

Rockin' and congrats...

Probably both nVidia and Dell. Also, it's kind of funny that the "Partner Certified" drivers didn't work, but as I recall any fonts that were already installed were working in my apps and I didn't notice a problem until I went to try to add additional fonts, so it is possible the "certification" process missed the step of adding a Type 1 font (or since our Type 1's are destined to be replaced with the new open type fonts, Type 1 confirmation wasn't part of the process at all). I think all 4 vendors involved (including MS) should have some interest in making this work and Win 2k3 SP2 did include a new version of atmfd.dll and atmlib.dll from Adobe, so somebody, somewhere is still in this code.

I can't say this is the strangest video issue I've ever seen, but it is definitely up there. Since the failure blames the font, the code must be assuming any error at all while adding the font is related to the font files. When I was troubleshooting this and looking through some of the dev docs I did notice the GDI.exe is tied to the font activation process (a very old font related hot fix in Win2k included atmfd.dll, atmlib.dll and dern near all of the GDI components), and that is what first kick started my brain back to the basic TS step of checking for a video conflict. So much for the Hardware Abstraction Layer I suppose. I'm sure things would be worse without it (think Win 3.1), but I do wish it was little more robust in its defense against driver related weirdnesses.