"Shenan Stanley" wrote in <news:Ogce41PyIHA.2068@TK2MSFTNGP05.phx.gbl>:
> charlie@dslextreme.com wrote:
>> I get this error message that I have 500 fonts, and I should
>> eleminate some of them or the data may not display correctly. Okey,
>> but it doesn's say how to do it.
>
> Not sure where the message you allegedly got came from, but..
>
> Having too many fonts can slow down how fast programs start up. I have
> heard (in the past) some people say you should have no more than 500 fonts
> installed on Windows XP - in general the less you have the faster your
> programs that use them (office software, graphic programs etc..) will load.
>
> From the Control Panel, click on the "Fonts" icon. You can delete the fonts
> you don't use here.
Actually it would be the number of fonts used within a document that
affects how fast the application can load that document. Fonts are
considered GDI resources that load into memory. The GDI heap stores
fonts, brushes, palettes, bitmaps, pens, and other graphic items. Once
in the GDI object quota for an app's process, that resource doesn't need
to be read from the file again. For example, use FileMon from
SysInternals to monitor accesses to *.ttf files. Then open Wordpad.
The Arial font already got loaded into memory as a system GDI resource
so you won't see its .ttf get accessed in FileMon. Add several lines of
text in the test document. Then Ctrl+A to highlight it and select a
different font (one that uses .ttf for its definition). You'll see the
file get queried and opened in Filemon. Switch again to another font
and you see that font's file get accessed. Now change back to the font
you used before. You will NOT see the font file get accessed again
because it is in the GDI heap.
The application's load is not slowed by a large number of fonts. The
application loading a document may get slowed if that documents uses
lots of font. If it uses 1 or less than half a dozen fonts then you'll
probably not be able to measure the difference in time the application
takes to load that document. If, however, that document has 500
different fonts used within it then, yes, it will take longer for the
application to open that document - but that still doesn't affect how
long the application itself took to load. I've seen some documents with
maybe a dozen fonts used within them but I have never seen one with
hundreds of fonts used within the document.
Old tweaks die hard even when no longer applicable. Under Windows 3.1,
all fonts were loaded into a GDI heap during Windows 3.1 startup by
using file I/O to read them from the Fonts section in the win.ini file
(
http://support.microsoft.com/kb/58335) which affected its load time.
GDI heap management was improved under Windows 95/98 (see
http://support.microsoft.com/kb/125699 and
https://www.microsoft.com/technet/ar...t5/wrkc26.mspx).
"Both Windows 95 and Windows NT or Windows 2000 free all GDI resources
[which includes fonts] owned by a 32-bit process when that process
terminates", (
http://support.microsoft.com/kb/136989). They don't share
the same GDI heap anymore. Fonts which are GDI resources are only
loaded when requested. Obviously some font files get touched during
Windows load for its own GUI and perhaps by some startup programs but it
wouldn't matter if you had 200 or 3000 fonts since only the ones needed
are touched, not all fonts. If Windows was loading all these fonts as
system GDI resources on startup, they why are they still getting loaded
into the GDI heap for an application when an application wants to use
them? They would already be in memory if loaded on Windows startup.
The same folks proliferating the old scheme under new versions of
Windows that more fonts results in longer Windows startup time are the
same ones proliferating the concept that memory should be defragmented
despite that addressing is *random*, or that memory "optimization" by
pushing a process' memory pages into virtual memory to create more free
memory is beneficial despite that unused (free) memory is wasted memory
and virtual page thrashing incurs performance overhead, or that programs
shouldn't be running in the background when the host is idle (by the
user) as if less CPU cycles (instruction executes) somehow saves on the
wear and tear of the CPU. The 500 cutoff probably propagated from old
Windows 3.1 articles, like
http://support.microsoft.com/kb/82751. Most
times when someone makes the blanket but unfounded claim about font
counts, they are regurgitating what they read elsewhere and which is as
equally unsubstantiated.
On Windows NT/2K/XP startup, the fonts do get touched for GDI resources
for a startup process, like the GUI. The registry gets updated to
reflect what fonts are currently installed; see:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
How long do you think it takes to add 100, 1000, or 3000 fonts in a
registry list (which is in memory) when reading the font folder's
filelist? During the registry update, you think Windows is sitting
otherwise idle until this update completes? I've yet to see one
NT-based version of Windows that booted faster because several hundred
non-system fonts were deleted.
Linear Mode
