Windows Installer Wants to Re-Install an Installed Font file

[albeter]

I have come across several applications with similar problems to the following.

I have an application which I install (onto a PC w/ Windows XP). As a result of this installation one or more font files are installed into the standard Windows font folder (i.e., C:\WINDOWS\Fonts). [For example: MININ___.TTF]. I then copy the font file(s) and relocate them into a different folder (e.g., ...\Font Archive\), and then uninstall the font(s) from C:\WINDOWS\Fonts. Then using MainType I install the font(s). MainType is configured to not copy the installed fonts to the Windows font folder. The result is that the font(s) are installed, but the files do not reside in the Windows font folder.

The problem is that when I then try to launch the application, Windows logs an error in the Event Viewer similar to the following:

Detection of product '{E8D54BE3-7781-4B87-BB9F-62719B0E52A6}', feature 'AlwaysInstall', component '{8648246C-F73E-4567-A75A-9E50FAE70374}' failed. The resource 'C:\WINDOWS\Fonts\MININ___.TTF' does not exist.

And, Windows [.msi] Installer then tries to re-install the font file(s) into the Windows font folder.

Why does Windows not detect that the font file is already installed?

And, how do I prevent it from re-installing the font file back into the Windows font folder?

[Erwin Denissen]

I have come across several applications with similar problems to the following.

I have an application which I install (onto a PC w/ Windows XP).

Although you didn't mention what application, I guess the application is the cause of the error.

[albeter]

I have come across several applications with similar problems to the following.

I have an application which I install (onto a PC w/ Windows XP).

Although you didn't mention what application, I guess the application is the cause of the error.

The specific application for which I provided the cited error message is Houghton Mifflin’s eReference desktop application for Windows. You can learn more about this application at the following web site: http://www.houghtonmifflinbooks.com/eref/index.jsp

However, as I stated, I have encountered other applications which have similar behaviors. For instance, Microsoft’s IntelliPoint SW that comes with their mouse pointing devices exhibits similar behavior. Upon installation of this application, the following 2 font files are installed in the Windows font folder: Swkeys1.ttf and SWMacro.otf.

After relocating these font files from the Windows font folder to my /Font Archive/ folder, and then installing the fonts with MainType, upon launching the IntelliPoint SW application, the Windows [.msi] Installer then tries to re-install the font files into the Windows font folder. Checking the Event Viewer I find the following error message:

Detection of product '{8C5FAD77-F678-4758-A296-C12F08D179E0}', feature 'IntelliPoint', component '{59C151FB-6A0A-41A6-B914-7B472F28BE15}' failed. The resource 'C:\WINDOWS\Fonts\Swkeys1.ttf' does not exist.

I believe this behavior has to do with the Windows [.msi] Installer for the application. If it does not detect the physical presence of the font file(s) in the Windows font folder, it initiates a process to re-install them. This behavior effectively destroys the common procedure of relocating font files out of the Windows font folder and forces us to keep what may be seldom used font files resident in the Windows font folder. That is unless there is a way to disable this behavior.

[Erwin Denissen]

Have you asked Houghton Mifflin if they know more about it?

[Bhikkhu Pesala]

albeter,

These applications expect to find the fonts in a certain place, so don't move them and you won't have a problem.

This is not a fault with MainType, but a limitation of those applications. When they launch, I assume that they must be checking their own program registry key instead of the Windows font registry. Although the font is correctly installed, they think it is not, so they ask you to install it again.

You should contact the software vendors and ask them to fix their program to be more adaptable. I presume that you can use these fonts in Wordpad, etc., so if the eReference program cannot use them, the problem lies with the eReference program doesn't it?

[ravendawson]

Well, why don’t you look for a fix for such a Windows installer error like this? It would be better to contact professionals. You may only have bigger problems if you try to move the applications yourself.