Curious behavior after rebuilding default fonts

After mangling Marlett yet again, I followed Microsoft Support's article on
replacing the Windows default fonts. I found (not surprisingly) that many of
my apps couldn't find or recognize fonts anymore. I remember running into
this before and thought deleting the desktop.ini file and reopening the Fonts
directory would solve it. No such luck.

After reading more posts in this newsgroup, I discovered the wonders of
TweakUI, downloaded it and asked it to repair Fonts. After the obligatory
reboot, I still hadn't had any success, but then ran "c:\windows\fonts\"
again just for grins and sure enough, the fonts were "fixed." All the apps
could recognize fonts again.

Thinking my problems were solved, I later rebooted and to my horror, all was
not well; it had reverted to earlier errant behavior. Again the
"c:\windows\fonts\" and, lo and behold, it's correct. What gives? I can
reboot, get bad behavior, open the Fonts directory and fix it, then later
reboot for more fun and games. I tried TweakUI again with the same results.

Any bright ideas from the system magicians? Thanks for your help.

Jon

Marlett doesn't just get mangled by itself.. I suspect you have a more
basic problem than some oddities in the fonts folder. Have you done a
recent Scandisk thorough? What exactly do you mean by "ran
'c:\windows\fonts\'"? - if this is a command you are typing (eg, at Run)
then I cannot imagine how it would have any effect at all.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Range Rat" Range wrote in message
...
After mangling Marlett yet again, I followed Microsoft Support's article
on
replacing the Windows default fonts. I found (not surprisingly) that many
of
my apps couldn't find or recognize fonts anymore. I remember running into
this before and thought deleting the desktop.ini file and reopening the
Fonts
directory would solve it. No such luck.

After reading more posts in this newsgroup, I discovered the wonders of
TweakUI, downloaded it and asked it to repair Fonts. After the obligatory
reboot, I still hadn't had any success, but then ran "c:\windows\fonts\"
again just for grins and sure enough, the fonts were "fixed." All the apps
could recognize fonts again.

Thinking my problems were solved, I later rebooted and to my horror, all
was
not well; it had reverted to earlier errant behavior. Again the
"c:\windows\fonts\" and, lo and behold, it's correct. What gives? I can
reboot, get bad behavior, open the Fonts directory and fix it, then later
reboot for more fun and games. I tried TweakUI again with the same
results.

Any bright ideas from the system magicians? Thanks for your help.

Jon

"Jeff Richards" wrote:

Marlett doesn't just get mangled by itself..

Sure it does. I've replaced it enough times successfully to know to set
aside extra copies in case it happens again, usually due to insufficient
memory during an IE surf session. There's a whole separate MS Support page
just for Marlett (Sorry, can't remember the number, but I found it on this
forum).

Having said that, I just replaced them all to be on the safe side. I've had
similar incidents in the past where this was the easy solution.

I suspect you have a more
basic problem than some oddities in the fonts folder. Have you done a
recent Scandisk thorough?

Scandisk yes, no problems. If there are other oddities, I haven't seen
them. Seems pretty isolated.

What exactly do you mean by "ran
'c:\windows\fonts\'"? - if this is a command you are typing (eg, at Run)
then I cannot imagine how it would have any effect at all.

Per the MS support article, it rebuilds the desktop.ini file from scratch in
that directory.

--
Jeff Richards
MS MVP (Windows - Shell/User)
"Range Rat" Range wrote in message
...
After mangling Marlett yet again, I followed Microsoft Support's article
on
replacing the Windows default fonts. I found (not surprisingly) that many
of
my apps couldn't find or recognize fonts anymore. I remember running into
this before and thought deleting the desktop.ini file and reopening the
Fonts
directory would solve it. No such luck.

After reading more posts in this newsgroup, I discovered the wonders of
TweakUI, downloaded it and asked it to repair Fonts. After the obligatory
reboot, I still hadn't had any success, but then ran "c:\windows\fonts\"
again just for grins and sure enough, the fonts were "fixed." All the apps
could recognize fonts again.

Thinking my problems were solved, I later rebooted and to my horror, all
was
not well; it had reverted to earlier errant behavior. Again the
"c:\windows\fonts\" and, lo and behold, it's correct. What gives? I can
reboot, get bad behavior, open the Fonts directory and fix it, then later
reboot for more fun and games. I tried TweakUI again with the same
results.

Any bright ideas from the system magicians? Thanks for your help.

Jon

MS has an article about replacing the Marlett font because it is needed for
certain symbols. It can be damaged or lost like any file, but unless there's
something wrong in the machine it should not be getting mangled on any
regular basis. For instance, I can't recall that I've ever had to replace
it on any of my systems, other than as part of some more general disk or
system failure.

Similarly, it is sometimes necessary to rebuild desktop.ini, but why do you
even need this for the fonts folder? It is not a folder that you ever need
to view. And I nonetheless cannot imagine how system.ini could have any
effect on the use of fonts in that folder.

You say that there are no other oddities, but you also mention "insufficient
memory during an IE surf session." Windows uses virtual memory and should
not run out, unless you have insufficient disk space or you have somehow
crippled the swap file. If this is happening then that is exactly the sort
of oddity that can create the effects you are seeing, and it should be
resolved.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Range Rat" wrote in message
...


"Jeff Richards" wrote:

Marlett doesn't just get mangled by itself..

Sure it does. I've replaced it enough times successfully to know to set
aside extra copies in case it happens again, usually due to insufficient
memory during an IE surf session. There's a whole separate MS Support
page
just for Marlett (Sorry, can't remember the number, but I found it on this
forum).

Having said that, I just replaced them all to be on the safe side. I've
had
similar incidents in the past where this was the easy solution.

I suspect you have a more
basic problem than some oddities in the fonts folder. Have you done a
recent Scandisk thorough?

Scandisk yes, no problems. If there are other oddities, I haven't seen
them. Seems pretty isolated.

What exactly do you mean by "ran
'c:\windows\fonts\'"? - if this is a command you are typing (eg, at Run)
then I cannot imagine how it would have any effect at all.

Per the MS support article, it rebuilds the desktop.ini file from scratch
in
that directory.

--
Jeff Richards
MS MVP (Windows - Shell/User)
"Range Rat" Range wrote in message
...
After mangling Marlett yet again, I followed Microsoft Support's
article
on
replacing the Windows default fonts. I found (not surprisingly) that
many
of
my apps couldn't find or recognize fonts anymore. I remember running
into
this before and thought deleting the desktop.ini file and reopening the
Fonts
directory would solve it. No such luck.

After reading more posts in this newsgroup, I discovered the wonders of
TweakUI, downloaded it and asked it to repair Fonts. After the
obligatory
reboot, I still hadn't had any success, but then ran
"c:\windows\fonts\"
again just for grins and sure enough, the fonts were "fixed." All the
apps
could recognize fonts again.

Thinking my problems were solved, I later rebooted and to my horror,
all
was
not well; it had reverted to earlier errant behavior. Again the
"c:\windows\fonts\" and, lo and behold, it's correct. What gives? I
can
reboot, get bad behavior, open the Fonts directory and fix it, then
later
reboot for more fun and games. I tried TweakUI again with the same
results.

Any bright ideas from the system magicians? Thanks for your help.

Jon

Jeff Richards wrote:

MS has an article about replacing the Marlett font because it is needed for
certain symbols. It can be damaged or lost like any file, but unless there's
something wrong in the machine it should not be getting mangled on any
regular basis. For instance, I can't recall that I've ever had to replace
it on any of my systems, other than as part of some more general disk or
system failure.

Similarly, it is sometimes necessary to rebuild desktop.ini, but why do you
even need this for the fonts folder? It is not a folder that you ever need
to view. And I nonetheless cannot imagine how system.ini could have any
effect on the use of fonts in that folder.

i have no insights for Range Rat, but Jeff ...
viewing the the fonts folder is what you do if you choose the Fonts
control panel applet. And like for the TIF-folder, what you'll see is
not what you really have in there. And from the little i know, isn't
this special appearance /at least partly/ governed by the contents of
the desktop.ini (ClsID - BD84B380-8C... telling it via the registry to
use FontExt.dll for this and that to give you the special folder-GUI.)?


You say that there are no other oddities, but you also mention "insufficient
memory during an IE surf session." Windows uses virtual memory and should
not run out, unless you have insufficient disk space or you have somehow
crippled the swap file. If this is happening then that is exactly the sort
of oddity that can create the effects you are seeing, and it should be
resolved.


--
Please followup in newsgroup.
E-mail address is invalid due to spam-control.

Certainly Windows manages the fonts folder differently (although TIF is
different again) but what you see is pretty much what you get. I have no
DESKTOP.INI in my fonts folder, and it views from the CP applet just fine.
AFAIK there's no reason that you shouldn't apply special options to the
folder (which will create the INI file), it's just that I can't see how it
could be related to disappearing files.

The KB on restoring the fonts folder (234749) does not mention any need to
restore the INI file. It's possible that FONTEXT.DLL gets confused by a bad
INI file, but I haven't seen any reference to such a problem. OP mentions a
"MS support article" about the 'fix' to open the folder and re-create the
INI file, but I can't find it. On my system, opening the folder does not
rebuild the INI file. Opening the folder is mentioned as the last step in KB
234749, but there's no explanation as to why, and no mention of rebuilding
the INI file.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"... et al." wrote in message
...
snip

i have no insights for Range Rat, but Jeff ...
viewing the the fonts folder is what you do if you choose the Fonts
control panel applet. And like for the TIF-folder, what you'll see is not
what you really have in there. And from the little i know, isn't this
special appearance /at least partly/ governed by the contents of the
desktop.ini (ClsID - BD84B380-8C... telling it via the registry to use
FontExt.dll for this and that to give you the special folder-GUI.)?

Desktop.ini doesn't appear to show up in Explorer in the Fonts folder. I
can see it at a DOS Prompt, though...

C:\WINDOWS\FONTSdir /a desktop.ini
Directory of C:\WINDOWS\FONTS
DESKTOP INI 349 09-02-02 4:53a DESKTOP.INI
1 file(s) 349 bytes

C:\WINDOWS\FONTStype desktop.ini
[.ShellClassInfo]
UICLSID={BD84B380-8CA2-1069-AB1D-08000948F534}
ConfirmFileOp=0

[{8BEBB290-52D0-11d0-B7F4-00C04FD706EC}]
MenuName=T&humbnails
ToolTipText=T&humbnails
HelpText=Displays items using thumbnail view.
Attributes=0x60000000

[ExtShellFolderViews]
{8BEBB290-52D0-11d0-B7F4-00C04FD706EC}={8BEBB290-52D0-11d0-B7F4-00C04FD7
06EC}


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Jeff Richards" wrote in message
...
| Certainly Windows manages the fonts folder differently (although TIF
is
| different again) but what you see is pretty much what you get. I have
no
| DESKTOP.INI in my fonts folder, and it views from the CP applet just
fine.
| AFAIK there's no reason that you shouldn't apply special options to
the
| folder (which will create the INI file), it's just that I can't see
how it
| could be related to disappearing files.
|
| The KB on restoring the fonts folder (234749) does not mention any
need to
| restore the INI file. It's possible that FONTEXT.DLL gets confused by
a bad
| INI file, but I haven't seen any reference to such a problem. OP
mentions a
| "MS support article" about the 'fix' to open the folder and re-create
the
| INI file, but I can't find it. On my system, opening the folder does
not
| rebuild the INI file. Opening the folder is mentioned as the last step
in KB
| 234749, but there's no explanation as to why, and no mention of
rebuilding
| the INI file.
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
| "... et al." wrote in message
| ...
| snip
|
| i have no insights for Range Rat, but Jeff ...
| viewing the the fonts folder is what you do if you choose the Fonts
| control panel applet. And like for the TIF-folder, what you'll see
is not
| what you really have in there. And from the little i know, isn't
this
| special appearance /at least partly/ governed by the contents of the
| desktop.ini (ClsID - BD84B380-8C... telling it via the registry to
use
| FontExt.dll for this and that to give you the special folder-GUI.)?
|
|
|

Desktop.ini files, in any folder, are usually hidden and won't appear in
Explorer unless it is set to show hidden files. Perhaps it's associated
with active desktop. If so, that might explain a number of things ;-)
--
Jeff Richards
MS MVP (Windows - Shell/User)
"PCR" wrote in message
...
Desktop.ini doesn't appear to show up in Explorer in the Fonts folder. I
can see it at a DOS Prompt, though...

C:\WINDOWS\FONTSdir /a desktop.ini
Directory of C:\WINDOWS\FONTS
DESKTOP INI 349 09-02-02 4:53a DESKTOP.INI
1 file(s) 349 bytes

C:\WINDOWS\FONTStype desktop.ini
[.ShellClassInfo]
UICLSID={BD84B380-8CA2-1069-AB1D-08000948F534}
ConfirmFileOp=0

[{8BEBB290-52D0-11d0-B7F4-00C04FD706EC}]
MenuName=T&humbnails
ToolTipText=T&humbnails
HelpText=Displays items using thumbnail view.
Attributes=0x60000000

[ExtShellFolderViews]
{8BEBB290-52D0-11d0-B7F4-00C04FD706EC}={8BEBB290-52D0-11d0-B7F4-00C04FD7
06EC}


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Jeff Richards" wrote in message
...
| Certainly Windows manages the fonts folder differently (although TIF
is
| different again) but what you see is pretty much what you get. I have
no
| DESKTOP.INI in my fonts folder, and it views from the CP applet just
fine.
| AFAIK there's no reason that you shouldn't apply special options to
the
| folder (which will create the INI file), it's just that I can't see
how it
| could be related to disappearing files.
|
| The KB on restoring the fonts folder (234749) does not mention any
need to
| restore the INI file. It's possible that FONTEXT.DLL gets confused by
a bad
| INI file, but I haven't seen any reference to such a problem. OP
mentions a
| "MS support article" about the 'fix' to open the folder and re-create
the
| INI file, but I can't find it. On my system, opening the folder does
not
| rebuild the INI file. Opening the folder is mentioned as the last step
in KB
| 234749, but there's no explanation as to why, and no mention of
rebuilding
| the INI file.
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
| "... et al." wrote in message
| ...
| snip
|
| i have no insights for Range Rat, but Jeff ...
| viewing the the fonts folder is what you do if you choose the Fonts
| control panel applet. And like for the TIF-folder, what you'll see
is not
| what you really have in there. And from the little i know, isn't
this
| special appearance /at least partly/ governed by the contents of the
| desktop.ini (ClsID - BD84B380-8C... telling it via the registry to
use
| FontExt.dll for this and that to give you the special folder-GUI.)?
|
|
|

I turned off Active Desktop long ago. Does seem I had Thumbnail View
enabled for that folder, though. Still, turning that off, the .ini is
still there, only smaller...

C:\WINDOWS\FONTSdir /a desktop.ini
Directory of C:\WINDOWS\FONTS
DESKTOP INI 109 01-13-05 11:11p DESKTOP.INI
1 file(s) 109 bytes

C:\WINDOWS\FONTStype desktop.ini
[.ShellClassInfo]
UICLSID={BD84B380-8CA2-1069-AB1D-08000948F534}
ConfirmFileOp=0

[ExtShellFolderViews]


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Jeff Richards" wrote in message
...
| Desktop.ini files, in any folder, are usually hidden and won't appear
in
| Explorer unless it is set to show hidden files. Perhaps it's
associated
| with active desktop. If so, that might explain a number of things ;-)
| --
| Jeff Richards
| MS MVP (Windows - Shell/User)
| "PCR" wrote in message
| ...
| Desktop.ini doesn't appear to show up in Explorer in the Fonts
folder. I
| can see it at a DOS Prompt, though...
|
| C:\WINDOWS\FONTSdir /a desktop.ini
| Directory of C:\WINDOWS\FONTS
| DESKTOP INI 349 09-02-02 4:53a DESKTOP.INI
| 1 file(s) 349 bytes
|
| C:\WINDOWS\FONTStype desktop.ini
| [.ShellClassInfo]
| UICLSID={BD84B380-8CA2-1069-AB1D-08000948F534}
| ConfirmFileOp=0
|
| [{8BEBB290-52D0-11d0-B7F4-00C04FD706EC}]
| MenuName=T&humbnails
| ToolTipText=T&humbnails
| HelpText=Displays items using thumbnail view.
| Attributes=0x60000000
|
| [ExtShellFolderViews]
|
{8BEBB290-52D0-11d0-B7F4-00C04FD706EC}={8BEBB290-52D0-11d0-B7F4-00C04FD7
| 06EC}
|
|
| --
| Thanks or Good Luck,
| There may be humor in this post, and,
| Naturally, you will not sue,
| should things get worse after this,
| PCR
|
| "Jeff Richards" wrote in message
| ...
| | Certainly Windows manages the fonts folder differently (although
TIF
| is
| | different again) but what you see is pretty much what you get. I
have
| no
| | DESKTOP.INI in my fonts folder, and it views from the CP applet
just
| fine.
| | AFAIK there's no reason that you shouldn't apply special options
to
| the
| | folder (which will create the INI file), it's just that I can't
see
| how it
| | could be related to disappearing files.
| |
| | The KB on restoring the fonts folder (234749) does not mention any
| need to
| | restore the INI file. It's possible that FONTEXT.DLL gets
confused by
| a bad
| | INI file, but I haven't seen any reference to such a problem. OP
| mentions a
| | "MS support article" about the 'fix' to open the folder and
re-create
| the
| | INI file, but I can't find it. On my system, opening the folder
does
| not
| | rebuild the INI file. Opening the folder is mentioned as the last
step
| in KB
| | 234749, but there's no explanation as to why, and no mention of
| rebuilding
| | the INI file.
| | --
| | Jeff Richards
| | MS MVP (Windows - Shell/User)
| | "... et al." wrote in message
| | ...
| | snip
| |
| | i have no insights for Range Rat, but Jeff ...
| | viewing the the fonts folder is what you do if you choose the
Fonts
| | control panel applet. And like for the TIF-folder, what you'll
see
| is not
| | what you really have in there. And from the little i know, isn't
| this
| | special appearance /at least partly/ governed by the contents of
the
| | desktop.ini (ClsID - BD84B380-8C... telling it via the registry
to
| use
| | FontExt.dll for this and that to give you the special
folder-GUI.)?
| |
| |
| |
|
|
|
|

Jeff Richards wrote:

Certainly Windows manages the fonts folder differently (although TIF is
different again) but what you see is pretty much what you get. I have no
DESKTOP.INI in my fonts folder, and it views from the CP applet just fine.

It may view just fine as how you want to view it, and indeed it would
view just the way i like it to be displayed in/by Windows Explorer.
But it's not the way Steve & Bill dictates for us see it (see below).

I'd rather have Windows Explorer doing it's thing (showing files &
folders and their attributes) in truth-mode and use separate tools, e.g.
Windows Font Viever (FontView.exe) to (un-)install and see font-families
sorted together and so on. But Steve and Bill are big on integration (IE
as part of Windows, using archives just as folders in Windows Explorer,
and them /stupid/ special folders).

AFAIK there's no reason that you shouldn't apply special options to the
folder (which will create the INI file), it's just that I can't see how it
could be related to disappearing files.

You *should have* special options applied to the Fonts-folder, giving
you also different menuitems (Install New Font…, List Fonts By
Similarity & Hide variations ...) that i guess you also lack. Again, the
job for a standalone application in my opinion.


The KB on restoring the fonts folder (234749) does not mention any need to
restore the INI file. It's possible that FONTEXT.DLL gets confused by a bad
INI file, but I haven't seen any reference to such a problem. OP mentions a
"MS support article" about the 'fix' to open the folder and re-create the
INI file, but I can't find it.

He might have stumbled over, and you could have a look at, msKB #133725
where part of the law governing this folder is given to us.

On my system, opening the folder does not
rebuild the INI file. Opening the folder is mentioned as the last step in KB
234749, but there's no explanation as to why, and no mention of rebuilding
the INI file.

I don't know how Windows inner workings goes about it's business.
But in my desire to put Windows Explorer in truth-mode as much as
possible i, like you, have had no Desktop.ini in that folder for a long
time and haven't seen any negative effects as a result (as far as i've
been able to discern). Well, i probably didn't try to use the 'Install
New Font…' from inside that folder ;-). Then this fall ,when helping
someone that did have a font-related problem, i came across the above
msKB among several others dealing with fonts.

--
Please followup in newsgroup.
E-mail address is invalid due to spam-control.