Reliably Changing Versions of Fonts »

For people who design fonts, swapping versions of your font can be a problem, as your operating system or apps have font caches which may become confused when you replace your fonts on the fly. The app you are using a font in may sometimes still display/​use the old version, even though you replaced it! So for people who need to be absolutely sure they are getting the new version, here are some options. Note that latest versions of Adobe CC apps may recognize fonts swapped on the fly. Office 360 as well, at least on Windows. So if you are not having trouble, and you are swapping fonts some other way, good for you! But if you are having trouble, here are some more options.

Here are some approaches for reliably swapping versions of fonts that have the same internal names, to new versions. This applies to both Mac and Windows, and across all apps as well. When working this way, as best as I recall, in the past 10–15 years, I have only hit font caching problems once! I suspect that was just a failure to apply my method religiously enough. There are two options for fonts with the same internal names on the desktop, plus to avoid the problem entirely, there is an approach to making font names unique, and some links to web-​based test sites.

Option 1: Brute force (cross-​platform)

1. Close apps that you are using the fonts in, particularly those which cache your fonts, including Adobe CC apps and Microsoft Office.
2. Then, uninstall the “old” font version from your OS. Don’t just overwrite it in place with the new version! (If you are using a font management app, you can just deactivate, but I usually nuke them anyway, I don’t need 170 versions of the same font kicking around.)
3. Relaunch those darn font-​caching apps, including Adobe CC apps and Microsoft Office. That’s after you uninstall the font. Even open a doc that uses the now-​missing font! This gives the app and its cache a chance to recognize the font is no longer there and update appropriately.
4. Quit Office apps (without saving your docs, no need). Note: no need to quit Adobe CC apps, they can recognize newly-​installed fonts on the fly.
5. Install your new font versions; or activate them in your font manager.
6. If you are using Office apps with your fonts, you can launch them apps again and work normally.

Option 2: FontNuke (Mac only)

I forgot about this option for a while, but was reminded of it by James Montalbano in a thread on TypeDrawers. FontNuke is a Mac utility that clears font caches, and then reboots your system. It’s available through major utility aggregators like MacUpdate and CNet. I’ve used it occasionally, and it works fabulously. Downside: it requires a system restart. That’s why I ended up tending to go with Option 1. (Also, Mac restarts used to take longer than they do nowadays. Yay for SSDs!) Upside: if your system font caches have gotten messed up, or you don’t want to go through all the steps above, it becomes the simplest solution.

• Download from MacUpdate
• Download from CNet
• Read FontNuke intro or read the FAQ

Option 3: Font Naming Tricks (cross-​platform)

Option 1 seem like too much freakin’ work? Or you need something that works on Windows, or reboots suck? I hear you. That’s why as a font designer, I sometimes work with a system where instead of keeping the internal names the same, I actually put the build version number right at the end of the gosh-​darned family name, so it shows in the menu with the version number. I also put it on the end of the file name. I leave it this way as long as possible during development. Sure, this has its limitations, as the new font won’t just automatically substitute for the old one in existing documents. And it has to be changed before releasing the font. But if I am in the midst of frequent font revisions, it also means I can swap out font versions constantly, as often as I like, and not worry in the least about my apps or OS getting confused. That is pretty sweet.

1. Before generating the actual TTF or OTF font, increment a build number at the end of the font family name
2. Remember that your existing docs won’t recognize this as being the same font family.  🙁  But you don’t have to worry about caching and conflicts! 🙂

Option 4: Test in the browser instead

If you don’t have to test in a desktop app, you can avoid a lot of grief! There are sites for testing fonts in a web browser. You can drag the font into a browser window and test it there. Impallari’s is great

• Pablo Impallari’s tester, as hosted by Cyreal
• Font Dragr
• Type Zebra
• WebFont|Test

If you are doing browser-​based font testing—or font testing anywhere, really—with an incomplete character set, consider Miguel Sousa’s Adhesion Text to get useful words for test purposes. (Don’t miss the options for other languages, and more!) 

Fontmageddon? Windows security patch KB2753842 of Dec 11 (fixed!) »

OpenType /​ PostScript font support killed in many apps (FIXED Dec 20, 2012)

(UPDATED repeatedly, first with more details and then because of the Dec 20 fix.)

Was it Fontmageddon? For users who use fonts in some applications (see below), Windows security update KB2753842 of Dec 11, 2012, caused more harm than good. Luckily MS got it fixed and re-​released it nine days later. The current version of the patch does NOT have the problem, and can be installed over the original release to fix the problem caused by the original.

Kudos to Microsoft for fixing it quickly and including interested outside parties in testing it. I was able to seed Extensis tech support manager Romeo Fahl with the fixed patch, so we participated in helping verify it worked.

WHAT THE BAD PATCH DID

(1) installing the update breaks some very tiny number of fonts at the system level and for all apps, including potentially malicious fonts. That’s what it was supposed to do. BUT ALSO….

(2) with the original version of the update, for certain apps text set in all PostScript Type 1 (.pfb/.pfm) and OpenType CFF (.oft) fonts became invisible. This can even affect font menus when the app has a WYSIWYG font menu.

FIXING THE PROBLEM

Installing the revised version (2.0) of the patch from Microsoft will fix the problem caused by the original release.

If your computer is part of a domain administered centrally by an IT team, you should alert them that the issue is fixed, so they can decide whether to roll it out now that the patch is safer.

 

PROGRAMMER DETAILS

The apps that were especially affected are those that use the GetGlyphOutline() API to grab font outlines of PostScript fonts (both Type 1 pfb/​pfm fonts, and OpenType CFF .otf fonts). With the bad version of the patch, that API no longer returned the memory size needed to get the curves, but instead returned a bogus value of zero. This effectively renders some apps unable to render the glyph on screen. At least, at 15 points and higher.
I gather there are other APIs apps can use, but that GetGlyphOutline() works all the way back to XP, unlike the alternatives.

AFFECTED OS VERSIONS AND SOFTWARE

I strongly suspect that in many more applications than those listed, “convert to curves” functions will fail or result in lost text. I also suspect that in most cases where a current version of an application is affected, so are older versions not listed. What we know is that affected OSes and apps included:

• Windows: All desktop and server versions of Windows from XP to Windows 8, it seems.
• PowerPoint, but only in presentation mode (an especially dangerous failure, as a user might think things were fine… until they tried to do an actual presentation)
• QuarkXPress 7, 8, 9.5 (but only affects fonts at 15 pts and larger)
• CorelDRAW X3 to X6. Workaround: view in “draft” mode works because it does not use the problematic API.
• Serif PagePlus
• Adobe Flash (authoring at least, probably not the running of Flash apps?)
• Flexi and SignLab (signmaking apps)
• Avid Marquee (video titling)
• Bentley MicroStation (CAD /​ information modeling)
• The Secret World (Alternate Reality Game)
• Inkscape (vector drawing)
• Xara Designer Pro X (vector drawing) and possibly other Xara apps

MICROSOFT RESPONSE
The MS Knowledgebase article has a standard section for “known issues.” On Friday Dec 14, 2012, Microsoft updated it to read: “We are aware of issues related to OpenType Font (OTF) rendering in applications such as PowerPoint on affected versions of Windows that occur after this security update is applied. We are currently investigating these issues and will take appropriate action to address the known issues.”
On Thursday, Dec 20, 2012, Microsoft released version 2.0 of the patch that fixes the problems in the original. The “known issues” section now reads: “The original version of security update 2753842 had an issue related to OpenType Font (OTF) rendering in applications such as PowerPoint on affected versions of Windows. This issue was resolved in the version of this security update that was rereleased on December 20, 2012.”

Web Typography Best Practices webcast series »

Through my day job I am doing a 3-​part webcast series on web typgraphy best practices. It is free, and registering once covers all three webcasts (with no obligation to attend).

• Part 1: Selecting Fonts. Wed Sep 7, 11 am PST
• Part 2: Setting Text, Wed Sep 21, 11 am PST
• Part 3: The New Frontier—OpenType typography on the Web, Wed Oct 5, 11 am PST

Read all the details on the WebINK blog. Or just register now.

Browser Choice vs Font Rendering »

This post by Jeffrey Zeldman on font rendering in web browsers is a good introduction to the subject in a number of respects, but unfortunately repeats a pernicious myth: that web browsers on Windows all render text differently, and that this interacts with the OS rendering. There are a couple of caveats (see below), but for the most part, this a this is a system level setting. On any given Windows computer running XP or Vista or Windows 7, you will generally get >pixel-​for-​pixel identical glyph rendering in Internet Explorer, Firefox, Chrome, or Safari. (As also shown in Si Daniels’ presentation at ATypI 2009 in Mexico City).

Why is this? All of today’s major web browsers on Windows (IE, Firefox, Chrome, Safari) simply use the OS’s user-​adjustable GDI text rendering settings, whatever those may be. Similarly, all today’s major web browsers on Mac OS simply use the system text rendering.

(Yes, there are a couple of caveats. Internet Explorer 7 actually ignores the OS setting in favor of its own prefs setting, which is to use the OSes ClearType rendering regardless. Safari for Windows has an optional setting to use Apple’s “Quartz” text rendering, even on Windows—this was the one-​and-​only rendering option in Safari 3 for Windows, but Windows users “freaked,” so Apple changed it for Safari 4 for Windows. Also, Firefox can use the kerning built into fonts, which affects spacing, though it doesn’t actually impact rendering of individual glyphs. Every major browser uses the same rendering as some version of OS rendering, however; none does something unrelated to Mac or Windows text rendering.)

So why does rendering vary so much? Windows XP, Vista and Windows 7 can be set to one of three settings for “font smoothing” (a.k.a. anti-​aliasing). These settings affect all applications using the old-​school GDI APIs for text rendering, which as of late 2009 means all the major web browsers. The font smoothing settings are:

• off (uncheck the box that says “use the following method to smooth the edges of screen fonts)
• Standard (grayscale)
• ClearType (optimization for color LCD screens)

Note that the standard vs ClearType distinction only affects fonts with TrueType outlines. Fonts in PostScript Type 1 or OpenType CFF formats get a less sophisticated type rendering/​smoothing which, well, seems less than stellar these days.

“Standard” (grayscale anti-​aliasing) is the default on Windows XP, although installing Internet Explorer 8 will change that setting to “ClearType” (even if one then proceeds to use a different web browser). Windows Vista and Windows 7 default to ClearType. So, most folks on Windows are seeing ClearType rendering, one way or another. However, 

Besides GDI (all of today’s browsers), there is a completely different rendering mode used by applications which are programmed to use the “DirectWrite” text APIs (similar rendering also available to the largely-​ignored WPF APIs). This uses ClearType, but a ClearType which is improved over the GDI version. For TrueType outlines, It offers moderate but noticeable improvements, such as options for improved spacing, and anti-​aliasing in the Y direction. OpenType CFF fonts see a truly dramatic improvement, going from really mediocre rendering under GDI to rendering roughly equally well with TrueType under DirectWrite (or under its predecessor, WPF)! Minion Pro and Myriad Pro in OpenType CFF render pretty well down to 9 pixels per em (ppem), and just fabulously at 12 or more.

This is worth knowing and noting because it has already been announced that Internet Explorer 9 will use DirectWrite, and apparently FireFox is working on it as well.

[Post updated 8 Jan 2010 to correct IE 7 having a built in pref for which OS rendering it uses. Thanks to commenters! – T]

Boing Boing Redesign Uncovers Web Font Ignorance »

People keep on sending me links to this article  “Boing Boing’s Redesign Uncovers Dark Side of Web Fonts,” about problems Boing Boing had with their new web font implementation. Only thing is, the article has a substantial dose of nonsense mixed in with the perfectly good analysis. I don’t blame the writer, though. This web font stuff is actually really complicated, and information has been hard to come by. Heck, I even briefly forgot a basic point in a first pass at this article. But nonetheless, I am fairly sure that Boing Boing could have fixed their problems easily, if they knew how. Here’s the story:

WHAT HAPPENED

The background here is that there are new ways of using fonts with web sites, and Boing Boing tried the simplest approach of just hosting a free font on their own web server and pointing at it, but the on-​screen results were not as good as expected.

“…the font it settled on — specifically BPreplay — ended up looking terrible for most users.”

“The result was hordes of angry Boing Boing fans complaining that the new headline font was “ugly,” “an abomination” and “plain nasty.” Of course, the culprit wasn’t really the font, but rather how different it looked depending on which browser and operating system the viewer was using.”

FINDING THE CULPRIT?

This is where things get tricky. I will update this post as I learn more. But, as best as I can tell, if that link to the font is right, and the font wasn’t modified by Boing Boing, the culprit really was in large part the font. But first let’s follow the trail of the previous article and make some corrections….

“The problem is that while modern browsers, like the latest versions of Safari, Firefox, Opera and Google Chrome, all support @font-face, the Windows XP operating system often doesn’t have anti-​aliasing turned on by default.”

Not true. Anti-​aliasing is on by default in XP. What isn’t usually on by default in XP is ClearType, Microsoft’s enhanced anti-​aliasing for LCD screens. Sometimes a computer vendor will turn ClearType on for the computers they sell (particularly if they are laptops or come with an LCD monitor).

But what makes this even less meaningful is that (again assuming the linked font is the right one), the font in question is in OpenType CFF format. Such fonts are always anti-​aliased in XP, even if you turn off anti-aliasing—the setting change only affects TrueType fonts. Even ClearType doesn’t affect how these fonts are rendered (rasterized) in web browsers, either. Same thing in Vista, and as far as I know in Windows 7 as well.

“The rule, which is still part of CSS3’s draft specification, is also not supported by any version of Internet Explorer. So, as cool as your font might look when properly anti-​aliased, on Windows XP it looks, as Rob Beschizza, head of Boing Boing’s redesign puts it, ‘like ass.’”

I’m not sure how those two sentences are related. That’s a mystery to me. XP can get good anti-​aliasing as well as Vista, and Internet Explorer is bundled with Vista and Windows 7 as much as with XP. But even taking those points separately….

The @font-face rule was actually in CSS 2 way back when, and removed in CSS 2.1. Internet Explorer has supported @font-face in every version from IE 4 to the current IE 8, but the catch is they support it only with Microsoft’s “.eot” font format (a wrapper around a TrueType font), not with regular desktop fonts. But there’s a good reason for not supporting regular desktop fonts directly: font vendors mostly won’t license their fonts to be stuck “naked” on web servers without any additional protections. Sure, there are free fonts, but, well, we’ll talk about those in a few minutes.

If Boing Boing simply put up the naked .otf font file, and didn’t do anything for Internet Explorer users (and people running older versions of other browsers), then what font actually got displayed to those users would depend on what Boing Boing specified as the fallback fonts and whether the people actually had those fonts (and thanks to Ben Kiel for reminding me of this in passing). Now, if the fallback stack relied on fonts that most XP users would not have, but Vista users would, then there might be a difference that was at least partly based on operating system. But of course it would simply be up to the folks constructing the CSS for the web site to pick reasonable fallback fonts, and not really the fault of the operating system. Perhaps as a first-​level fallback from their desired font they specified one of the so-​called “ClearType fonts” such as Calibri or Corbel, which are bundled with Windows Vista and Office 2007. Not quite right to blame XP for not having the font, but that would explain how somebody could mislabel it as an XP-​specific problem.

Other than that, whether you are using Windows XP or not has little to do with whether or not the font looks “like ass.” Turning on ClearType can further improve rendering for fonts with TrueType outlines, but would have no effect on this particular font. Being on Vista instead of XP would make no difference at all for any web browser rendering OpenType CFF fonts such as this one.

Side note: The font wouldn’t even be seen in Internet Explorer, because Boing Boing didn’t use its .eot format as far as I know. Any further problems in IE would then be due to a poorly-​specified font fallback stack in the CSS. However, if they had used .eot and TrueType outlines…. Although XP has ClearType off by default, newer versions of Internet Explorer turn it on just for the browser, so there isn’t much difference between IE rendering of TrueType fonts between XP and Vista.

In researching what went wrong, it doesn’t help that Boing Boing backed off from the font change part of their redesign, so we can’t look at it and test it. Looking at this screenshot, however, shows pretty clearly what was going on. This screen capture was definitely taken on Windows, and the font in question is still anti-​aliased. However, it has some pretty crappy artifacts in how it’s rendered on screen, at least some of which are related to it being unhinted. When I see things like a single pixel sticking out of the bottom of a round shaped letter, that’s a dead give-​away that the problem is likely hinting (or more accurately, lack thereof).

“Hinting” is essentially extra code in the font that improves its rendering at screen resolution. Apple’s rendering approach largely ignores hinting, but Microsoft’s rendering still uses it a fair bit. Passable hinting can be done automatically by font editing tools, so there’s no real excuse for leaving it out of a font (as with this one). In fact, pretty much every commercial font on the planet is hinted, as are most free fonts. But this isn’t even an average free font. Yes, the terrible spacing is pretty typical for free fonts, but being unhinted is uncommon. Maybe it was converted by somebody else.

Bottom line: the font sucks. This should not be a surprise. Most free fonts do. Don’t get me wrong. There are a few great free fonts out there. But 98% of free fonts suck badly, and maybe about 20% of typically-​priced retail fonts suck badly, so set your expectations appropriately.

THE “DIRTY LITTLE SECRET”

But there’s another problem that might have led to complaints and concerns even if the font was made decently, but still in the same format. The “dirty little secret” of the font world is this: Windows GDI rendering of OpenType CFF and “PostScript” Type 1 fonts on screen just sucks, compared to its rendering of TrueType fonts.

Typophiles have long ignored this fact, because in the environments they’ve cared about, Type 1 and OpenType CFF fonts render perfectly well on screen:

• Just about any application on the Mac OS.
• Adobe Acrobat, InDesign and Illustrator, on any platform.

Unfortunately, Windows GDI rendering is what 90% of people see in web browsers and office applications today. (Yes, Safari for Windows also has the option to use its own rendering system, but that’s a tiny minority.) Internet Explorer sidesteps the problem simply by not supporting OpenType CFF fonts in .eot format, only TrueType (though one can convert). But it’s not like .eot ever caught on with web designers, anyway.

The future could improve. There is much better OpenType CFF rendering, even applying ClearType, available for applications using Windows Presentation Foundation and  DirectWrite, but very few applications use these modes today, so it is sadly not very relevant… yet. My recollection is that the technical preview of Office 2010 for Windows has dramatically better rendering of OpenType CFF, so perhaps it is coming. Maybe Internet Explorer 9 will get there too, supporting both outline formats in .eot or some new web font format. Perhaps in five years decent support for OpenType CFF rasterization on screen will have reached the strong majority of web browsers….

CONCLUSION

So for me it’s a toss-​up as to whether I blame Windows GDI rendering, or the fact that Boing Boing used a crappy free font (BPreplay) because they couldn’t legally use the retail font they wanted to (VAG Rounded). My first take is that I think Windows GDI just made worse something that would have been a problem anyway. Somebody who knows what they’re doing could spend ten minutes and either fix the font’s hinting in BPreplay or convert it to the TrueType flavor of OpenType—if the license permits it, I’d be happy to try either for them. But then again, maybe the complaint is more about the fallback font, a factor easily controlled by the web site author.

So yes there are some pitfalls. Obviously things would be better if one format worked across all browsers. But there’s also the question of whether one can use the fonts one wants, which tripped up the Boing Boing folks. What happens with that depends on what font vendors decide to do with the fonts they control the licensing for; many foundries are still trying to figure out how to approach the web fonts conundrum. Will they license fonts for use on web servers directly? Will they do so but specify security requirements that can’t be met by sticking regular desktop fonts on web servers, meaning that we’ll have to wait for new web font formats to be widely adopted, such as WOFF? Will they instead rely on a font serving process that involves something centralized, either run by themselves, or by a third party (such as TypeKit or Kernest)?

How exactly this will play out is still TBD today. What I do know for certain is that within a few years, web fonts will be a reality for the average viewer and the average web site. Many or even most web sites will pick specific fonts that aren’t necessarily already on the viewing computer, and those fonts will get used to display the desired text. Font selection will become part of branding for the web the way it has been in print. We’ll also get an explosion of awful font choices on web sites, particularly small personal ones, much like when the masses first got access to a wide variety of fonts they could print on their home computers. But overall, it will be a Good Thing, and I relish the thought of a more typographically rich web world in a year or three.

[Updated for minor clarifications 2009-​10-​12, reformatted 2009-​10-​13, added a bit on font fallback 2009-10-13]

Spring/​summer 2009 speaking »

I have a few talks coming up in the next little while. Currently planned:

WorldWare Conference, 17-​19 March 2009, Santa Clara, CA
Font Handling in Multilingual Software
Um, well, yes, this talk is today. Fonts are a critical part of making software world-​ready, and applications must test with the right fonts. Various font formats take different paths to dealing (or not dealing) with the needs of the world’s languages. Operating systems offer varying levels of support for the different formats. Learn how to navigate and escape this maze!
45 min

Justified West Conference, 25 April 2009, Vancouver, BC, Canada

Justified West 2009 Conference poster image—click for higher-​res version

To register, phone 604-​323-​5322. Email Dr Shelley Gruendler for more info
Forensic Typography
Thomas Phinney discusses and shows cases of forged documents and other typographic investigations he’s been asked to investigate, from a
father’s will to the NFL’s Pro Football Hall of Fame, to the US
presidency. Learn how choices of fonts, typography and output devices
have ruined perfectly good forgeries.
30 min

HOW Design Conference, 24-​27 June 2009, Austin, Texas
10 Things You Didn’t Know Fonts Could Do
Join type guru Thomas Phinney on a whirlwind tour of advanced typography using OpenType, from the incredibly useful to the bizarre. You’ll learn how advanced typographic effects formerly only available to experts can now be automated, and see how cutting-​edge fonts can do everything from emulate realistic handwriting to translate languages. You’ll get plenty of tips and tricks (including tips for more legible type in print and onscreen), and there will be time set aside for Q&A—so be sure to bring your burning type questions.
75 min

Video: OpenType, cross-​app text, Flash, etc. »

Worst Presentation EVAR

I almost didn’t blog about this, because it was probably the most messed-​up presentation I’ve done in the last many years. I was trying to do a PDF-​based presentation interleaved with a demo in InDesign, but my keyboard stopped working completely when I was in full-​screen mode in Acrobat… meaning I also had no way to get out of Acrobat to do the demo! So I had to reboot, re-​order my presentation on the fly, and improvise talking through from memory some stuff I had intended to do with accompanying slides, while waiting for my computer to complete the reboot and then for InDesign to launch (which last took 3x as long because I had rebooted while it was running). I also had a cold, so I am clearing my throat every 30 seconds. On top of that, the guy doing the presentation in the next room was REALLY LOUD and somehow his presentation included loud heavy metal music…. Which you can’t hear it on the recording, but I and the audience could hear it very clearly, and it was seriously distracting. Aaargh!

All of which threw me off my pace a bit, even if I seem to be handling it with aplomb on the recording. So even after I’m out of the part where my computer is totally hosed, I’m not at my best.

That being said there’s still some decent stuff in several spots of this AdobeTV recording from Adobe MAX, November 2008. See below for key bits to watch:

• Preserving OpenType alternate glyphs across apps: 5:25 – 8:20 (audio only)
• OpenType typography features: 13:30 – 35:40 (video)

• Just don’t expect me to be at my scintillating best on this one, okay?

  Share this:

  • Email
  • Print
  • Twitter
  • Facebook
  • More

  • Reddit
  • LinkedIn
  • Pocket
  • Tumblr
  • Pinterest

Unable to install OpenType .otf & PostScript Type 1 fonts? »

Sometimes folks can’t install any OpenType CFF (“.otf”) or Type 1 (a.k.a. “PostScript”) fonts on a Windows computer. There are (at least) four known causes for this. (The new outbreak of problem #4 below spurred me to write them all up.)

1. What version of Windows is the user running? If a really ancient version (Windows ME, Windows 98, Windows 95, or Windows NT 4), then they need to install ATM (Light) on their computer. Note that Windows NT 4 uses a different version than Windows 98/​ME. Type 1 and OpenType CFF fonts simply will not work on these operating systems without ATM.
2. One common source of this problem in the past was if the user uninstalled ATM (Light or Deluxe) without first updating/​patching things properly. This problem can occur on Windows 2000, XP and Vista. Adobe has had a simple fix for this since 2002. (Similar problems could occur if one somehow ended up with the Windows 9x/​ME ATM installed on a 2000/​XP/​Vista machine.) This problem is uncommon now, as few people on these operating systems have had ATM installed in the first place.
3. If somebody has turned on the “/​3GB switch” on the computer, that can cause this problem, but the use of the /​3GB switch does not cause this problem for all users. You may want to better understand what the /​3GB switch does, the consequences thereof, and then look at how to toggle it (how to turn it on is also how to check it or turn it off). Basically it’s a matter of removing the phrase “/​3GB” from the boot.ini file. On Windows XP, one can go into the control panels and select the “System” (System Properties) one. Go to the Advanced tab. In the “Startup and Recovery” section, select “Settings.” Then click on the “Edit” button to edit the startup settings manually. This will open the boot.ini file in Notepad. Typically the /​3GB switch if present will be the last entry, right after “/​fastdetect”.
4. The latest and currently most common problem occurs even with brand new and unmodified machines running Windows XP or possibly Vista, being unable to use Type 1 or OpenType CFF fonts, with an error message that the fonts are “invalid.” It is a video driver configuration issue, and reverting to an older (!) video driver generally solves the problem, but that’s not ideal. A few weeks ago, this problem was solved: it can be fixed with a simply registry edit. NVidia says the problem occurs on Windows XP only, and Vista users are unaffected, but at least one Vista user has reported they had this problem and the fix resolved it. It affects multiple cards from both NVidia and ATI. The fix, posted by David Ingraham in a horribly lengthy thread on the Adobe User Forums, and in a post by “PixelNinja” on the NVidia forums is this:— start of email from HP —Good news. Nvidia has identified the problem and provided a fix. The way it was explained to me, Windows expects the device driver to be a certain size (maximum). In this case, the nvidia driver is slightly larger than expected. A simply registry entry will resolve the issue in WinXP (the issue doesn’t occur in Vista).To resolve the problem, do the following:Open the registry editor (regedit)Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

   Add a new REG_​DWORD entry called SessionImageSize with a value (decimal) of 20

   Reboot

   The Type 1 fonts should now open/​install without any problems.

   — End of HP email —

   Tech support is a painful and mostly unsung profession. We should all give a special thanks to HP tech support guy John Camparone, who apparently went to truly great lengths to diagnose and debug this last problem with NVidia. Thanks, man.